Re: [w3c/webcomponents] Generic programs can't reliably use/manipulate documents via the DOM (#640)

> you are missing the point, /closed/ mode is not wrongly introduced because you cannot mess with the internals, it was created precisely for this purpose: so you cannot mess with the internals.

I don't think I am. I'm trying to argue that this change is harmful, and that the justifications are not proportionate to the harms.

> You are looking at this issue with very narrow perspective of very few use cases, completely ignoring the pain of web apps developers they have been dealing with for decades: the global DOM space, where everything could affect everything. The common way, how desktop apps are developed is that you have/buy RAD with e.g. 20 components and through out the years you write/purchase/download hundreds of others and the beauty is, that those are self contained black boxes that always works together regardless of any kind of combination of any number of component from any number of developers (exceptions being possible class naming collisions and unique resources access). The second beauty of this simply is the fact, that developers who are using those components are informed "you can touch this, this is fixed and you cannot rely on that, that is internal and can change with every minor release". If you chose to somehow rely on internals and it breaks, it's your fault, not authors.

We're all in agreement on this. Notice how nobody is arguing against open shadow DOMs, which satisfy all of these things.

> If you ever tried to combine even 2 web/js component libraries together? pain... and then upgrade one...

Agreed, it's nasty. Open shadow DOMs are a great way to help improve this pain point.

> Yes /closed/ mode is something new and strange but something web platforms needs to become fully fledged application run time

Closed mode isn't new and strange: restricting access to things isn't that revolutionary a concept, and it being new doesn't make it a good idea. Perhaps shadow DOMs are new and strange, but they are a brilliant idea, something the web needs, and in no way require closed mode.

> you are effectively describing the issue you/we had for decades: "opaque 'empty' |<div>|s", applications build by divs and spans, filled by another ||divs and spans generated via XMLHTTPRequest... same diff for you (no officially described semantics what so ever), huge difference for those who write/maintain such projects.

It's actually a world of difference for me. The officially described semantics *were the DOM*. Anything you wanted or needed to know about the user-facing content could be found by looking in the DOM. Not so for closed shadow roots: you may as well replace every element with a closed shadow DOM with a `<useless-element>`.

The huge difference for writers/maintainers comes from custom elements, which can function perfectly well with an open-only shadow DOM.

> Instead of refusing several years of discussions, the way to solve this is come up with set of attributes that would be useful to expose/describe, the same way WAI-ARIA works to describe authored controls. Do you want to be informed about the fact that control is editable?

I *still* can't find anything in those several years of discussion that persuades me that closed shadow roots are a net positive.

The set of attributes that would be useful to expose/describe is the DOM. Or is there something in the DOM API that you consider not useful to have exposed?

> let's introduce editable attribute, that would be default on controls mentioned above (unless readonly/disabled) and can be used on other controls.

Let's say your shadow DOM contains a text input and a checkbox. Is it editable? If not, the behaviour is obviously broken in the input box; otherwise, behaviour is incorrect when the checkbox has focus. This is an example of a family of non-trivial problems, and the glaringly obvious solution is to have some API to expose the internal DOM.

> Solution we have now is not perfect, but we should work on it, not just simply say "it has few issues, so forget about it all"

It's a tack-on to open shadow roots, not a solution in its own right. Exposing the shadow DOM is a detail of the larger shadow roots concept, and none of the other very significant benefits of shadow roots disappear if we "forget all about it".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/640#issuecomment-301314882