-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Universal Selector behaves like a Type Selector #3
Comments
To summarize, you'd like something more explicit to tell you that you're using a universal selector instead of a type selector. Do you have something in mind? |
With that change in place the if-line would look like this:
Hm. Still somewhat icky. Let's go back to the specs...
Maybe the breakdown should follow that description a bit more closely. So, a selector gets broken down into something like: SimpleSelector, [Combinator, SimpleSelector]* and [PseudoElement].
If we go with that, each SimpleSelector would contain an array with that stuff from the list above. E.g.:
With those changes in place the function could then look like this:
Since that pseudo element is spec wise on a different level, it's kinda nice to have code which reflects this. (I also renamed 'modifier' to 'subPart'.) Hope this makes sense. :) |
"either"... oops. |
Not a mistake per se, but it makes using the API a bit odd.
E.g. take a look at this little function which calculates a selector's specificity:
For completeness' sake here is the function which makes that number human-readable:
If you want to toy around with it here is some array with selectors and their specificity (taken from the specs):
Now, back to the thing I didn't like... checking explicitly if this thing which looks like the name of an element is indeed the name of an element (
part.elementName !== '*'
) feels sorta wrong.The text was updated successfully, but these errors were encountered: