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

I'm concerned that we're over engineering here.

I do understand adding reprojection significantly reduces the need to write author scripts,
but I would like to see us implement the truly minimal set of features, have all browsers ship it,
and see how authors, particularly that of high profile websites such as Facebook and Twitter use it in real life.

Granted, I know people have talked to developers and got feedback, etc… but nothing beats the use in production code.

I'd like to see the Web platform improve organically by means of positive feedback loop between browser vendors
and Web developers. Take position: sticky for example. We saw web developers using JavaScript and CSS to
emulate a particular mode of layout so we've added a new CSS value to natively support that.

For reprojection, I don't think we have sufficient data points to tell how exactly authors are going to use or
what they're going to create with shadow DOM, and what percentage of common use cases reprojections address.

On Apr 30, 2013, at 10:52 AM, Erik Arvidsson <> wrote:

> The thing about reprojection is that it makes implementers life harder
> but it makes developers life easy. I'd rather have us do the hard work
> here.
> For the record, we have two independent implementations of the Shadow
> DOM spec so that should debunk some of the myths that this is too hard
> to implement and maintain.
> On Tue, Apr 30, 2013 at 10:37 AM, Ryosuke Niwa <> wrote:
>> On Apr 25, 2013, at 2:42 PM, Edward O'Connor <> wrote:
>>> First off, thanks to Dimitri and others for all the great work on Shadow
>>> DOM and the other pieces of Web Components. While I'm very enthusiastic
>>> about Shadow DOM in the abstract, I think things have gotten really
>>> complex, and I'd like to seriously propose that we simplify the feature
>>> for 1.0, and defer some complexity to the next level.
>>> I think we can address most of the use cases of shadow DOM while
>>> seriously reducing the complexity of the feature by making one change:
>>> What if we only allowed one insertion point in the shadow DOM? Having
>>> just 1 insertion point would let us push (most? all?) of this complexity
>>> off to level 2:
>>> * distribution, getDistributedNodes(), etc.
>>> * selector fragments & matching criteria
>>> * /select/ combinator
>>> * <content select>
>>> * <shadow> ?
>>> * reprojection
>> I'm in favor of removing all forms of redistributions except the one where the entire content is inserted at exactly one location.
>> This will reduce things authors can do but it will considerably reduce the implementation complexity and eliminates almost all performance penalties.
>> - R. Niwa
> -- 
> erik

Received on Tuesday, 30 April 2013 18:10:53 UTC