Re: [selectors-nonelement] First draft of a new spec for selecting non-element nodes

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
------------------------------------------------------------------