- From: Matthew Robb <matthewwrobb@gmail.com>
- Date: Tue, 4 Feb 2014 10:16:33 -0800
- To: "Edward O'Connor" <eoconnor@apple.com>
- Cc: www-style@w3.org
- Message-ID: <CAAngBgi9ufMVjzt__Yi2baOPURB5QYLprQOOQEznXHb_YxmheA@mail.gmail.com>
I'm not sure the specific rules governing selectors of this type but what if you did `::shadow` and `::^shadow` or some other character after the pseudo accessors On Tue, Feb 4, 2014 at 10:02 AM, Edward O'Connor <eoconnor@apple.com> wrote: > Hi Dimitri, > > You wrote: > > > As indicated by Tab at the F2F, Blink currently implements the cat/hat > > combinators proposed by yours truly [3]. > > > > FWIW, I don't fully understand why it would be so terrible to leave > > cat and hat alone (in talking with Tab, there's only a weak precedent > > for preferring pseudo element functions to combinators with > > ::content), but I am okay with renaming them. Ultimately, it's this > > WG's shed, I just store my bike there. > > I don't think host documents should be able to select arbitrary elements > in the shadow DOM. A much better model, which IIRC was in one of your > documents at one point, is to let the component author explicitly export > certain shadow elements as pseudos. Something like: > > # In shadow tree > > <div pseudo=foo>...</div> > > # in CSS, if that shadow tree is attached to el with id bar > > #bar::pseudo(foo) { ... } > > In this model, the component author is only signing up for a contract > for which they know the terms. > > Also, given the several open threads on public-webapps about various > foundational components issues, I think it would be a mistake to ship an > implementation without either prefixing it or putting it behind a > disabled-by-default runtime flag. That said, I'm sure you guys > understand Blink's policy for exposing features to the Web better than I > do. > > > Ted > > -- - Matthew Robb
Received on Tuesday, 4 February 2014 18:17:41 UTC