Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.
posted by martyb on Friday March 20 2020, @08:41PM   Printer-friendly
from the Do-No-Evil-Poof!-Gone. dept.

Moonchild, the lead developer of the Pale Moon browser writes:

"Dear Web Developer(s),

While, as a software developer ourselves, we understand very well that new features are exciting to use and integrate into your work, we ask that you please consider not adopting Google WebComponents in your designs. This is especially important if you are a web developer creating frameworks for websites to use.
With Google WebComponents here we mean the use of CustomElements and Shadow DOM, especially when used in combination, and in dynamically created document structures (e.g. using module loading/unloading and/or slotted elements).

Why is this important?

For several reasons, but primarily because it completely goes against the traditional structure of the web being an open and accessible place that isn't inherently locked down to opaque structures or a single client. WebComponents used "in full" (i.e. dynamically) inherently creates complex web page structures that cannot be saved, archived or even displayed outside of the designated targeted browsers (primarily Google Chrome).
One could even say that this is setting the web up for becoming fully content-controlled."

https://about.google/: "Our mission is to organize the world's information and make it universally accessible and useful"

Useful to... whom?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by quietus on Saturday March 21 2020, @01:39PM (3 children)

    by quietus (6328) on Saturday March 21 2020, @01:39PM (#973817) Journal

    There might be a solid argument for WebComponents but what, really, is the argument for ShadowDOM?

    You can already implement any number of additional DOM trees in a single webpage through the IFRAME tag. The only real addition with ShadowDOM I can see is that you can make this additional DOM tree completely hidden in locked mode (there's a way around, apparently, but I haven't tested yet).

    It's not like any ordinary user is going to check out DOM trees, so what is it? A clumsy attempt to wall off semi-proprietary code from other Javascript developers? An attempt to rig the search engine game just a bit more to Google?

    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 2) by darkfeline on Saturday March 21 2020, @10:19PM (2 children)

    by darkfeline (1030) on Saturday March 21 2020, @10:19PM (#973949) Homepage

    The same reason most programming languages have visibility rules, and why namespaces as a concept exists everywhere.

    https://stackoverflow.com/a/16677331/469721 [stackoverflow.com]

    --
    Join the SDF Public Access UNIX System today!
    • (Score: 0) by Anonymous Coward on Sunday March 22 2020, @01:24PM (1 child)

      by Anonymous Coward on Sunday March 22 2020, @01:24PM (#974119)

      CSS rule to reset cascade should be enough, IMO. However hard it is (or not), it is still less of a pain than web components.

      As for namespaces, for HTML devs namespaces are hard and the spawn of Satan, apparently. XHTML died that way (you don't have to make the whole document on parse error, but that's how it went). On the other hand @prefix and og:title and co. metadata still exist and nobody is complaining for some reason.

      • (Score: 0) by Anonymous Coward on Sunday March 22 2020, @01:26PM

        by Anonymous Coward on Sunday March 22 2020, @01:26PM (#974121)

        *make the whole document invalid