You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As you can see in the readme, “Adopt lenient parsing rules” is on the to-do list. Currently, however, the CSS Parser only parses standard-compliant CSS.
You’re welcome to add a patch, though. I think a reasonable strategy could be to catch exceptions in the parser’s parseRule method and advance the parser to after the next line break or semicolon, or before the next closing curly bracket (whichever comes first) and return null. We’d then have to change every consumer of parseRule (I think parseRuleSet is the only one) to not fail when parseRule returns null.
We could add a safe mode to ignore non-compliant css instead of throwing exception. These way to work are present in most parsers I know.
Ultimately, avoid to end with parsing code for compliant rules mixed up with specific fix. Although, I really think that this is the only one non-compliant approach that should really be considered as it is present in nearly every css file.
I will consider your idea, and will give you feedback in a few, I'll be quite busy this weekend.
When parsing arbitrary css file, I often have to deal with ie specific css such as
These properties should be ignored as comment as they are not standard css and aim to patch the same property designed for compliant browser.
The other option would be to allow * characters as valid starting character for a property name. It could be simpler, and output the same css code.
If you are interested in having such feature, I can implement the latter.
The text was updated successfully, but these errors were encountered: