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.
API proposed by Chrome: Declarative partial updates
21–30 of 48 posts
Re: API proposed by Chrome: Declarative partial updates
#22Very 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…
The new element syntax is needed to signify DOM ranges that may cross the boundaries of HTML element trees. Some text to replace . Jake Archibald at Mozilla has a good video about this. https://www.youtube.com/shorts/yARSOcqOWvY
Oh nooooooo are you kidding? That's beyond horrific.
That's really really really awful
Re: API proposed by Chrome: Declarative partial updates
#23Very 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?
Re: API proposed by Chrome: Declarative partial updates
#24Earlier quoted context omitted.
The new element syntax is needed to signify DOM ranges that may cross the boundaries of HTML element trees. Some text to replace . Jake Archibald at Mozilla has a good video about this. https://www.youtube.com/shorts/yARSOcqOWvY
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 marker be a sibling of the 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 marker. The range will end at the tag, the same place https://github.com/WICG/declarative-partial-updates/blob/mai... says it goes by default if you don't write the 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.
Re: API proposed by Chrome: Declarative partial updates
#25Earlier quoted context omitted.
I am puzzled then: so what would happen if the template will replace this island form your example with markup without closing ` `?
Some replaced text Which, by the HTML standard, will automatically close the ` ` as the ` ` closes.
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.
Re: API proposed by Chrome: Declarative partial updates
#26Very 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…
> 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.
Re: API proposed by Chrome: Declarative partial updates
#27Earlier quoted context omitted.
Some replaced text Which, by the HTML standard, will automatically close the ` ` as the ` ` closes.
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.
Re: API proposed by Chrome: Declarative partial updates
#28Earlier quoted context omitted.
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 marker be a sibling of the 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 marker. The range will end at the tag, the same place https://github.…
We're working together with Jake on this. I do hope that processing instructions can help with highlights in the future.
Re: API proposed by Chrome: Declarative partial updates
#29Very 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…
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.
Re: API proposed by Chrome: Declarative partial updates
#30Is this a Google-only proposal? Has Mozilla provided their thoughts on the matter?
We've worked on the design closely together with Mozilla/Apple folks and with multiple external partners that want to use it.