21305 2013-03-15 20:34:31 +0000 [Shadow] Add explanatory rationale for the set of content selectors, and possibly update the spec with selectors from CSS4 Selectors 2013-07-17 22:02:32 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC Linux RESOLVED FIXED P2 normal --- 15480 1 mrbkap dglazkov bzbarsky dominicc public-webapps-bugzilla oldest_to_newest 84484 0 mrbkap 2013-03-15 20:34:31 +0000 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 84549 1 dominicc 2013-03-18 09:07:44 +0000 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. 84568 2 bzbarsky 2013-03-18 17:37:32 +0000 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. 84598 3 dominicc 2013-03-19 04:40:36 +0000 (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. 84599 4 bzbarsky 2013-03-19 05:10:04 +0000 > 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. 84600 5 dominicc 2013-03-19 07:14:47 +0000 Changing the title to help Dimitri out. 84636 6 mrbkap 2013-03-19 17:12:46 +0000 I still don't think it makes sense to allow :visited. 89223 7 dominicc 2013-06-13 01:09:23 +0000 I support removing :visited from the set of selectors. 90888 8 dglazkov 2013-07-17 22:02:32 +0000 It's been removed (along with a few others).