16 ms·

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

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.

dfabulich 4mo ago
The new element syntax is needed to signify DOM ranges that may cross the boundaries of HTML element trees. Some <?start name="hl"?>text to replace<?end name="hl"?>. Jake Archibald at Mozilla has a good video about this. https://www.youtube.com/shorts/yARSOcqOWvY https://www.youtube.com/shorts/yARSOcqOWvY
- kkarpkkarp 4mo ago
 I am puzzled then: so what would happen if the template will replace this island form your example with markup without closing ``?
 - dfabulich 4mo ago
 Some replaced text Which, by the HTML standard, will automatically close the `` as the `` closes.
 - csande17 4mo ago
 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.
 - nomsternom 4mo ago
 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.
- conartist6 4mo ago
 Oh nooooooo are you kidding? That's beyond horrific. That's really really really awful
 - csande17 4mo ago
 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 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 tag, the same place https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#proposed-markup 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.
 - nomsternom 4mo ago
 We're working together with Jake on this. I do hope that processing instructions can help with highlights in the future.
 - nomsternom 4mo ago
 (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.)
kkarpkkarp 4mo ago
> 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.
- deleted 4mo ago
 [deleted]
- deleted 4mo ago
 [deleted]
- nomsternom 4mo ago
 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.
 - mgr86 4mo ago
 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.
xg15 4mo ago
> 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.
nomsternom 4mo ago
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.
- nofriend 4mo ago
  The odd thing is the non conditional "before it lands" rather than "if it lands".
  - nomsternom 4mo ago
    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

dfabulich 4mo ago

The new element syntax is needed to signify DOM ranges that may cross the boundaries of HTML element trees. Some <?start name="hl"?>text to replace<?end name="hl"?>. Jake Archibald at Mozilla has a good video about this. https://www.youtube.com/shorts/yARSOcqOWvY https://www.youtube.com/shorts/yARSOcqOWvY

kkarpkkarp 4mo ago
I am puzzled then: so what would happen if the template will replace this island form your example with markup without closing ``?
- dfabulich 4mo ago
 Some replaced text Which, by the HTML standard, will automatically close the `` as the `` closes.
 - csande17 4mo ago
 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.
 - nomsternom 4mo ago
 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.
conartist6 4mo ago
Oh nooooooo are you kidding? That's beyond horrific. That's really really really awful
- csande17 4mo ago
 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 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 tag, the same place https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#proposed-markup 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.
 - nomsternom 4mo ago
 We're working together with Jake on this. I do hope that processing instructions can help with highlights in the future.
 - nomsternom 4mo ago
 (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.)

kkarpkkarp 4mo ago

> 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.

deleted 4mo ago
[deleted]
deleted 4mo ago
[deleted]
nomsternom 4mo ago
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.
- mgr86 4mo ago
 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.

xg15 4mo ago

> 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.

nomsternom 4mo ago

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.

nofriend 4mo ago
The odd thing is the non conditional "before it lands" rather than "if it lands".
- nomsternom 4mo ago
  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