Skip to content

Parse nth-child(-/*comment*/n+b) #154

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

Closed
wants to merge 1 commit into from

Conversation

Manishearth
Copy link
Member

@Manishearth Manishearth commented Jun 3, 2017

fixes #153

r? @emilio


This change is Reviewable

Copy link
Member

@emilio emilio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused, the patch in bug 1364009 reads:

Don't allow comments/spaces between signs,numbers,and `n` in an+b syntax for nth-child;

But it seems it's allowing comments but not spaces, right?

src/nth.rs Outdated
"n" => parse_b(input, 1),
"n-" => parse_signless_b(input, 1, -1),
_ => Ok((1, try!(parse_n_dash_digits(&*value))))
Token::Delim('+')| Token::Delim('-') => match try!(input.next_including_whitespace()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: spacing.

But I'd write it as:

Token::Delim(delim) => {
    let val = match delim {
        '+' => 1,
        '-' => -1,
        _ => return Err(()),
    };
    match try!(input.next_including_whitespace()) {
        // ...
    }
}

That way you avoid the extra variable at the top too.

@Manishearth
Copy link
Member Author

Yeah, so the spec is weird here. It explicitly includes a specification for all kinds of tokens, including tokens like 3n- (which is a dimension token). Based on these, neither whitespace nor comments are allowed within any token, as is usual. The 3n is never parsed as two tokens, so it never has whitespace. This was the main point of the patch.

On top of that, the -n is parsed as two tokens, but does not allow whitespace, as is specced. Chrome takes this to mean "comments but not whitespace", and Firefox supported comments and whitespace already. So I changed it to be uniformly "comments but not whitespace" everywhere, since by default you can assume that the spec is ignoring comments all the time.

Yes, that probably could be clarified more in that commit message but it's long :) I will try.

In this cssparser PR, i don't really change much behavior, I just make -n behave the the same as +n, which should match up regardless of your interpretation of the rest.

Copy link
Member

@emilio emilio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, fair enough.

The fix seems legit (feels weird to treat + differently than - here), and as long as it matches other browsers...

r=me

@emilio
Copy link
Member

emilio commented Jun 4, 2017

Let's wait until the discussion in #153 settles though.

@Manishearth
Copy link
Member Author

w3c/csswg-drafts#1498

@SimonSapin
Copy link
Member

r=me if w3c/csswg-drafts#1498 is accepted. (I’m officially co-editor of that spec so I could accept that change, but this section is tricky and Tab wrote it so I’d rather have him do it.)

@tabatkins
Copy link

👎, this appears to be a total misreading of the Syntax spec. More details in w3c/csswg-drafts#1498

@Manishearth
Copy link
Member Author

This means that these tests only require Firefox fixes to pass now.

@Manishearth Manishearth closed this Jun 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

:nth-child(-/**/n+2) should parse
4 participants