Bug 15444 - [Shadow]: Find a way for selection to work across shadow DOM subtrees
[Shadow]: Find a way for selection to work across shadow DOM subtrees
Status: NEW
Product: WebAppsWG
Classification: Unclassified
Component: Component Model
unspecified
PC All
: P2 major
: ---
Assigned To: Hayato Ito
public-webapps-bugzilla
:
: 25038 (view as bug list)
Depends on:
Blocks: 15480
  Show dependency treegraph
 
Reported: 2012-01-06 18:40 UTC by Dimitri Glazkov
Modified: 2014-11-19 05:06 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitri Glazkov 2012-01-06 18:40:35 UTC
As specified in http://dvcs.w3.org/hg/webcomponents/rev/3fb19f98bead, window.getSelection() may never retrieve content from shadow DOM subtrees. Also, a user can't select content from both document tree and shadow DOM tree. We must fix that somehow.
Comment 1 Dimitri Glazkov 2012-01-06 20:29:06 UTC
Should we allow shadow DOM subtrees to specify whether they want to be treated as part of "as-rendered" structure or as a separate subtree?

Currently, for getSelection(), the WebKit implementation returns serialized value of the Selection object inside of a shadow DOM subtree, but node values are adjusted to avoid leaking shadow DOM nodes.
Comment 2 Steve Orvell 2013-09-05 01:50:34 UTC
This is an important UX concern. I think it's fine to limit access to selection data as defined by the spec. However, users expect to be able to select and copy text in a web page. To have that limited by invisible ShadowDOM boundaries would be very annoying. Ideally, this just always works and is separate from the encapsulation provided via ShadowDOM.
Comment 3 Dimitri Glazkov 2014-03-06 00:11:06 UTC
One thing that Jonas suggested at the recent spec review is to make our selection language non-normative. It's a tough subject, so we shouldn't freeze this into the spec. The suggestion was to have the language along these lines:

"Selection is not defined. Implementation should do their best to do what's best for them. Here's one possible, admittedly naive way: <insert current normative wording, but make it informative>"
Comment 4 Hayato Ito 2014-03-10 06:09:43 UTC
(In reply to Dimitri Glazkov from comment #3)
> One thing that Jonas suggested at the recent spec review is to make our
> selection language non-normative. It's a tough subject, so we shouldn't
> freeze this into the spec. The suggestion was to have the language along
> these lines:
> 
> "Selection is not defined. Implementation should do their best to do what's
> best for them. Here's one possible, admittedly naive way: <insert current
> normative wording, but make it informative>"

Done at 
https://github.com/w3c/webcomponents/commit/25bd518701866866a26d9d7e3e50d90a45f62d93.

I'll keep this bug open until we have a better model, that is a tough issue for us.
Comment 5 Dimitri Glazkov 2014-03-10 16:07:28 UTC
(In reply to Hayato Ito from comment #4)
> (In reply to Dimitri Glazkov from comment #3)
> > One thing that Jonas suggested at the recent spec review is to make our
> > selection language non-normative. It's a tough subject, so we shouldn't
> > freeze this into the spec. The suggestion was to have the language along
> > these lines:
> > 
> > "Selection is not defined. Implementation should do their best to do what's
> > best for them. Here's one possible, admittedly naive way: <insert current
> > normative wording, but make it informative>"
> 
> Done at 
> https://github.com/w3c/webcomponents/commit/
> 25bd518701866866a26d9d7e3e50d90a45f62d93.
> 
> I'll keep this bug open until we have a better model, that is a tough issue
> for us.

Maybe kill the 6.1.1 section title and remove the musty language from the non-normative parts?
Comment 6 Hayato Ito 2014-03-11 07:45:41 UTC
(In reply to Dimitri Glazkov from comment #5)
> Maybe kill the 6.1.1 section title and remove the musty language from the
> non-normative parts?

Sure. Done at 
https://github.com/w3c/webcomponents/commit/0887618b6f247d1d59f37fbc474313014d81f227
Comment 7 Hayato Ito 2014-11-19 05:06:12 UTC
*** Bug 25038 has been marked as a duplicate of this bug. ***