- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Fri, 11 Oct 2013 22:23:51 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Hajime Morita <morrita@google.com>, Webapps WG <public-webapps@w3.org>, Sudarshan <sudarshan.p@samsung.com>
- Message-id: <14632A4A-9520-47B4-81C4-84BDF6E582FC@apple.com>
On Oct 7, 2013, at 1:38 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Oct 7, 2013 6:56 AM, "Hajime Morrita" <morrita@google.com> wrote: > > > > Hi, > > > > I'm sorry that I didn't notice that you were talking about UA shadow DOM. It's an implementation detail and the standard won't care about that. > > > > That being said, it might be a good exercise to think about feasibility to implement <img>-like custom element which supports alternate text. > > > >> 1. Selections – Which the specification is clear. It will not allow the selection range cannot span across different node trees. This again would hinder seamless experience with selection. > > > > > > Is this needed to implement alt text? Try this on Firefox: http://jsfiddle.net/8gkAV/2/ . > > The caret just skips the alt-text. > > I think we generally consider that a bug. > I think this is a desirable behavior since the img element is "atomic". I don't think we want to let the user start editing the alt text since the user can't stylize the alt anyway. > >> 2. Editing – The spec says that the contenteditable attribute should not be propagated from the shadow host to the shadow root. Does this mean that and Shadow DOM cannot participate in editing? This I find is limiting to use shadow DOM to represent fallback content > > > > This is same as 1) above. The caret skips the alt-text. > > > > I think these are desirable behavior because, if Shadow DOM is editable in @contentEditable subtree by default, the component author (who added the shadow DOM) has to make the element definition ready for editing. > > Selection and editing are related but different. > > Text displayed on screen should by default always be selectable. The fact that it isn't in canvas for example is a bad thing. > > It is fine to enable the author to opt out of making the selection selectable, but the default should be that it is selectable > I don't think that's what the spec currently says. The way I interpret it, selection should work as if it's in a separate iframe. So the text will be selectable but the selection can only extend within the shadow DOM inside the shadow DOM, and selection will treat its shadow host as an "atomic" unit outside of it. - R. Niwa
Received on Saturday, 12 October 2013 05:24:57 UTC