Post

Naming is hard, apparently, because I can see this being confused with the marker pseudo-element that already exists. developer.mozilla.org/en-US/docs/W...

That's fair. The naming definitely isn't set in stone. It's usually one of the things that changes later down the line in the feature design process.

Is there any precedent for non-tree-abiding tags?

What is this tag type called? <? marker> and <? range>.

are they "processing instructions" or "marker nodes"

You said your example causes a layout shift, but if you're streaming in HTML and the browser is laying out the first content would it be possible *not* to cause a layout shift?

you could be putting the new content in a non visible area (eg: that needs to be scrolled to or expanded), or if you can anticipate them you could set fixed heights to parent elements to reserve space on the screen for the new content

Ohh yeah, like <option>s in a <select>. Nice example.

the fact firefox has any AI integration is reason enough for me to never use it again, and for everyone to boycott it.

Being able to apply non-layout styling to arbitrary ranges (without JS) would be handy.

As for out of order streaming of HTML... It seems like a good (and perhaps even overdue) primitive. One not reliant on JS that should drive down TTFB and (subject to the implementation) TTI.

Wasn't <geolocation> recently added?

I meant a new tag type, rather than a new element name. Like, <?marker> will produce a different node type to what it does now.

dude your social media effort is so good jake, i really need to do some dx so do forgive me if i take some inspiration from you, but i really love the amount of effort you put into all this

ooooo would this work as a back end for fragments in frameworks?

Doesn’t harm to link to more of the relevant issues and explainers here, I guess.

By the way, besides that issue I learned of these plans after becoming curious about this Intent to Prototype by Blink:

I vaguely remember a thread in the early stages of HTML5 discussions and WHATWG formation that dealt with comment syntax, e.g. about the SGML rule that allowed `<!-- comment -- no comment -- comment again -->` in theory and how to handle stuff like `<!>`, which I had been using as a Todo marker.

I don’t see how riddling your content with markers to do syntax highlighting would fare any better than the span soup approach. I see more benefit in something like `<script type="highlightmap">` + `<pre highlightedby=highlightmap>` in which the browser would do it all by itself (+ is polyfillable)

It depends what you mean by "riddling your content". If you add a range to the DOM, it's there, as part of your DOM. Sure, the elements panel doesn't show it, but it probably will at some point, for debugging CSS highlights.

The benefit is that CSS highlights can't impact layout, so there's a performance benefit to using them rather than spans etc. How would highlightmap work? Some standardised tokenizer?