Very funny so see such an XML like syntax right after deciding to rip XML support out of Chrome. We're watching Google reinvent XSLT in real time, but now with tons of Javascript glue for some reason.
How would that work? I think you posted something on the github but I don't think what you're conceiving here is possible with this API. It just reroutes HTML insertions from the template to a different location, there is no duplication.
The Content-Encoding header allows any page to be a literal zip-bomb. That's how early versions of Tailwind worked; you'd deliver a 50KB Brotli payload that exploded into 2MB of CSS ( https://v1.tailwindcss.com/docs/controlling-file-size ). So pages potentially being zip-bombs is already a well-accepted part of the Web platform.
So... you'll have to write Javascript that goes and replaces the additional markers with the stuff they're supposed to expand to? Because what I see there is just a state of partial evaluation, and that leads me to ask (and would lead anyone to ask) how evaluation of all substitutions can be completed...
At the moment - you can treat it as a single "search & replace", and not as a replace all. And yes JS can do the rest atm.
Hopefully introducing this (and processing instructions in general) can lead to additional enhancements in the future. But it would have to be gradual, kind of like how modern CSS evolved.
Very odd proposal. The new element syntax is perhaps the boldest choice. I wonder why they thought that was necessary. The idea of using this to defer rendering elements is also odd. So this would use a http long polling style? It really goes against several decades of progress in the web platform, where by now it's long established that you do this sort of thing with xhr. 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" as if it's a sure thing.
It would be pretty wild if this feature allowed you to go back and add/remove individual tokens from earlier in the document and re-apply all the tree construction rules, like an even more unhinged version of document.write(). I think the actual proposal is expressed in terms of moving DOM nodes around and doesn't allow stuff like this.
It's expressed in terms of changing the output of where bides are inserted. Instead of new nodes being inserted to the template elements, they are inserted where the processing instructions were found.
As far as I can tell, this is not actually allowed by the current proposal. The definition of the "find markers" algorithm in https://github.com/whatwg/html/pull/11818 requires that the <?end> marker be a sibling of the <?start> marker in the DOM, so they can't have different parents like this.
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.
> It really goes against several decades of progress in the web platform, where by now it's long established that you do this sort of thing with xhr.
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.
> The new element syntax is perhaps the boldest choice
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.
It's also a processing instruction rather than an element, which makes it possible to put it inside e.g. a <table> element and partially replace some rows.
How would you expect it to be in all the browsers before one of the browsers ships it first? We are seeking as much consensus as we can. It's an odd expectation.
Are you referring to the sentence about the polyfill? Seems like "shipping a polyfill for X before X lands in all browsers" is a reasonable thing to say? Donno
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"?
I scanned the page but didn't get -- why? What problem does it solve? Why is a browser in the business of taking care of content update? How is this better than existing solutions?
From what I read, think HTMX. HTML streams top to bottom so this proposal means out of order streaming of html things. So handles a lot of delivery/rendering stuff that's frontloaded with react/js/etc. It doesn't touch state management though.
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.
As far as I can see out-of-order streaming is only half the described functionality – there is also HTML streaming & revamped DOM parsing which does not have the positive signals that out-of-order streaming does:
Yea we've been working with Mozilla and Apple on that one as well but they haven't responded to the standards position yet. I am sure that we'll reach something that's within consensus.
Declarative partial updating "sets the stage for client-side includes." https://github.com/WICG/declarative-partial-updates
The linked article suggests a potential syntax:
That would transclude the content of /partials/footer.html in your HTML.But the road ahead for this is still quite bumpy. Here's a good video from a year ago, talking through the obstacles. https://www.youtube.com/watch?v=t0NBcve0enY
Very funny so see such an XML like syntax right after deciding to rip XML support out of Chrome. We're watching Google reinvent XSLT in real time, but now with tons of Javascript glue for some reason.
Is anyone talking about any web page being a zip bomb even without JS turned on?
How would that work? I think you posted something on the github but I don't think what you're conceiving here is possible with this API. It just reroutes HTML insertions from the template to a different location, there is no duplication.
The Content-Encoding header allows any page to be a literal zip-bomb. That's how early versions of Tailwind worked; you'd deliver a 50KB Brotli payload that exploded into 2MB of CSS ( https://v1.tailwindcss.com/docs/controlling-file-size ). So pages potentially being zip-bombs is already a well-accepted part of the Web platform.
Sure, but how is this related to out of order streaming?
<div> <?marker name="placeholder2"> </div>
<template for="placeholder2"> <?marker name="placeholder1"> <?marker name="placeholder1"> </template>
<template for="placeholder1"> <?marker name="placeholder"> <?marker name="placeholder"> </template>
<template for="placeholder"> Here is some <em>HTML content</em>! </template>
Before you couldn't make this dangerous (without JS) because there was no way to auto expand the templates
This would end up as:
<div> Here is some <em>HTML content</em>! <?marker name="placeholder"> <?marker name="placeholder1"> </div>
(only the first matching marker set is replaced.
So... you'll have to write Javascript that goes and replaces the additional markers with the stuff they're supposed to expand to? Because what I see there is just a state of partial evaluation, and that leads me to ask (and would lead anyone to ask) how evaluation of all substitutions can be completed...
At the moment - you can treat it as a single "search & replace", and not as a replace all. And yes JS can do the rest atm. Hopefully introducing this (and processing instructions in general) can lead to additional enhancements in the future. But it would have to be gradual, kind of like how modern CSS evolved.
Very odd proposal. The new element syntax is perhaps the boldest choice. I wonder why they thought that was necessary. The idea of using this to defer rendering elements is also odd. So this would use a http long polling style? It really goes against several decades of progress in the web platform, where by now it's long established that you do this sort of thing with xhr. 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" as if it's a sure thing.
The new element syntax is needed to signify DOM ranges that may cross the boundaries of HTML element trees.
Jake Archibald at Mozilla has a good video about this. https://www.youtube.com/shorts/yARSOcqOWvYI am puzzled then: so what would happen if the template will replace this island form your example with markup without closing `</em>`?
It would be pretty wild if this feature allowed you to go back and add/remove individual tokens from earlier in the document and re-apply all the tree construction rules, like an even more unhinged version of document.write(). I think the actual proposal is expressed in terms of moving DOM nodes around and doesn't allow stuff like this.
It's expressed in terms of changing the output of where bides are inserted. Instead of new nodes being inserted to the template elements, they are inserted where the processing instructions were found.
Oh nooooooo are you kidding? That's beyond horrific.
That's really really really awful
As far as I can tell, this is not actually allowed by the current proposal. The definition of the "find markers" algorithm in https://github.com/whatwg/html/pull/11818 requires that the <?end> marker be a sibling of the <?start> marker in the DOM, so they can't have different parents like this.
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.
We're working together with Jake on this. I do hope that processing instructions can help with highlights in the future.
(and this is correct, the start/end marker need to be siblings. You can't input something that starts in one parent and ends in another.)
> It really goes against several decades of progress in the web platform, where by now it's long established that you do this sort of thing with xhr.
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.
> The new element syntax is perhaps the boldest choice
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.
It's also a processing instruction rather than an element, which makes it possible to put it inside e.g. a <table> element and partially replace some rows.
I think semantically this is the perfect choice. Considering the history and intended use of PI.
As an aside, I’m still rather annoyed that web components use hyphens. I really thought colon’s and namespaces made perfect sense there.
How would you expect it to be in all the browsers before one of the browsers ships it first? We are seeking as much consensus as we can. It's an odd expectation.
The odd thing is the non conditional "before it lands" rather than "if it lands".
Are you referring to the sentence about the polyfill? Seems like "shipping a polyfill for X before X lands in all browsers" is a reasonable thing to say? Donno
Wtf?
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"?
[dead]
I scanned the page but didn't get -- why? What problem does it solve? Why is a browser in the business of taking care of content update? How is this better than existing solutions?
From what I read, think HTMX. HTML streams top to bottom so this proposal means out of order streaming of html things. So handles a lot of delivery/rendering stuff that's frontloaded with react/js/etc. It doesn't touch state management though.
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.
> How is this better than existing solutions?
For one - will not need to write JS or bundle a JS library to do this if it has native platform support.
The WICG explainers do a somewhat better job than this article.
https://github.com/WICG/declarative-partial-updates
https://github.com/WICG/declarative-partial-updates/blob/mai...
Is this a Google-only proposal? Has Mozilla provided their thoughts on the matter?
When you have questions like this, the best places to check are the "standards positions" Github repositories for Mozilla and WebKit.
https://github.com/mozilla/standards-positions/issues/1369
Mozilla hasn't officially weighed in, but one decision maker (hsivonen) did vote in favor of it.
Apple WebKit is officially in favor of it, as of just a few days ago.
https://github.com/WebKit/standards-positions/issues/628
As far as I can see out-of-order streaming is only half the described functionality – there is also HTML streaming & revamped DOM parsing which does not have the positive signals that out-of-order streaming does:
https://github.com/mozilla/standards-positions/issues/1370
https://github.com/WebKit/standards-positions/issues/629
Yea we've been working with Mozilla and Apple on that one as well but they haven't responded to the standards position yet. I am sure that we'll reach something that's within consensus.
We've worked on the design closely together with Mozilla/Apple folks and with multiple external partners that want to use it.
So htmx?
Definitely an inspiration but less opinionated.
But native