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

I'm concerned that if the spec shipped as you described, that it would not
be useful enough to developers to bother using it at all.

Without useful redistributions, authors can't use composition of web
components very well without scripting.
At that point, it's not much better than just leaving it all in the
document tree.

I too would like to see the Web develop organically bits at a time, but
ShadowDOM fundamentally changes how the DOM works.

This feels like at the inception of the automobile, deciding that a
gasoline engine is too complicated and instead selling customers a horse
hitched to body. We won't get good feedback on developer uptake if we take
out the biggest gamechanger.


On Tue, Apr 30, 2013 at 11:10 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

> 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 <arv@chromium.org> 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 <rniwa@apple.com> wrote:
>
> On Apr 25, 2013, at 2:42 PM, Edward O'Connor <eoconnor@apple.com> 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
>
>
>