added support for calc wherever <length> is expected #35

merged 3 commits into from Nov 16, 2012

2 participants


According to

calc is supported wherever a length property value is supported.

This adds support for a calc() function, and adds support for the *, +, and - operators to successfully parse out the calc functions.

Unit tests updated


wow, thanks I'll take a look next week.


This looks like a good start. What it's missing is a way to access that information correctly from the parser. Ideally, there would be a way to get access the various parts of the calc() function from inside the "property" event, as part of the value. Do you have any ideas for how to do that?


I'm very new to the parser lib, I was trying to solve a problem with css-lint that depended on parser-lib to verify whether css is valid and this lack of support was throwing errors in my build process. If you point me in the right direction I can look into adding support deeper into the library.


Understood. I'd just like to have a complete solution rather than a partial one. Right now, what you've implemented will make sure that the parser doesn't throw an error, but it doesn't make sure that somebody using the parser can get access to the data. A good place to start is with the description of syntax units here:

Each value is split into instances of PropertyValuePart ( I'm not sure what would happen right now if you listen for a "property" event and look at the value when using calc(). That would be a good place to start. Ideally, the parser should return something that gives you access to all the parts of the calculation.

It's a bit of work, I'm sure - part of why I haven't dug into it yet. :)


After looking at this again, I'd like to merge it in however there is a test that's failing. (the Travis build isn't working correctly.) Run ant test from the command line to see it. If you can fix that, I'll be happy to merge in.

fracmak added some commits Oct 12, 2012
@fracmak fracmak added support for calc wherever <length> is expected 1845473
@fracmak fracmak added support for + operator for calc functions e0be226
@fracmak fracmak _operator is used for seperating multiple values for a property (ie. …
…box-shadow: 10px 10px 0, 2px 2px 0) as well as for mathematical operators inside functions. Since functions are the only place mathematical operators are allowed, we now pass in a boolean to distinguish which token is acceptable to not accidentally treat -10px -10px as an equation

I've dug through the code and found out where my logic went wrong. the _operator() function is used for seperation of compound css statements as well as parsing parameters in a function. When I added the mathematical operators to the list, it broke scenarios like box-shadow: 10px 10px #888, -10px -10px #f4f4f4; because it thought it was a mathematical operator. I've added a boolean to the _operator function to indicate whether we're parsing inside a function or outside since the math operators are only allowed inside. This has fixed the test.

@nzakas nzakas merged commit 8ca2d38 into CSSLint:master Nov 16, 2012

1 check passed

Details default The Travis build passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment