Skip to content
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

Comments and whitespace in a complicated selector are not seen by stringifier #10

Open
dfreedm opened this issue May 10, 2016 · 3 comments
Labels

Comments

@dfreedm
Copy link

dfreedm commented May 10, 2016

Given a sheet

.foo,
.bar,
/* comment */
.baz {
  border: 2px solid black;
}

and a stringifier

class Stringifer extends shadyCssParser.Stringifier {
  comment() {
    return '';
  }
}

Output is expected to be

.foo,.bar,.baz{border:2px solid black;}

but is instead

.foo,
.bar,
/* comment */
.baz {border:2px solid black;}
@cdata cdata added the bug label May 10, 2016
@cdata
Copy link
Contributor

cdata commented May 15, 2016

This is slightly tricky to fix in the parser without adding a significant number of costly conditional checks, but it's actually quite trivial and cheap to fix with a specialized Tokenizer. tokenizeComment could be specialized to always return a zero-length token that starts and ends at the detected offset of the comment token.

In order to support this, the Parser would have to accept a specialized Tokenizer implementation. I'm going to add this for the near term, which should allow you to address this case. If there is a more elegant solution or preferred ergonomics to be had, I'm open to considering it.

@cdata
Copy link
Contributor

cdata commented May 15, 2016

An example of the specialized tokenizeComment method:

tokenizeComment(...args) {
  let token = super.tokenizeComment(...args);
  // Force token to be zero length
  token.start = token.end;
  return token;
}

@cdata cdata closed this as completed May 15, 2016
@cdata cdata reopened this May 15, 2016
@cdata
Copy link
Contributor

cdata commented May 15, 2016

Okay, now that I think about it more, this would not be a sufficient solution. We only look at the start and end tokens when slicing chunks of the string, so the ranges in any interstitial comment tokens won't matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants