Webcomponents: Generic programs can't reliably use/manipulate documents via the DOM

Created on 8 May 2017  路  67Comments  路  Source: WICG/webcomponents

Alternative title: DOM does not reliably model document objects with closed shadow DOMs.

A generic program (ie. a program that uses the DOM to interact with a document of which it has no prior knowledge) has no reliable interface with which it can interact with and/or monitor documents. In particular:

  • the true active element in the document cannot be discovered when inside a closed shadow DOM. Thus,

    • the program cannot reason about the default action associated with eg. keydown, keyup and click events, and so cannot predict behaviour in response to user input or its own simulated input.

    • the program cannot reliably direct or redirect the focus of the page in order to perform further actions

    • a selection cannot be read (except as a string by Selection.toString) or modified (except by the non-standard Selection.modify)

  • the contents of the shadow DOM are completely inaccessible to the program.

    • Since the program has no specific knowledge of the document, it cannot reason about it in any reliable way.

    • Further -- even when the document/component provides an API for (some of) its contents -- the program has no way of knowing that it exists or how to use it.

    • A user may expect (or even direct) the program to interact with a closed shadow DOM child, since there is no perceptible difference from a normal element to them.

  • a program with access to the DOM but not the document's Javascript context cannot use any of the usually suggested techniques to circumvent this. Its only option is to proceed with broken or incomplete functionality.

Closed shadow DOMs may (or may not) be fine for document authors, who make the decision to use code including them. However, their existence and use makes the DOM an unreliable API for programs, libraries, etc. that are made to act upon a document by the user or document author.

If the DOM is supposed to be an effective API for developers other than document/component authors, then closed shadow DOMs are directly harmful (edit:) to all these developers. I propose depreciating mode and dropping closed shadow DOMs completely.

This issue generalises #354, all examples there also apply to here. (/cc @dylanb in case you're still interested).

shadow-dom
Source
picture mrmr1993
👍2

Most helpful comment

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 ||s
and ||s and mine are full of ||s and
||s. Or worse, 'empty' |

|s.
"
but you are effectively describing the issue you/we had for decades:
"opaque 'empty' |
|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
(||, |