- From: Simon Fraser <smfr@me.com>
- Date: Wed, 17 Feb 2016 12:19:46 -0800
- To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style@w3.org list" <www-style@w3.org>, www-svg <www-svg@w3.org>
- Message-id: <36F1144C-4A9C-425E-91D6-EBCE4EA04292@me.com>
> On Feb 17, 2016, at 11:35 AM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> wrote: > > I am quite sympathetic to the argument that we should just make gradient rendering good everywhere. > > But in practice, Chromium at least is making visible performance-over-quality tradeoffs, displaying banding in smooth gradients and jagged pixelation on sharp transitions (in larger blocks than the actual screen resolution). Banding can also appear in subtle gradients in any rendering tool that doesn't do explicit dithering, which can be an issue with high-quality printing and SVG. > > If we create a new `gradient-rendering` property (instead of re-purposing `image-rendering`), that solves 2 issues: > User agents that can't control gradient rendering can simply indicate that they don't support certain values. So an `@supports (gradient-rendering: smooth) {}` rule would fail if the renderer always applies some pixel aliasing to gradients, even if they have no problem with smooth image scaling. I don’t think that’s an appropriate use of @supports(). We don’t spec CSS properties whose implementation is optional based on whether the UA can implement something; we spec them so that everyone can implement them, and allow UA differences via ‘auto’ values. > > The keywords can be chosen to make more sense for gradients instead of for image scaling. The distinction between `crisp-edges` and `pixelated` is perhaps too confusing to factor in ( I had suggested that `crisp-edges` would alias to device pixels only for strict vertical and horizontal gradients, and use smoothing for other angles. ) And perhaps an explicit `dithered` keyword may prove useful for some implementations. > Like the other *-rendering properties, these would be a "hint" from the author to the user agent; no one would be deemed non-conforming for failing to provide advanced rendering control. > > For reference, here are current behaviors, based on a quick test of the following two pages on a Windows laptop with a moderately good screen resolution: > CSS gradients at various angles: > https://jsfiddle.net/987q718v/ <https://jsfiddle.net/987q718v/> > SVG gradient (center) and CSS gradient: > http://oreillymedia.github.io/SVG_Colors_Patterns_Gradients/ch07-positioningGradients-files/css-gradient-direction.html <http://oreillymedia.github.io/SVG_Colors_Patterns_Gradients/ch07-positioningGradients-files/css-gradient-direction.html> > Chrome: visible banding, sharp diagonal transitions aliased to ~2x2 pixel blocks > Edge & Firefox: very subtle banding on the black-to-white gradients, diagonal transitions aliased to device pixels. > > I couldn't recreate the noticeable blurring on horizontal/vertical gradients in Firefox that I've seen designers complain about previously. Not sure if that means it's fixed or if certain other features of the gradient are required to provoke it. > Given that Rick has said that this is a Chrome bug that has been fixed, do you still think this new property is required? Simon
Received on Wednesday, 17 February 2016 20:20:17 UTC