Opacity values outside the range [0,1] are not invalid, and are preserved in specified values, but are clamped to the range [0, 1] in computed values.
However, CSS3 will not highlight opacity: 2;. In fact, it won't highlight opacity: 5e-1; either, even though that is valid and in the correct range (equivalent to opacity: .5;). The latter is a result of attempting to create this restriction with a rather complex regex, and missing a case.
But, while technically this highlighting is non-compliant, I do understand the sentiment of wanting to help the user write good code; opacity: 2; may be compliant, but it sure is more confusing than the functionally identical opacity: 1;. On the other hand, it could be nice for users to see opacity: 2 highlighted, just so they know it is allowed; I myself have used the opacity clamping extensively in combination with CSS variables that may fall out of that range.
That being said, there are also cases where CSS3 tries to specify a clamped number, but doesn't quite manage to do so consistently. For example, rgba(500 500 500) highlights just fine, but rgba(567 567 567) does not (note: both are valid). To top that off, rgb(567 567 567) also highlights fine because it was not implemented with the same clamping restriction, whereas the spec makes no difference between rgb() and rgba() in this regard and says to clamp the components to the defined ranges. Additionally, like with opacity, things like writing 1e2 instead of 100 also do not highlight even though they are valid and in the correct range.
Lastly, in the case of cubic-bezier(), CSS3 is just flat out wrong; the second and fourth argument are not only permitted to be outside of the range 0-1, but are not even clamped; values outside of that range just represent a different timing function. An example of this is cubic-bezier(.1, 2, .8, -1.5), which is perfectly spec-compliant but does not highlight properly.
My proposed resolution for this issue is to remove the number-zero-to-255 and number-zero-to-one definitions completely, and simply replace them with number.
The CSS3 package is, in my opinion, a bit overly restrictive when it comes to some properties accepting numbers in a certain range.
For example, the spec mentions this in the section titled "Transparency: the
opacityproperty":However, CSS3 will not highlight
opacity: 2;. In fact, it won't highlightopacity: 5e-1;either, even though that is valid and in the correct range (equivalent toopacity: .5;). The latter is a result of attempting to create this restriction with a rather complex regex, and missing a case.But, while technically this highlighting is non-compliant, I do understand the sentiment of wanting to help the user write good code;
opacity: 2;may be compliant, but it sure is more confusing than the functionally identicalopacity: 1;. On the other hand, it could be nice for users to seeopacity: 2highlighted, just so they know it is allowed; I myself have used theopacityclamping extensively in combination with CSS variables that may fall out of that range.That being said, there are also cases where CSS3 tries to specify a clamped number, but doesn't quite manage to do so consistently. For example,
rgba(500 500 500)highlights just fine, butrgba(567 567 567)does not (note: both are valid). To top that off,rgb(567 567 567)also highlights fine because it was not implemented with the same clamping restriction, whereas the spec makes no difference betweenrgb()andrgba()in this regard and says to clamp the components to the defined ranges. Additionally, like withopacity, things like writing1e2instead of100also do not highlight even though they are valid and in the correct range.Lastly, in the case of
cubic-bezier(), CSS3 is just flat out wrong; the second and fourth argument are not only permitted to be outside of the range 0-1, but are not even clamped; values outside of that range just represent a different timing function. An example of this iscubic-bezier(.1, 2, .8, -1.5), which is perfectly spec-compliant but does not highlight properly.My proposed resolution for this issue is to remove the
number-zero-to-255andnumber-zero-to-onedefinitions completely, and simply replace them withnumber.