Re: Shadow DOM and Fallback contents for images

On Tue, Oct 15, 2013 at 2:39 AM, Hajime Morrita <morrita@google.com> wrote:
> The text in shadows are select-able, and it behaves kind of like iframes as
> Ryosuke mentioned.
>
> I'm not sure if these are clear from the current draft, but points are:
>
> - Users can select a part of the shadow tree.
>
> - If selected range is in a shadow tree, it isn't accessible (in API sense)
> outside the shadow. For one outside the shadow, that is
> document.getSelection(), the selection is represented as a range which
> selects the shadow host. Inside shadow, that is ShadowRoot.getSelection(),
> the selection points the node inside the shadow. This is how encapsulation
> works with Shadow DOM.
>   It's just about API. The UA knows what part of the text is selected. Thus
> things like clipboards should work as expected.
>
> - The selection cannot cross the shadow boundary. Both ends of the selection
> should be in a same tree. I think this restriction is mainly for simplicity.
>
> Does this make sense?

Yup, this sounds great. So selecting text inside shadow content will
look exactly like selecting text text from outside the shadow content
from a user's point of view.

/ Jonas


> On Mon, Oct 14, 2013 at 1:19 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> > 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.
>>
>> Again, most selections are not related to editing.
>>
>> I think that if we made all text inside shadow content only selectable
>> as a whole, that would make shadow content a second class citizen in
>> the page. The result would be that authors actively avoid putting text
>> inside shadow content since the user experience would be so
>> surprising.
>>
>> As a user, I'm always annoyed when I can't interact with text normally.
>>
>> / Jonas
>
>
>
>
> --
> morrita

Received on Thursday, 17 October 2013 00:16:32 UTC