So htmx?
Definitely an inspiration but less opinionated.
API proposed by Chrome: Declarative partial updates
31–40 of 48 posts
Re: API proposed by Chrome: Declarative partial updates
#32Very 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.
Re: API proposed by Chrome: Declarative partial updates
#33Earlier quoted context omitted.
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.
Re: API proposed by Chrome: Declarative partial updates
#34Earlier quoted context omitted.
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.
Re: API proposed by Chrome: Declarative partial updates
#35Earlier 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.…
(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.)
Re: API proposed by Chrome: Declarative partial updates
#36Earlier quoted context omitted.
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?
Re: API proposed by Chrome: Declarative partial updates
#37Very 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 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.…
It's also a processing instruction rather than an element, which makes it possible to put it inside e.g. a element and partially replace some rows.
Re: API proposed by Chrome: Declarative partial updates
#38Very 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.
The odd thing is the non conditional "before it lands" rather than "if it lands".
Re: API proposed by Chrome: Declarative partial updates
#39Earlier quoted context omitted.
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
Re: API proposed by Chrome: Declarative partial updates
#40Earlier quoted context omitted.
> 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.…
It's also a processing instruction rather than an element, which makes it possible to put it inside e.g. a 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.