I can't really tell how you'd even use this. Is it supposed to be some sort of micro-optimisation thing to do with how HTML is parsed (now you can download chunks out of order, presumably with some performance gains since it's browser native?).
When I saw the title I was hoping it was going to be a very simple React-like API for constantly updating parts of the DOM with maximum performance since the browser devs are now involved. It doesn't look like that's what this is at all. And all these years later I'm still wondering why browsers aren't implementing an API like that when it's been obvious for over a decade now that real-time DOM updates are a vital browser feature that needs to be performant, and that developers vastly prefer a declarative model to a procedural one. Why after 15-16 years are we still building 100 versions of the same abstraction in user-land to turn Element.append into "refresh these elements when this data changes"?
<p>
<em>Some <?start name="hl"?>text</em>
to replace<?end name="hl"?>.
</p>
<p>
<em>Some replaced text
</p>
That's really really really awful
Well, you're allowed to write it, but the browser will just ignore the <?end> marker. The range will end at the </em> tag, the same place https://github.com/WICG/declarative-partial-updates/blob/mai... says it goes by default if you don't write the <?end> at all. (That default wouldn't make a ton of sense if patch ranges were allowed to break out of their parent elements like this.)
Jake Archibald thinks it'd be cool to use a similar syntax to do CSS highlights, but there are other problems with that (like not being able to create overlapping ranges), and he's not on the Chrome team that's pushing this proposal.
Well yes, because no better technology existed. I don't see what kind if experience proved that writing a million imperative ad-hoc solutions for out-of-order loading would be better than a standardized solution.
Probably to not break anything in older browsers which hasn't adopted it yet: new tag will be simply ignored, that's my thinking
> I'm amazed that they even put this in chrome, let along are saying things like "let sites use this new functionality right away even before this lands in other browsers"
It is behind the flag, like every other new proposal they made. Even though some dev would like to use it right now (for regular site visitors, not for self testing), she can't.
As an aside, I’m still rather annoyed that web components use hyphens. I really thought colon’s and namespaces made perfect sense there.
Don't use chrome anymore but, I dunno if all browsers came to the table and unified behind something like this I'd be all about it. Most of the web stacks seem like some weird polished turd solution where we started frontloading more and more onto javascript, so I am amusingly not against this proposal. Feel like it could be a step into a better direction for web technologies, which feel like a very odd/lost ship in the world of software.
For one - will not need to write JS or bundle a JS library to do this if it has native platform support.
https://github.com/WICG/declarative-partial-updates
https://github.com/WICG/declarative-partial-updates/blob/mai...