[Bug 27401] [Shadow]: Fully explore composition

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

--- Comment #3 from Olli Pettay <bugs@pettay.fi> ---
(In reply to Dimitri Glazkov (afk until Dec 1, 2014) from comment #2)
> > > For example, the question "when should I put things in Shadow DOM?" is a
> > > symptom of approaching the problem from the wrong angle.
> > Why?
> 
> See the rest of that sentence, it meant to all work together :)
It still doesn't say why 
'the question "when should I put things in Shadow DOM?" is a
 symptom of approaching the problem from the wrong angle'


> Exactly my point. The question of when I should put things in a class is
> along the same lines -- you do it when it's useful for your software
> engineering needs.
Hmm, somehow I'm misreading you here, I think. Since yes, this is all about
usefulness. But the question is what are the use cases. The level of
information hiding and encapsulation
affect quite a bit to the possible use cases.



> I am realizing now that I severely over-constrained the problem space by
> trying to solve both "explain HTML form elements" and "enable composition"
> with the same primitive.
That indeed may have lead to some confusion. It has not been too clear always
what
Shadow DOM is aimed for.


> Yes! This is effectively what Shadow DOM and custom elements do today. The
> custom elements are the insertion points. 
But why the need for shadow DOM then? Why the need for making the platform much
more complicated when
something simpler might have been enough. (if we didn't have shadow DOM, we
wouldn't have to modify event dispatch, nor go through
all the spec and their use of is-in-document etc.)

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

Received on Sunday, 23 November 2014 17:15:06 UTC