Re: Shadow DOM and Fallback contents for images

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.

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

How Shadow content interacts with editable text is definitely an
interesting question. Though one that is a bit hard to answer given how
poorly contentEditable is specified.

/ Jonas