- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Mar 2024 18:17:19 +0000
- To: public-css-archive@w3.org
LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-images-4] Allow gradients with a single color stop and 0-1 positions == This came up in https://github.com/w3c/csswg-drafts/pull/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: - Smoother authoring experience for editors offering realtime updates (earlier visual feedback). - Less verbosity, - 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 - We don’t have to introduce warts in the grammar like [a special token for color stops with exactly two positions](https://github.com/w3c/csswg-drafts/pull/10077/files#diff-994978825958ad4d2d852734a8d7d222a30c4bb14402ef0bb98905805bd763a3R1841). - 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](https://github.com/w3c/csswg-drafts/pull/10077#issuecomment-1998556669) 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. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10092 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 March 2024 18:17:20 UTC