- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 27 Aug 2015 15:59:28 +0200
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style@w3.org" <www-style@w3.org>, Anne van Kesteren <annevk@annevk.nl>
On Thu, Aug 27, 2015 at 3:46 PM, fantasai <fantasai.lists@inkedblade.net> wrote: > On 08/27/2015 12:38 PM, Tab Atkins Jr. wrote: >> >> On Thu, Aug 27, 2015 at 3:07 AM, fantasai <fantasai.lists@inkedblade.net> >> wrote: >>> >>> We don't define anywhere what pseudo-elements the DOM methods accepting >>> a selector are allowed to use. >>> >>> For example, IIRC they can only return elements, so any selectors that >>> use most pseudo-elements should be invalid. E.g. ::selection, ::before, >>> ::first-letter, etc. should all be invalid. >>> >>> However, we might want that using ::shadow or ::content as a combinator >>> is valid, so that >>> ::shadow >>> is either invalid or returns nothing but >>> ::shadow div >>> is valid and returns <div> descendants of any shadow trees. >>> >>> I think this should be done by DOM specifying what it accepts rather >>> than Selectors defining what DOM should accept. >> >> >> You're confusing some issues. >> >> Wrt whether pseudo-elements should be returned by the matching >> algorithm when some API invokes it, that's controlled by an argument >> to the matching algorithm already. You specify when you invoke it >> which pseudo-elements you want to allow in your result set. > > Right. And DOM doesn't specify that flag atm, which means it gets > pseudo-elements in its result list atm. Yeah. Either DOM needs to be fixed, or we can switch the default for the argument if we think "no pseudo-elements" is going to be the more common usage of this algo. >> Wrt whether pseudo-elements are valid or invalid in a particular >> invoking context is of course definable by whatever thing is invoking >> Selectors. We alter the set of "valid" things depending on context >> for several selectors in the spec already. > > Yes, my point is that we need to define the set of DOM-valid things > somewhere. We could do it in Selectors (by creating a profile that > DOM references) or DOM could define it, or we could make the DOM-valid > profile the default one that you get when you reference Selectors. > > But right now DOM just references Selectors and, since it doesn't say > otherwise anywhere, gets everything in it (which is perfect since the > current spec doesn't include anything we don't want) and nothing > outside it (which isn't great for Shadow DOM-supporting UAs, who'll > want the pseudo-elements in css-scoping). Why are you assuming that the Scoping selectors aren't included? ~TJ
Received on Thursday, 27 August 2015 14:00:22 UTC