3 ms·

They don't break semantics, input fields work just fine within a single Shadow DOM. You have to understand that a different library has a different workflow. If

They don't break semantics, input fields work just fine within a single Shadow DOM. You have to understand that a different library has a different workflow. If you addopt the correct workflow, you won't have any of the issues you're having. But it takes some time to learn something new.

troupo 3y ago
> They don't break semantics, input fields work just fine within a single Shadow DOM. Yes, yes they do break semantics. 1. If you just put the input in a web component, it will not appear in the form. You have to manually add it. https://web.dev/articles/more-capable-form-controls https://web.dev/articles/more-capable-form-controls 2. If you have an input in Shadow DOM, it cannot be referenced with a label from outside that shadow DOM. That breaks ARIA, and will be fixed god knows when with a new cross-root ARIA spec. This has nothing to do with libraries, or React, or whatever you imagine. These are basic browser behaviours that everyone expects to work out of the box, and they are broken. > that a different library has a different workflow. This has nothing to do with libraries. This is basic browser functionality. > If you addopt the correct workflow, you won't have any of the issues you're having. No "correct workflow" can cover the fact that these behaviours are broken, and need 20+ new specifications to fix. There's no correct workflow that will make cross-shadow ARIA work. There's no correct workflow that will make a custom component participate in forms if the author didn't add that functionality. There's no correct workflow that will make your custom button be able to work as a submit button. And so on, and so on, and so on, and so on. Edit. Note: if you took the time to actually read the report from people who shove webcomponents into the browser, you will see that even they admit how much of an issue all this is, and it has nothing to do with React or libraries, and everything to do with self-inflicted wounds by a badly thought-out design: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html (emphasis mine). Note how none of these are issues for anything built for the browser. These are issues only for the half-baked, badly-designed web components. --- start quote --- This document tries to highlight the main features that are lacking from the web components spec that either block adoption for more developers and frameworks, or cause pain points for existing developers. It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM. ... Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patterns outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. ... The form-associated APIs currently have no way for a developer to behave as a custom submit button. It is currently unclear how form-associated custom elements should participate in the autocomplete lifecycle despite there being an API for that purpose. ... Many web components could be implemented without JavaScript, taking advantage of encapsulated DOM and styles. However, web components cannot currently be rendered by users who have JavaScript disabled. ... ad infinitum ... --- end quote ---
- gitaarik 3y ago
  I will read those links you referenced later. But what I think about the Shadow DOM is that that is for me actually the killer feature. That prevents a lot of weird issues. But it also brings limitations to methods of how web developers are used to do things, like applying styles globally, or having some sort of dependency between deeply nested elements, crossing the Shadow DOM when using Web Components. What people usually try to do is to somehow open up the Shadow DOM for certain things, to make some things allowed to pass, or global. But I think might be a bit holding on to an old familiar habit. And I think there are better ways of structuring a project with Web Component in mind. For example, you can create a base class from which all your components extend, and put the base style in that base class, and have your components add style on top of that. I implemented this method in a tiny library which makes it easy to use [0]. But yeah it is hard for most developers to adopt a new way of thinking. And as long as the new way doesn't provide that much improvement over the old way, it won't get adopted. But I think the idea of Web Components still needs to be integrated more in the web dev community. And maybe they will manage to make some changes to make the adoption easier. And besides that, of course Web Components still have lots of other issues. But for me it has reached a point where I don't feel the need for React anymore. I rather live with some quirks in Lit than doing things with React, which just feels clumsy to me now. [0]: https://github.com/gitaarik/lit-style https://github.com/gitaarik/lit-style
  - troupo 3y ago
    > But yeah it is hard for most developers to adopt a new way of thinking. It's not "a new way of thinking". Things like functioning inputs, buttons, and ARIA are basic browser functionality. > And as long as the new way doesn't provide that much improvement over the old way, it won't get adopted. Not only it doesn't provide improvment, it needs 20+ new web standards to fix the issues that literally nothing else has. I've gone ahead and quoted directly from the report made by people who keep developing these specs. And yet you've ignored literally everything I wrote and keep answering something entirely else. > of course Web Components still have lots of other issues. Indeed, they do. I listed a bunch of them. And yet you keep pretending that I'm talking about "React workflows" or something. This is pointless until your read what I write, and not what you think that I write. Until then, adieu.

