W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Mozilla and the Shadow DOM

From: Wilson Page <wilsonpage@me.com>
Date: Thu, 16 Apr 2015 15:07:04 +0100
Message-ID: <CAP=fDxWNjXcS80FzudTqJvEoXBaqTY0D96xPJ7wSRyPdKxdAew@mail.gmail.com>
To: Elliott Sprehn <esprehn@chromium.org>
Cc: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
This is an interesting approach that didn't occur to me! Similar to Anne's
concerns, this would require you to have more knowledge of the internals of
the super-class component. If you own both components then this is fine.

Also if this means we can remove a complex piece from the spec to help
reach consensus, great! :)


On Thu, Apr 16, 2015 at 1:41 AM, Elliott Sprehn <esprehn@chromium.org>

> On Wed, Apr 15, 2015 at 6:30 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>> On Wed, Apr 8, 2015 at 8:17 AM, Anne van Kesteren <annevk@annevk.nl>
>> wrote:
>> > * Multiple shadow roots. We'd like to retain this feature.
>> > Although it has complexity, we've heard from both Firefox UI and
>> > Firefox OS application developers that the moment your library gets
>> > sophisticated, you want this for extensibility.
>> I was asked to provide a use case for our stance. One that we've found
>> with Firefox OS is custom dialogs, quoting Wilson Page:
>> # I have an <x-dialog> component. It takes care of transitioning
>> # in and out of the viewport and appropriate styling contained
>> # elements (<h1>, <button>, <p>).
>> #
>> # I want to be able to extend this component to produce
>> # <x-dialog-alert>. In this case extending the prototype alone
>> # isn't enough, I need to also be able to extend the markup
>> # and styling of <x-dialog>.
>> #
>> # At the point of creation <x-dialog-alert> can add a second
>> # ShadowRoot that allows it to compose its own content
>> # inside that of the 'old' <x-dialog> ShadowRoot. Without this
>> # <x-dialog-alert> would have to duplicate all the markup, style
>> # and interaction code again.
> I don't think you need to duplicate anything. The super class can still
> fill in the original shadow root, then the subclass can modify it. This is
> the same concept of the prototype inheritance, your methods will shadow the
> super class methods, but you can just call them and then extend the
> behavior.
> This is also the reason the created and attached callbacks are on the
> prototype. So you can call super and use the parent behavior by shared
> protocol.
> - E
Received on Thursday, 16 April 2015 14:07:31 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC