Should turbo-frame tags wrap, replace or be embedded in semantic html tags?

1

section, article, nav, aside…the handbook shows wrapping content in frames, but usually without semantic html tags.

<turbo-frame id="post_1"></turbo-frame>

We can’t duplicate id either so this isn’t good…

<article id="post_1">
    <turbo-frame id="post_1"></turbo-frame>
</article>

If we are pulling the frame contents from another page, for example show or edit, the semantic html might not match in those other context either, so…wrap the frame(content) in the semantic tag(article) without an id?

<article>
    <turbo-frame id="post_1"></turbo-frame>
</article>
2

And I guess along the same lines, should we avoid putting styling classes on the frame tag? I guess that would keep it cleanly to one purpose…

3

And I guess along the same lines, should we avoid putting styling classes on the frame tag? I guess that would keep it cleanly to one purpose…

How would you feel about markup that looked like this?

<turbo-frame id="post_1">
  <article />
</article>

I think you’re onto something, limiting the turbo-frame responsibilities, and adding supplementary elements that are either children or ancestors of the turbo-frame.

4

Interestingly if these turbo frames are nested in a section with the tailwindcss divide-y class, the dividers won’t appear between the frames until I apply the block class to the frames. I guess the custom turbo-frame element doesn’t have any display context? At the same time they are not invisible to the document flow which would be really fantastic. :thinking:

5

I’m tracking with you. That concoction of HTML and CSS where the relationships between elements matters could dictate how you construct your markup.

I don’t think you need to avoid putting styling on the turbo-frame tag, but I cannot speak with certainty. Is having a wrapping div with the style information equally problematic?

6

I don’t use Tailwind myself, but I wonder if setting turbo frames to display: contents would solve this? (Or it might break it entirely!)

7

It gets weirder when inspecting the elements.

Safari says that <turbo-frame> inherits display: block from html. But I still need an explicit class="block" to get it working…maybe Tailwind is doing a CSS reset on it.

8

Does anyone know a way to make an HTMLElement invisible to layout?

Like, shouldn’t <turbo-frame> be invisible to flow layout and just used as a placeholder?

9

display: contents is probably the best option for <turbo-frame> because I believe it shouldn’t be involved in layout and styling.

That said, although display: contents effectively removes the <turbo-frame> from layout, it has no effect on other things like css query selectors.

In the case of Tailwind, the divide-y class just looks for non-hidden children and sets the top border of each child beyond the first. Just a convenience class. So a display: contents element will not have a box layout and will not show a border. The direct decendant didn’t get the border style unfortunately.

Strangely, I still don’t understand why I must add turbo-frame { display: block; } or add class="block" to get the divide-y top border to show up. Safari show inheriting display: block from HTML…

10

Wrapping the <turbo-frame> with a styled div tag seems to be the best solution,
but ugh to adding layers of nesting. :thinking:

I really feel wrong about using the frame as the enclosing layout tag,
although that’s exactly what they show here.

1 Like