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
This came up in #10077 but I’m opening a new issue since I proposed a different path but then the change qualifies as substantive.
So currently, CSS Images 4 has prose and grammar that disallows single color stop gradients. However, all UAs have implemented a syntax that allows a gradient with a single color stop as long as it has two positions, e.g. linear-gradient(red 0% 100%).
What purpose does this restriction serve? You get a single color anyway and the positions are meaningless, they could be anything at all and as long as they parse, they produce the same result. E.g. linear-gradient(red 50% 50%), linear-gradient(red -100% -200%), linear-gradient(red 50% 50%), linear-gradient(red 300% 1000%) all produce the same result. So what's the harm in simply allowing a single color stop, even if it has one position — or even none? You get a single color anyway!
The benefits of that are small, but not inconsequential:
Clearer intent (the current syntax is misleading, because the numbers don't actually do anything).
It means that color stops can be independently valid or invalid, they don't depend on the presence of other color stops, which means they can be manipulated more easily in script
While the restriction is implemented, so adopting that would involve less eng effort, dropping the restriction is actually easier to implement so it would allow UAs to clean up their implementations.
The only argument against this is that implementations seem to agree on the current state (of requiring two stops) so we may as well adopt that in the spec. However, given the spec already differs from implementations, I see no harm in changing it in a way that makes it more permissive than implementations. Having it be less permissive (the current situation) is a much bigger issue.
The text was updated successfully, but these errors were encountered:
Yeah, the restriction was just because you're defining a gradient, and by definition that requires two colors to interpolate between. But there's nothing wrong with allowing a single color, certainly. And if browsers are already allowing a single stop when it has two positions, contrary to the spec grammar (probably because they expand that at parse-time into two stops in their internal representation, and then just check that the internal list is at least 2 items), then I really don't see an issue.
This came up in #10077 but I’m opening a new issue since I proposed a different path but then the change qualifies as substantive.
So currently, CSS Images 4 has prose and grammar that disallows single color stop gradients. However, all UAs have implemented a syntax that allows a gradient with a single color stop as long as it has two positions, e.g.
linear-gradient(red 0% 100%)
.What purpose does this restriction serve? You get a single color anyway and the positions are meaningless, they could be anything at all and as long as they parse, they produce the same result. E.g.
linear-gradient(red 50% 50%)
,linear-gradient(red -100% -200%)
,linear-gradient(red 50% 50%)
,linear-gradient(red 300% 1000%)
all produce the same result. So what's the harm in simply allowing a single color stop, even if it has one position — or even none? You get a single color anyway!The benefits of that are small, but not inconsequential:
The only argument against this is that implementations seem to agree on the current state (of requiring two stops) so we may as well adopt that in the spec. However, given the spec already differs from implementations, I see no harm in changing it in a way that makes it more permissive than implementations. Having it be less permissive (the current situation) is a much bigger issue.
The text was updated successfully, but these errors were encountered: