Stories
Slash Boxes
Comments

SoylentNews is people

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: 2) by darkfeline on Saturday March 21 2020, @08:20AM (6 children)

    by darkfeline (1030) on Saturday March 21 2020, @08:20AM (#973764) Homepage

    Why do you need to write a letter asking developers not to use something? Because otherwise the developers are going to use it. Why are the developers going to use it? Because it makes it much easier to get things done. Without Web Components, a lot of web app development requires doing horrible horrible things.

    > an open and accessible place that isn't inherently locked down to opaque structures

    These new standards are open, not proprietary.

    > or a single client

    Nothing is stopping other clients from implementing these standards except lack of manpower. So we're really saying "Please stop adding useful features because the rest of us can't implement them". Which is unfortunate, but that's not a compelling argument. The same argument could have been used to stop image support in web browsers, because some web browser developers didn't have the manpower to add image support. Such an argument would have lost, as the current argument will.

    > complex web page structures that cannot be saved, archived or even displayed outside of the designated targeted browsers

    Web Components is basically for web apps. Web apps can't really be saved or archived anyways; e.g., what does it mean to save the HTML view for a Google Doc? Actual web content (e.g., static HTML) is not affected. Of course, websites can hide their content in web apps rather than using well formatted HTML, but getting rid of Web Components won't stop websites from doing that. They're already doing that anyway; Web Components just allows them do it in a less insane way.

    One might object to web apps as a concept. Great! You are not going to stop people from wanting web apps.

    Let's play devil's devil's advocate for a second. Say we really do get rid of Web Components. What happens? Web devs are just going to import a 5 MB JavaScript library that basically does the same thing. If you're a small web browser, the library maintainers will probably not bother making sure you're supported (it turns out that popularity actually matters a lot).

    --
    Join the SDF Public Access UNIX System today!
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 4, Insightful) by Arik on Saturday March 21 2020, @11:59AM

    by Arik (4543) on Saturday March 21 2020, @11:59AM (#973789) Journal
    "These new standards are open, not proprietary."

    Open malware; I'm not sure that's really better.

    "Nothing is stopping other clients from implementing these standards except lack of manpower."

    Since none of them have any ethical or moral standards, you're probably right about that.

    "The same argument could have been used to stop image support in web browsers, because some web browser developers didn't have the manpower to add image support."

    Yes, that's a flawed argument, designed to fail. The much better argument is because not all browsers have a display device capable of displaying images, and not all humans have eyes capable of seeing them.

    Therefore images must always be optional elements, with appropriate alt tags.

    "Web Components is basically for web apps."

    Exactly why they shouldn't exist.

    "Web apps can't really be saved or archived anyways; e.g., what does it mean to save the HTML view for a Google Doc?"

    You really don't understand what it means to save a view?

    "getting rid of Web Components won't stop websites from doing that."

    It would be a good start, but yes, all the common browsers are loaded with other junk that would also need to be removed.

    "One might object to web apps as a concept. Great! You are not going to stop people from wanting web apps."

    True, it's computer literacy that stops that. Too bad it's in decline.

    "Web devs are just going to import a 5 MB JavaScript library that basically does the same thing."

    Which is why javascript should never be allowed by default.

    --
    If laughter is the best medicine, who are the best doctors?
  • (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?

    • (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

  • (Score: 2) by mcgrew on Saturday March 21 2020, @03:40PM

    by mcgrew (701) <publish@mcgrewbooks.com> on Saturday March 21 2020, @03:40PM (#973850) Homepage Journal

    Lazy kids should learn HTML.

    --
    mcgrewbooks.com mcgrew.info nooze.org