Not so quick. I quote: “[…] creates complex web page structures that cannot be saved, archived or even displayed outside of the designated targeted browsers”. The third of those is about the resources to maintain a browser, the first and second are about what users are able to do with the page.
I like archive.org. You may think that site’s a detail, not worth considering, only rendering in the browser is what matters. If so, I respectfully disagree.
I upvoted for the note about Chromium… do you mean that using those “web components” do not add more third-party components, even components that are necessary in order to understand the page?
I mean it’s just some nice JS APIs, not something that fundamentally changes how web pages work.
It’s actually more friendly to normal “document” pages with some “progressive enhancement” JS elements than frameworks with custom ad-hoc component models like React are. You can build similar full client-side apps with both, but those frameworks encourage that a bit more. It’s a bit harder to instantiate a React component inside a normal static document. Not hard but you do need to write a little script that would select an element and instantiate React there. Like you would do <script>$(".thingy").someGallery({config:"stuff"})</script> with jQuery plugins back in the day. With web components you can just have markup like <fancy-gallery><img ...><img ...></fancy-gallery> and the element would work without writing a single line of JS (only loading the script that registers the element itself).
That sounds as if it tends to complicate rather than simplify static analysis of the web page. I assume that services like archive.org use static analysis, carefully and conservatively I’m sure.
That is just factually incorrect. You can in fact save and/or archive a page with WebComponents. All browsers except for niche ones support their display. Nothing in that open letter is factual.
Chrome is rapidly becoming the new IE as Google keeps adding things to it without even bothering to go through W3C. This leaves other browsers playing catch up with Chrome putting them at a direct disadvantage. I think it’s a really dangerous situation to end up with only a single viable browser engine implementation that’s tightly controlled by an advertising company.
Except this is standardized, supported by every major browser, and legitimately useful (not some WebUSB spec only useful for Chromebooks). I don’t like the Google monopoly as much as everyone else, but let’s not get angry over imagined reasons.
It creates problems for people who […], need special web clients for e.g. limited physical accessibility
These days, people with disabilities can easily use mainstream browsers alongside whatever assistive technology (e.g. screen reader or alternative input method) they need, and most take this approach. We’ve come a long way from the days when, for example, blind people used Lynx or some obscure browser developed specifically for them. So there’s no need to use accessibility as a reason to keep supporting non-mainstream browsers.
One of the main reasons people want to use shadow DOM these days is because it allows them to designate CSS styling that only applies to their little corner of the web page it is in (e.g. a widget).
This is super useful, but Web Components or the Shadow DOM certainly isn’t the only way to go about it.
The Yesod web framework provides this functionality, and it works really well. We make heavy use of it in our project. It has none of the drawbacks listed in the above article that apply to Web Components.
From my perusing of the discussion on HN, it seems to consensus is that while it’s possible to use web frameworks to achieve this functionality, having it “built in” makes it even easier.
The issue from Pale Moon’s view is that they don’t have the resources to develop their browser to handle the new components , so they’d like them to not be used.
Last I checked the stuff surrounding web components works in all web browsers.
This is essentially Pale Moon developers admitting “we don’t have the resources to maintain a browser, please don’t use web standards”.
Not so quick. I quote: “[…] creates complex web page structures that cannot be saved, archived or even displayed outside of the designated targeted browsers”. The third of those is about the resources to maintain a browser, the first and second are about what users are able to do with the page.
I like archive.org. You may think that site’s a detail, not worth considering, only rendering in the browser is what matters. If so, I respectfully disagree.
This is BS though. Nothing about web components prevents saving of pages. IIRC this comes from an old bug in Chromium that was fixed a long time ago.
I upvoted for the note about Chromium… do you mean that using those “web components” do not add more third-party components, even components that are necessary in order to understand the page?
I mean it’s just some nice JS APIs, not something that fundamentally changes how web pages work.
It’s actually more friendly to normal “document” pages with some “progressive enhancement” JS elements than frameworks with custom ad-hoc component models like React are. You can build similar full client-side apps with both, but those frameworks encourage that a bit more. It’s a bit harder to instantiate a React component inside a normal static document. Not hard but you do need to write a little script that would select an element and instantiate React there. Like you would do
<script>$(".thingy").someGallery({config:"stuff"})</script>with jQuery plugins back in the day. With web components you can just have markup like<fancy-gallery><img ...><img ...></fancy-gallery>and the element would work without writing a single line of JS (only loading the script that registers the element itself).That sounds as if it tends to complicate rather than simplify static analysis of the web page. I assume that services like archive.org use static analysis, carefully and conservatively I’m sure.
That is just factually incorrect. You can in fact save and/or archive a page with WebComponents. All browsers except for niche ones support their display. Nothing in that open letter is factual.
Chrome is rapidly becoming the new IE as Google keeps adding things to it without even bothering to go through W3C. This leaves other browsers playing catch up with Chrome putting them at a direct disadvantage. I think it’s a really dangerous situation to end up with only a single viable browser engine implementation that’s tightly controlled by an advertising company.
Except this is standardized, supported by every major browser, and legitimately useful (not some WebUSB spec only useful for Chromebooks). I don’t like the Google monopoly as much as everyone else, but let’s not get angry over imagined reasons.
ah, didn’t see that it got standardized
These days, people with disabilities can easily use mainstream browsers alongside whatever assistive technology (e.g. screen reader or alternative input method) they need, and most take this approach. We’ve come a long way from the days when, for example, blind people used Lynx or some obscure browser developed specifically for them. So there’s no need to use accessibility as a reason to keep supporting non-mainstream browsers.
This is super useful, but Web Components or the Shadow DOM certainly isn’t the only way to go about it.
The Yesod web framework provides this functionality, and it works really well. We make heavy use of it in our project. It has none of the drawbacks listed in the above article that apply to Web Components.
From my perusing of the discussion on HN, it seems to consensus is that while it’s possible to use web frameworks to achieve this functionality, having it “built in” makes it even easier.
The issue from Pale Moon’s view is that they don’t have the resources to develop their browser to handle the new components , so they’d like them to not be used.