Re: Shadow DOM and Fallback contents for images

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.

But I could be missing something?

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

/ Jonas

Received on Saturday, 12 October 2013 05:53:51 UTC