This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21305 - [Shadow] Add explanatory rationale for the set of content selectors, and possibly update the spec with selectors from CSS4 Selectors
Summary: [Shadow] Add explanatory rationale for the set of content selectors, and poss...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 15480
  Show dependency tree / graph
 
Reported: 2013-03-15 20:34 UTC by Blake Kaplan
Modified: 2013-07-17 22:02 UTC (History)
2 users (show)

See Also:

Attachments

Description Blake Kaplan 2013-03-15 20:34:31 UTC 
Insertion points currently allow the :visited pseudo-class to be used to select child nodes [1]. While useful, implementing this unfortunately re-introduces the CSS :visited history hack [2]. I don't think there's a safe way of allowing :visited to be used without reintroducing it.

[1] https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#matching-insertion-points
[2] http://dbaron.org/mozilla/visited-privacy
Comment 1 Dominic Cooney 2013-03-18 09:07:44 UTC 
The :visited issue is discussed in general here:

<http://www.w3.org/TR/selectors-api2/#privacy>

This notes that "user agents may treat all links as unvisited links". This provision could also apply to :visited in a content selector. As such I don't think this is a problem.

From one implementer's perspective (Chrome) this is an extremely low risk; we treat all links as visited.
Comment 2 Boris Zbarsky 2013-03-18 17:37:32 UTC 
If every UA is just going to never match :visited in here, what's the point of allowing it and leading people to try using it?

Is it just to allow them to copy/paste existing ":link,:visited" selectors?

That said, why are we restricting the set of selectors at all?  The spec doesn't say, and without an explanation of the goal it's impossible to tell whether this restriction is even the right approach, much less whether the set of things restricted to is correct.
Comment 3 Dominic Cooney 2013-03-19 04:40:36 UTC 
(In reply to comment #2) 
> That said, why are we restricting the set of selectors at all?  The spec
> doesn't say, and without an explanation of the goal it's impossible to tell
> whether this restriction is even the right approach, much less whether the
> set of things restricted to is correct.

I think the reason varies on a case-by-case basis depending on the specific selector.

I agree it would be nice if the spec had some non-normative language explaining the rationale for this set. If new selectors are added to CSS in future, that text could informally guide spec updates as to whether those selectors should be allowed or not.
Comment 4 Boris Zbarsky 2013-03-19 05:10:04 UTC 
> I think the reason varies on a case-by-case basis depending on the specific
> selector.

I strongly suggest putting the set of relevant reasons in the spec, in informative prose, or otherwise making it discoverable.  Without that, there is no way to tell whether the spec is correct or not.

It's not an "if".  See http://dev.w3.org/csswg/selectors4/, of which this spec seems to be wholly ignorant.  Or maybe not, and it's excluding them all on purpose.  As an implementor, I just can't tell because I have no idea what the spec is trying to do.
Comment 5 Dominic Cooney 2013-03-19 07:14:47 UTC 
Changing the title to help Dimitri out.
Comment 6 Blake Kaplan 2013-03-19 17:12:46 UTC 
I still don't think it makes sense to allow :visited.
Comment 7 Dominic Cooney 2013-06-13 01:09:23 UTC 
I support removing :visited from the set of selectors.
Comment 8 Dimitri Glazkov 2013-07-17 22:02:32 UTC 
It's been removed (along with a few others).