Skip to content

[css-variables-1] CSS Variables should be considered as released. #5390

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

Closed
SmashingQuasar opened this issue Aug 3, 2020 · 7 comments
Closed

Comments

@SmashingQuasar
Copy link

Hey!

CSS variables have been in release recommendation since 2015. While this is a necessary step to let browsers implement the feature properly and keep cohesion, we are way past this point. Even Internet Explorer 8 supports CSS variables.

The problem is that the validator rejects this syntax as it is not officially considered released and this create customer relations issues in modern projects.

It is way overdue to consider CSS variables as fully released and to update the validator as such so we can safely use them without the fear of false positive error reports.

Associated RFC: https://www.w3.org/TR/css-variables-1

Thanks!

@tabatkins
Copy link
Member

The W3C validator (which we don't, by the way, have any direct control over) appears to accept custom properties and variables without complaint.

If you're using another validator, you'll have to file an issue on them to fix their validation. CSS Variables are definitely widely released and supported.

@SmashingQuasar
Copy link
Author

Would you consider updating the document so it no longer presents this specification as Candidate Recommendation, please?

From what you are telling me, it is clearly no longer a Candidate Recommendation.
I will definitely contact the w3 validator about this issue but as long as it is marked as Candidate Recommendation, they will not make any change.

@tabatkins
Copy link
Member

What validator are you referring to? Perhaps the W3Schools validator (remember, W3Schools has absolutely no connection to the W3C)? As I said, the actual W3C validator accepts variables/custom properties just fine.

CR vs Rec is largely a procedural issue; validators absolutely should not be restricting themselves to only allowing things in Recs. (And I'm pretty certain any validator is not doing that; it would be completely worthless if that was the case, since most specs are in CR, not Rec.)

@sideshowbarker
Copy link
Member

I will definitely contact the w3 validator about this issue but as long as it is marked as Candidate Recommendation, they will not make any change.

That’s not correct.

The actual policy of both the W3C CSS validator and the current W3C HTML validator is basically to attempt to support any features that are implemented in at least two browser engines — regardless of the W3C publication status of whatever spec the features happen to be from.

So if there are particular CSS features that have been implemented in two or more browser engines but that aren’t supported in the CSS validator, that’s simply because the maintainers of the CSS validator have not yet gotten around to adding support for the features yet.

@tabatkins
Copy link
Member

Again, tho, the W3C validator, which I linked above, handles variables and custom properties just fine. So @SmashingQuasar must be relying on some other validator, and since they mentioned "w3 validator", I assume they're referring to W3Schools, which is a common mistake. I haven't tried using a custom property with that validator, as W3Schools is in general not something I care about. ^_^

@sideshowbarker
Copy link
Member

Again, tho, the W3C validator, which I linked above, handles variables and custom properties just fine.

The reason that W3C validator handles variables and custom properties is that for CSS checking, it’s using a fork I made of the W3C CSS validator backend — a fork with a patch for handling variables and custom properties.

But that patch in its current form isn’t really suitable for upstreaming to the W3C CSS validator sources — so I think the W3C CSS validator service at https://jigsaw.w3.org/css-validator/ doesn’t actually yet handle variables and custom properties.

That’s one reason why I recommend that these days anybody who wants to do CSS validation should consider trying https://validator.w3.org/nu/ (the Nu Checker) as an alternative to https://jigsaw.w3.org/css-validator/.

If you give https://validator.w3.org/nu/ the URL for a CSS stylesheet, or upload a .css file to it, it’ll recognize it as CSS and check it (using an embedded version of the backend of the W3C CSS validator, except with one difference being, as I mentioned above, that it’s able to handle variables and custom properties).

@SmashingQuasar
Copy link
Author

@tabatkins You linked the HTML Markup Validation service. I used this validator for CSS validation: https://jigsaw.w3.org/css-validator.
From my understanding it is hosted on the w3,org domain. Unless someone defaced this domain, I believe this is linked to the W3C validation service. I may be confused here but multiple people believe this to be the "official" W3C CSS validation service. We even have schools apparently relying on this for their evaluations.

@sideshowbarker Thanks for the answer. That's actually really helpful. I am not sure I understand why one validation service can support the deployment of your patch and not the other though. Different languages? I believe https://jigsaw.w3.org/css-validator has been developed in Java.

I don't know who has control over what considering how confusing this is but could the team in charge of https://jigsaw.w3.org/css-validator mark it as deprecated? In it's current state, this validator is out of standard but still uses the domain "w3.org". As I mentioned earlier, we had customers relying on it and we even had interns telling us their schools rely on this service for their evaluation. I think it is a problem serious enough to consider depreciation.

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

No branches or pull requests

3 participants