Re: Shadow DOM and Fallback contents for images

On Oct 11, 2013, at 10:52 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 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.
> 
> Note that this part is about selection, not editing. I don't see any
> reason to treat the alt text different from any other text. I.e. that
> the user can select character-by-character by default, but that this
> can be overridden by the author if desired.

If I'm not mistaken, how alternative text is presented is up to UA vendors.  Given that, I don't think we should mandate one way or another with respect to this behavior.

A more important question is what happens to selection inside a shadow DOM created by the author.

>>>> 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
> 
> Ugh, my text here is gibberish :)
> 
> I think I intended to say:
> 
> "It is fine to enable the author to opt out of making the shadow
> content 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.
> 
> Sounds like we should change the spec. Unless we have a good reason to
> treat selection as atomic?

One good reason is that the editing specification needs to be aware of shadow DOM and various operations such as deletion and copy needs to take care of the shadow DOM boundaries.  e.g. what should UA copy if selection ends points are in two different shadow trees.

Requiring each selection end to be in the same shadow tree solves this problem.

- R. Niwa

Received on Monday, 14 October 2013 04:12:10 UTC