Dealing with arguments

[davidtheclark]

Right now if I parse the selector .foo:nth-child(3) it looks like I'm getting a node whose value is '3' and type is 'tag'.

It seems to me that the parser should differentiate arguments from tags.

But at the same time it probably ought to still report the class .bar in .foo:not(.bar).

What do you think?

[ben-eb]

I define tag as a 'fallback' - so that nodes that don't match any of the other patterns (class, id, attribute selector etc) end up in tag. The parser has no knowledge of valid XML/HTML tags. I'm not sure that adding an alias to tag for argument makes sense because what if that value is h1 - doesn't it make more sense as a tag?

[davidtheclark]

Hm. What about this:

I searched a little through http://www.w3.org/TR/css3-selectors/ and I only see two types of selectors that take arguments, and the type of argument each takes is consistent. The negation pseudo-class, :not(), always takes a simple selector -- so that argument could be parsed just like other selectors. The :nth-*() pseudo-classes (e.g. nth-child(), nth-of-type()) take integers, an + b expressions, and odd and even -- so those could be parsed specially so that their arguments aren't mistaken for type selectors.

Maybe that way this mistake could be avoided without knowing valid XML/HTML tags.

[ben-eb]

I'm not sure if I want to go down the route of parsing different types of pseudo classes as different entities. I wanted to make the parser be aware of CSS-like syntax, so if you made up some new selector like a:unicorns(47) then it could still parse that into a tag, followed by a pseudo containing a tag.

This seems important because people are generating lots of language extensions; it would be confusing if some pseudo selectors were parsed differently from others.

[davidtheclark]

Ok. I will handle my particular issue in my own code. Thanks.