Allow CSS custom properties (without checking) #173
Conversation
93be7a2 to
796ed48
Compare
796ed48 to
a125bf0
Compare
1ce26b3 to
e6d27ee
Compare
This change is a temporary workaround that adds an interim/initial/partial level of support for handling CSS custom properties and the `var(...)` function. The intent is that we’ll add full support later, and then at that time back this change out — or else at least just use it as a starting point for full support. This change simply allows declarations to contain custom property names (that is, identifiers starting with two dashes) and to contain the `var(...)` function (with a custom property name as the first argument). Beyond that, it doesn’t add any checking to report an error if a `var(...)` function contains a custom property name that the stylesheet hasn’t actually defined, and no checking to report an error if a particular property has an expression with a `var(...)` function which resolves to a value that’s not allowed for that property. Addresses #111
e6d27ee to
46f3747
Compare
|
Could this be deployed? My school insists our code passes the validator which means I might have to rewrite my project without CSS variables because the validator is not up to date... |
|
@saschanaz Thanks, I hadn't seen those issues. They don't seem to mention any reason not to deploy an update to the live validator however. Since this was merged 10 months ago it looks like all that is missing is a roll out. |
|
The patch itself is deployed and the validator can read custom properties. Try https://jigsaw.w3.org/css-validator/validator?uri=https%3A%2F%2Fyari-demos.prod.mdn.mozit.cloud%2Fen-US%2Fdocs%2FWeb%2FCSS%2FUsing_CSS_custom_properties%2F_sample_.First_steps_with_custom_properties.html&profile=css3svg&usermedium=all&warning=1&vextwarning=&lang=en for example. |
|
@sashanaz My apologies. I got confused. I get errors on code like this: .search
{
--search-height: 14.5rem;
--search-radius: calc( var(--search-height) / 3 );
}Since it throws warnings for the variables and the line here throws an error right after the AFAICT This is correct CSS code. Maybe that's an issue with this PR not supporting operators on variables? |
|
Looking through the diffs here it's quite hard to tell what's going on not knowing the grammar syntax used. Maybe @sideshowbarker can clarify whether this code was intended to pass or not... |
That’s valid per spec. The fact that the validator doesn’t recognize it as valid is a bug in the validator. There are many such cases of valid CSS using custom properties and certain functions that are known to fail in the validator. The cause is that the validator doesn’t actually yet have support for custom properties. And the solution is that someone needs to update the validator code to add real support for custom properties. Nobody is currently working on that, though. So I don’t expect anything to change around this any time soon. |
|
@sideshowbarker Thanks for clarifying. Hopefully my evaluator will let me pass the exercise with css variables thanks to your comment. Btw just want to say, I 💖 MDN. Many thanks for your hard work. |
This change is a temporary workaround that adds an interim/initial/partial level
of support for handling CSS custom properties and the
var(...)function. Theintent is that we’ll add full support later, and then at that time back this
change out — or else at least just use it as a starting point for full support.
This change simply allows declarations to contain custom property names (that
is, identifiers starting with two dashes) and to contain the
var(...)function(with a custom property name as the first argument). Beyond that, it doesn’t add
any checking to report an error if a
var(...)function contains a customproperty name that the stylesheet hasn’t actually defined, and no checking to
report an error if a particular property has an expression with a
var(...)function which resolves to a value that’s not allowed for that property.
Addresses #111