- From: Jirka Kosek <jirka@kosek.cz>
- Date: Thu, 13 Feb 2014 11:55:01 +0100
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- CC: www-style@w3.org
- Message-ID: <52FCA485.9010204@kosek.cz>
On 13.2.2014 10:37, Daniel Glazman wrote: > - title of section 2.1 should be "Attribute node pseudo-element" I personally like much more "Attribute node selector" then "pseudo-element". Although ::attr() uses pseudo-element syntax, it doesn't have meaning of pseudo-element as it access only information directly available in a document tree, nothing derived like other pseudo-elements. Originally I had following text in the spec, which Tab removed during aligning with the rest of CSS specs: "Syntax and structure is the same as in [[SELECTORS4]] with the following exception: A <a href="../selectors/Overview.html#simple" spec='SELECTORS4'>simple selector</a> can be also <a>attribute node selector</a>." Thinking about it, there is currently no replacement for this which defines where this new selector goes into syntax rules. Of course, this is just terminology. But if over the time Non-element selectors will get extended to support for example comments and processing-instructions (yes, there are already use-cases and implementations for this) then using pseudo-element naming patter would be even more counter-intuitive. > - I think the last sentence of section 2.1 should be clarified. Is the > attribute node pseudo-element allowed in CSS stylesheets or not. Given > the fact it is unlikely browsers will implement something that > generates no boxes, I think that pseudo will remain invalid in CSS > sheets to avoid the creation of the corresponding OM. Indeed, it doesn't have meaning in CSS. The question is how to handle if it appears here by mistake. > - I think you need a section 3 about Selectors API saying that the > expectation is that non-element selectors will be usable in Selectors > API. Yeah, but that would mean either changing method signatures or provide additional methods as current Selectors API design can return only element nodes. (Even NodeList returned by qSA() is restricted to contain only Elements in a prose.) BTW, what's preferred way for tracking those issues in CSS WG? Should I file bug for each issue so it's easy to track them, or do you use other means? Thanks, Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------ Bringing you XML Prague conference http://xmlprague.cz ------------------------------------------------------------------
Received on Thursday, 13 February 2014 10:55:29 UTC