troupo 3y ago

> They don't break semantics, input fields work just fine within a single Shadow DOM. Yes, yes they do break semantics. 1. If you just put the input in a web component, it will not appear in the form. You have to manually add it. https://web.dev/articles/more-capable-form-controls https://web.dev/articles/more-capable-form-controls 2. If you have an input in Shadow DOM, it cannot be referenced with a label from outside that shadow DOM. That breaks ARIA, and will be fixed god knows when with a new cross-root ARIA spec. This has nothing to do with libraries, or React, or whatever you imagine. These are basic browser behaviours that everyone expects to work out of the box, and they are broken. > that a different library has a different workflow. This has nothing to do with libraries. This is basic browser functionality. > If you addopt the correct workflow, you won't have any of the issues you're having. No "correct workflow" can cover the fact that these behaviours are broken, and need 20+ new specifications to fix. There's no correct workflow that will make cross-shadow ARIA work. There's no correct workflow that will make a custom component participate in forms if the author didn't add that functionality. There's no correct workflow that will make your custom button be able to work as a submit button. And so on, and so on, and so on, and so on. Edit. Note: if you took the time to actually read the report from people who shove webcomponents into the browser, you will see that even they admit how much of an issue all this is, and it has nothing to do with React or libraries, and everything to do with self-inflicted wounds by a badly thought-out design: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html (emphasis mine). Note how none of these are issues for anything built for the browser. These are issues only for the half-baked, badly-designed web components. --- start quote --- This document tries to highlight the main features that are lacking from the web components spec that either block adoption for more developers and frameworks, or cause pain points for existing developers. It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM. ... Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patterns outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. ... The form-associated APIs currently have no way for a developer to behave as a custom submit button. It is currently unclear how form-associated custom elements should participate in the autocomplete lifecycle despite there being an API for that purpose. ... Many web components could be implemented without JavaScript, taking advantage of encapsulated DOM and styles. However, web components cannot currently be rendered by users who have JavaScript disabled. ... ad infinitum ... --- end quote ---

gitaarik 3y ago
I will read those links you referenced later. But what I think about the Shadow DOM is that that is for me actually the killer feature. That prevents a lot of weird issues. But it also brings limitations to methods of how web developers are used to do things, like applying styles globally, or having some sort of dependency between deeply nested elements, crossing the Shadow DOM when using Web Components. What people usually try to do is to somehow open up the Shadow DOM for certain things, to make some things allowed to pass, or global. But I think might be a bit holding on to an old familiar habit. And I think there are better ways of structuring a project with Web Component in mind. For example, you can create a base class from which all your components extend, and put the base style in that base class, and have your components add style on top of that. I implemented this method in a tiny library which makes it easy to use [0]. But yeah it is hard for most developers to adopt a new way of thinking. And as long as the new way doesn't provide that much improvement over the old way, it won't get adopted. But I think the idea of Web Components still needs to be integrated more in the web dev community. And maybe they will manage to make some changes to make the adoption easier. And besides that, of course Web Components still have lots of other issues. But for me it has reached a point where I don't feel the need for React anymore. I rather live with some quirks in Lit than doing things with React, which just feels clumsy to me now. [0]: https://github.com/gitaarik/lit-style https://github.com/gitaarik/lit-style
- troupo 3y ago
  > But yeah it is hard for most developers to adopt a new way of thinking. It's not "a new way of thinking". Things like functioning inputs, buttons, and ARIA are basic browser functionality. > And as long as the new way doesn't provide that much improvement over the old way, it won't get adopted. Not only it doesn't provide improvment, it needs 20+ new web standards to fix the issues that literally nothing else has. I've gone ahead and quoted directly from the report made by people who keep developing these specs. And yet you've ignored literally everything I wrote and keep answering something entirely else. > of course Web Components still have lots of other issues. Indeed, they do. I listed a bunch of them. And yet you keep pretending that I'm talking about "React workflows" or something. This is pointless until your read what I write, and not what you think that I write. Until then, adieu.