W3C home > Mailing lists > Public > www-style@w3.org > May 2011

Re: [css3-images] Rounding issues in degenerate repeating gradients

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 26 May 2011 18:08:11 -0700
Message-ID: <BANLkTi=W7OFNqb=d9_4LkAvKb-7ed-u4UQ@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: www-style list <www-style@w3.org>
On Thu, May 26, 2011 at 10:17 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On May 26, 2011, at 9:36 AM, Tab Atkins Jr. wrote:
>> On Thu, May 26, 2011 at 8:45 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> Shouldn't it be identical to what happens to a non-repeating horizontal or vertical gradient in a repeating background when background-size approaches zero? My expectation there that once it rounds to zero, it disappears. An author should not make things that are nearly zero width if he wants people to see them. If he is animating a gradient width, he can animate it down to one or two px instead of zero, if he is concerned about what decimal of one will cause it to suddenly disappear.
>> It could be, sure; the case is roughly equivalent.  Given our goal of
>> avoiding non-continuous behavior, I'd say that the background-size
>> behavior is a bug.  I don't like dismissing problems with "authors
>> shouldn't do that" when we can just fix it easily so that it doesn't
>> ever occur.
>> We should align these two, though, whether that's by making
>> background-size match repeating gradients, or making repeating
>> gradients match background-size.
> I haven't actually tested to see if that is what backgrounds do, I am just guessing it based on the principal of least surprise. I would expect implementations to clamp away any "divide by zero" issues, rather than defining some sort of magic behavior for what happens at near-zero. I think we have other properties where zero is an invalid value, don't we? Does that really cause problems, or is this just a theoretical purity issue?

I'm not concerned with divide-by-0 errors; the fact that we have an
alternate behavior specified already takes care of that.  I'm just
concerned about non-continuous behaviors.  For example, box-shadow
spread has non-continuous behavior around 0px border-radius - at some
arbitrary value close to zero, which depends on browser rounding
behavior, the spread suddenly switches from rounded-corner to
sharp-corner.  I can imagine legitimate author behavior running into
this, where they want a rounded shadow but a sharp box corner, and
have to guess at how small they can set border-radius without tripping
the behavior change.

> I think that if I had a gradient going from black to white that was one device pixel wide, the UA would probably draw it as gray. It seems reasonable that if it took place over 0.5px, that it might be a gray that was half as dark or half as opaque. As the width got smaller, the grey could get lighter until it disappeared. Just another possible way to deal with this in a smooth way, if that is what you are after.

I was just thinking that converting the gradient into a solid-color
that was a weighted average of the colors would be the other approach
to take.  ^_^  I consider that too complicated for a simple
corner-case like this, though.

(The gray wouldn't get lighter or disappear as the width shrunk,
though - if we had an infinite-resolution device, we'd get dithering
effects as the width shrunk that would make it appear to be a single
color.  We're just removing the singularity at width=0 by specifying
that it then represents the solid-color that the dithering is
approximating.  On a finite-resolution device, the singularity
effectively occurs when the width is equal to the width of a device
pixel, though actual dithering may occur at a larger width, if the
device pixels are small enough.)

Received on Friday, 27 May 2011 01:08:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:46 UTC