Re: [css3-background] border-radius color transitions using gradients recommended but undefined

I was also reading Sylvain's "CSS Corner" blog entry about corner-radius.[1]

Sylvain, I think your team did a great job on putting the dots around the curved corners. It looked so much better than Firefox and Safari (and, I assume Opera in the lower left), that I wish that was in the spec. The part about dots being round already IS in the spec, so the Safari version is already out of compliance there (as it is on even solid lines, where it seems to draw the whole curve based on the side with the thicker border). And for that example, the other three all look clearly wrong in one way or another.

 Is this something that can be described in the text of Backgrounds & Borders? Something about how to handle the change in border-width at the corners for the various border-styles? That the border-style should remain in effect at the corners and around the curve (I'm looking at you Mozilla), with the dots remaining round and spaced the same as the straight parts. 

I'm also wondering if any of the ideas or text quoted below can be used, or if it needs changes, or if it is relevant to the way IE9 is handling dotted lines.

On Jan 27, 2010, at 10:25 AM, Brad Kemper wrote:

> On Jan 27, 2010, at 9:49 AM, Zack Weinberg wrote:
>> Brad Kemper <> wrote:
>>> Since border-styles are also part of the same spec, can we also
>>> tighten that up too? There is no inter-op currently on dot shape or
>>> spacing, so standardizing that would be unlikely to break anything
>>> substantially. For "dotted", it does now say "round" dots, and I
>>> think we can be more precise.
>> We are aware that Gecko's handling of dotted border corners is, um,
>> terrible; improvements are in development at
>> -- I can generate a
>> new set of builds with those patches if anyone is interested in testing
>> them.  (They do not, however, address the interaction between dots and
>> border-radius.)
>> Incidentally, those patches use square dots for borders that are less
>> than three device pixels wide, which I think should be officially
>> allowed.
> Sure. I think that is as reasonably close as you can get to a round dot at that size.
>>> ‘dotted’ 
>>> A series of round dots, evenly spaced around the entire border
>>> (including corners and border radii). The space between dots should
>>> be approximately equal to the width of one dot, but this spacing
>>> should be adjusted in order to achieve uniform spacing, with no less
>>> than .75 dot-width of space between dots. Spacing of dots may be
>>> different along vertical border sides than along horizontal border
>>> sides, in order to achieve symmetry at the corners.
>> I am not sure "no less than .75 dot-width of space between dots" and
>> "uniform spacing" are simultaneously achievable under all conditions.
> I'm not married to that particular number, if there are reasons to pick a different one. The idea is that a dotted line not be too crowded with dots, and that I'd rather have a little extra space between dots than not enough. Maybe not everyone here will agree with that preference, but we I'd like the spec to say something concrete like this about the spacing, as long as we are getting more precise about other parts (like the blending of colors in a corner radius). 
>> You should also be aware that it is *mathematically impossible* to draw
>> a dotted line which is uniformly spaced, one device pixel wide, an even
>> number of device pixels long, and has dots at both ends.  This is,
>> unfortunately, a common thing for Web authors to request.  I tried a
>> bunch of alternatives and came to the conclusion that the least
>> aesthetically offensive fallback is to omit dots at two of the four
>> corners of the box (assuming all four sides are drawn).
> I am OK with allowing that exception for single pixel thickness lines. I am more concerned with the much more noticeable problems when the border thicknesses are thicker, such as when it's 20 device pixels.


Received on Sunday, 21 March 2010 23:20:25 UTC