forked from reworkcss/css
-
Notifications
You must be signed in to change notification settings - Fork 11
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
Regression in selector parsing: Attribute selectors not parsed correctly #77
Comments
RandomByte
changed the title
Regression in selector parsing: Data attributes not parsed correctly
Regression in selector parsing: Attribute selectors not parsed correctly
Dec 6, 2022
Thanks a lot for the report, I will work on it as soon as I get some time. |
RandomByte
added a commit
to SAP/less-openui5
that referenced
this issue
Dec 9, 2022
Reusing the existing tests for HTML queries by adding quotes to some of the attribute selectors and compressing the CSS before parsing it. This targets a regression in the @adobe/css fork of css as reported here: adobe/css-tools#77
matz3
added a commit
to SAP/less-openui5
that referenced
this issue
Dec 12, 2022
This reverts commit 0abe66a. The change introduced unexpected regressions due to a bug in `@adobe/css-tools`, see adobe/css-tools#77.
RandomByte
added a commit
to SAP/less-openui5
that referenced
this issue
Dec 14, 2022
Reusing the existing tests for HTML queries by adding quotes to some of the attribute selectors and compressing the CSS before parsing it. This targets a regression in the @adobe/css fork of css as reported here: adobe/css-tools#77
RandomByte
added a commit
to SAP/less-openui5
that referenced
this issue
Dec 14, 2022
Reusing the existing tests for HTML queries by adding quotes to some of the attribute selectors and compressing the CSS before parsing it. This targets a regression in the @adobe/css fork of css as reported here: adobe/css-tools#77
RandomByte
added a commit
to SAP/less-openui5
that referenced
this issue
Dec 16, 2022
Reusing the existing tests for HTML queries by adding quotes to some of the attribute selectors and compressing the CSS before parsing it. This targets a regression in the @adobe/css fork of css as reported here: adobe/css-tools#77
holblin
pushed a commit
that referenced
this issue
Jan 11, 2023
Hi @RandomByte , could you check if this PR fixes your problems?
|
@holblin thanks! I can confirm that it resolves all issues we were facing. |
The new version is published in npm 👍 |
ryenus
added a commit
to ryenus/less-openui5
that referenced
this issue
Jan 16, 2023
This had been first attempted in 0abe66a but later reverted by 3b6c459 due to adobe/css-tools#77, reapplying since the issue is now fixed. --- This solves the issue of having outdated and potential insecure transitive dependencies. There are no known behavior changes, so this is considered a non-breaking change / fix. See: reworkcss/css#163 See: SamVerschueren/decode-uri-component#6
ryenus
added a commit
to ryenus/less-openui5
that referenced
this issue
Jan 16, 2023
This had been first attempted in 0abe66a but later reverted by 3b6c459 due to adobe/css-tools#77, reapplying since the issue is now fixed. --- This solves the issue of having outdated and potential insecure transitive dependencies. There are no known behavior changes, so this is considered a non-breaking change / fix. See: reworkcss/css#163 See: SamVerschueren/decode-uri-component#6
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thank you for this fork of
css
. It's very helpful to us.While testing, I think I have found a regression in the parser, introduced with commit 24ed6e7:
css-tools/src/parse/index.ts
Lines 215 to 239 in a0efaee
The regular expression
/("|')(?:\\\1|.)*?,(?:\\\1|.)*?\1|\(.*?,.*?\)/g
seems to be too greedy for cases likediv[class='foo'],div[class='bar']
. For this example, it captures'foo'],div[class='
, leading to an incorrect replacement of the comma that separates the two selectors and is not part of the data selector.The original regular expression, used before this change (
/"(?:\\"|[^"])*"|'(?:\\'|[^'])*'/g
) handles this case correctly by matching'foo'
and'bar'
.Ultimately, the current behavior leads to an incorrect AST, where instead of two selectors, only one (incorrect) selector is listed:
Expected:
I have attached a test case demonstrating this. You can extract the archive directly into
test/cases/
:case - selectors-attributes.zip
The text was updated successfully, but these errors were encountered: