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

Hi,

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

If you ever tried to combine even 2 web/js component libraries together? 
pain... and then upgrade one... Yes /closed/ mode is something new and 
strange but something web platforms needs to become fully fledged 
application run time (yes, we could somehow do this before... you can 
walk to Rome, but I assume air plain or car is much better solution).

You are arguing that
"
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.
"
but 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.

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?
"
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.
"
let's introduce editable attribute, that would be default on controls 
mentioned above (unless readonly/disabled) and can be used on other 
controls. This is the way how it worked before (e.g. input extensions) 
and how it could work again. If you have experience with this, if you 
have some numbers of those attributes in mind, offer them.

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"


-- 

          Bronislav Klučka



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