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

>>> I think the same point as for C++ and Java applies. It's not a 'thing' as far is the user is concerned. Go wild.
>>
>> Well, then that same argument holds for closed shadow trees.
>
>Hardly. The DOM is always meaningful, since it represents the user interface/user-facing content in a standardised way. If you give me a DOM (and the relevant styles, admittedly), I can tell you what it represents and do useful things with it. Not so with arbitrary internal private states -- their representation is only meaningful in the context of that specific program.

That isn't quite true. A li can be used to represent either an item in a shooping list, a file in the list of uploaded file, etc...
The semantics of each element and content depends heavily on the context in which it exists.

>> It's not really a thing to go into some component's shadow tree and mess with it.
>
>I think you may have misinterpreted me: I meant that ECMAScript internal state isn't a virtual object in the mind of the user. DOM elements certainly are. Nonetheless, this is patently false; programs already do this. That you don't like it doesn't make it not a 'thing'. 

Well, not really. In the presence of closed shadow trees, those scripts don't / can't do this.
Also, just because it's currently done, it's a good idea.

For example, we used to write code with goto and label everywhere before higher-level languages were invented.
Do you think a language which hides goto is harmful because it disallows certain use cases?

>The thing that's made the web so powerful up until now *is* the DOM. Search engines rely on the DOM. Libraries rely on the DOM. Extensions rely on the DOM. Accessibility programs rely on the DOM. People have been able to re-use huge amounts of code because the underlying objects are all the same, and all accessible.
>
>This all dies when your documents are full of opaque `<main-content>`s and `<autocomplete-input>`s and mine are full of `<article-body>`s and `<filter-dropdown>`s. Or worse, 'empty' `<div>`s. The objects in the DOM can't reliably convey any meaning to cross-document programs, unless they learn to read the developers' minds. This ruins the web.

We already live in that world. People are writing apps with a bunch of divs and spans,
and that's completely orthogonal to the concept of closed shadow trees.

>I'll quote my example from above here, in the hopes that you have a response to it:
>
>> Suppose a library wanted to provide an easy way to attach keyboard shortcuts to a page, except when the user is entering text into an input (`<input>`, `<textarea>` `<* contenteditable="true">`, etc.). This library will function incorrectly (ie. interpret input-generating keypresses as keyboard shortcuts) for any pages containing an input inside a closed shadow DOM.

What happens when one of the components on a page already implemtns its own keyboard shortcuts?
With an open shadow tree or without a shadow tree at all, this library will go in and add new keyboard shortcuts.

This is why it's very important for each component to opt-in to whatever polyfill or library each page is importing. The idea of automatically enhancing an arbitrary component written by a third party quickly fails in practice.

-- 
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-301613208