Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

Hi Ted!

Thanks for the kudos. We Shadow DOM elves are hard at work on making
the world a better place :)

I think you're raising good questions. I am sensitive of the fact that
you are just starting the journey into the shadows and volunteer to be
your Aragorn.

Yes, Shadow DOM is fairly complex, but it is also the minimal set of
machinery that is actually useful. We elves had gone through the
extensive process of making sure of that.

If we take away multiple insertion points, we significantly reduce
authors' ability to build useful controls. For example, the control
that uses insertion points in WebKit now is the <details> element,
which needs two. So would a properly implemented <fieldset>
If you're planning to build an accordion, you need more than one
insertion point
Same for even the simplest tab view control, let alone the one that
manages tab overflow

As Scott pointed out in his succinct reply, removing multiple
insertion points does not eliminate the need for reprojection. In our
elvish experience, it took literally seconds for control authors to
write this code:

<button is="my-funky-button">

At which point, the lack of reprojection bites the author in the rear
soft tissue.

As far as implementation complexity, <content select>, distribution
APIs, and <shadow> are trivial, compared to the event handling and
representation of the composed tree. Hoping to alleviate this, I wrote
all event-related handling as imperatively as I could.

One thing where we could definitely help the implementers is in
uncondensing the spec. I think today's spec, though technically
correct, is way too dense and is in need of good refactoring. I am
planning to tackle this very soon and would appreciate any

Thanks again!


Received on Monday, 29 April 2013 22:00:51 UTC