W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Base Template (Was Re: Minimum viable custom elements)

From: Dimitri Glazkov <dglazkov@google.com>
Date: Thu, 12 Feb 2015 10:46:38 -0800
Message-ID: <CADh5Ky2BuHi8uO2DDWNReF8h0uOoCb3R6ecEcRVg3RDTYVE3Ow@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Steve Faulkner <faulkner.steve@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, Jan Miksovsky <jan@component.kitchen>, WebApps WG <public-webapps@w3.org>
Ryosuke, Jan,

It might be useful for you two folks to work through Jan's Shadow DOM
composition/inheritance insight (use cases?) together and see how they
could be resolved without having multiple shadow roots per element. I would
love to take advantage of all the work you both have done thinking about
this problem separately.


On Thu, Feb 12, 2015 at 9:46 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

> On Feb 12, 2015, at 4:50 AM, Steve Faulkner <faulkner.steve@gmail.com>
> wrote:
> On 12 February 2015 at 10:58, Anne van Kesteren <annevk@annevk.nl> wrote:
>> which is a very different problem from what you want to solve, no?
> The problem I think needs solving for minimum viable custom elements is
> reducing reliance on bolt-on accessibility. From the example provided
> http://janmiksovsky.github.io/base-template/ it appears that in this
> instance it does achieve that end.
> I don't know whether this will extend to other UI controls or whether it
> is a practical solution, which is why I brought it to the list for
> discussion.
> Again, this proposal or subclassing problem is nothing to do with custom
> elements but all do with shadow DOM.
> Ironically, I've pointed out the exact same problem explained in this page
> last April and proposed to change the way shadow DOM works to solve it:
> https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
> - R. Niwa
Received on Thursday, 12 February 2015 18:47:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC