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. > 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. Otherwise, the editing breaks invariants of the element. In this <x-img> case, the author need to update the @alt attribute for each Shadow DOM modification. This is big burden for authors. Generally speaking, seamless editing will easily break the Shadow DOM encapsulation. In an ideal world, each custom element can optionally provide its own way to "edit" it. For example, <x-img> might want to have draggable handle to change the image size. But such facility would be complex and is far beyond the current spec. > **** > > 3. Accessibility – Since we will be changing the final composition of the > DOM, should accessibility be affected by it? > This should just work. And I believe it works on Blink. It implements accessibility in terms of rendering tree, where shadow DOM disappears. -- morrita
