[Bug 27775] [Shadow]: Define the behavior of *closed* shadow trees.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775

--- Comment #2 from Hayato Ito <hayato@chromium.org> ---
(In reply to Olli Pettay from comment #1)
> (In reply to Hayato Ito from comment #0)
> > I am wondering whether it is worth or not to expose this *hidden* concept,
> > UA shadow trees, clearly in the spec, as a *closed shadow tree*, a tentative
> > name borrowed from the another thread, so that we can explain the behavior
> > of builtin elements in terms of Shadow DOM.
> Do we really want that? Wouldn't it bound implementations to use similar
> structures for 
> form elements.

Yeah, I thought that "we don't want this" because such a shadow tree has been
used as an implementation detail of some of builtin elements. No one should
take care of such an implementation detail, basically.
However, the recent movement, 'HTML as Custom Element', made me reconsider this
topic again. I feel uncomfortable in the current Shadow DOM spec because the
spec can't explain an existence of such an internally-used shadow tree in a
well-defined manner, even though the spec mentions it as a UA-provided shadow
tree, especially in the Section 8, "HTML Elements and Their Shadow Trees".


> 
> > In Blink, as some of you might know, ShadowRoot object has an enum
> > internally, UserAgentShadowRoot or AuthorShadowRoot. Some builtin elements,
> > such as <video> or <input>, use UserAgentShadowRoot in their implementation
> > as you imagine.
> > Currently, the behavior of this kind of shadow trees is only explained by
> > Blink's C++ code.
> > It'd be nice that I could write down a well-defined behavior of a closed
> > shadow tree somewhere. That should be in the spec. I don't want other
> > browser vendors to do a kind of *reverse-engineering*.
> 
> But why do we need to spec browser specific behavior? Maybe I'm missing what
> you're proposing here.

My bad. It's not a goal to define how a builtin element should be implemented
in the spec. That's up to UA.
My intention of filing this issue is just to define the behavior of closed
shadow trees clearly. It's up to UA how UA makes use of it. UA doesn't have to
use shadow trees if a shadow tree doesn't fit.

But, wait,,, it's against "the Section 8, HTML Elements and Their Shadow
Trees".
I think the original goal of Section 8 is to define how some of builtin
elements should behave if Web Developers call element.createShadowRoot() for
that. That's one of tough issues. 


> 
> 
> One good thing though is that if 'closed shadow tree' is spec'ed, it might
> force us to spec
> how proper encapsulation and information hiding works.

Good point. So far, we've succeeded to hide the implementation detail of
<video> elements, using UA-provided shadow trees. I hope this issue is the good
first step to consider this kind of topic.

> So maybe we do want it after all, but just not spec what kind of closed
> shadow tree various elements may have.
> That would be up to the UA.
> Or... maybe we shouldn't define 'closed shadow tree', but something like
> 'domain specific shadow tree', and UA would just happen to form a 'system'
> domain itself.
> Assuming 'dsst' would hide information by default, and could opt-in to
> not-hide, UA shadow DOM would just work
> by default. So, I think we want this, and no special 'closed shadow tree'

An Interesting idea. From the view of such a domain specific shadow tree, I am
feeling that the current shadow tree might be considered as one of domain
specific shadow tree, where the domain is 'Author'.

We might want to define the default behavior of two instances of domain
specific shadow trees, 'System and Author', at least. Any other better
interpretation of your idea?

Anyway, I don't have a plan to work on this task soon because I'm not confident
about how we should prioritize this task. I've not heard any urgent requests
for spec-cing *closed* shadow trees so far.

> 
> 
> > - Needs to discuss:
> >   Whether or not to allow calling Element.createShadowRoot() for the shadow
> > host which has the closed youngest shadow tree.
> >   If we allow it, we might have to consider the followings also:
> I think the end goal should be to allow it. There shouldn't be special cases
> or inconsistencies.

Agreed. That's exactly the original goal of "Section 8".

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 8 January 2015 07:48:48 UTC