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

> From: fantasai [mailto:fantasai.lists@inkedblade.net]
> Sent: Tuesday, January 26, 2010 3:04 PM
> To: Brian Manthos
> Cc: Brad Kemper; Arron Eicholz; Sylvain Galineau; www-style@w3.org;
> Andrew Fedoniouk; Zachary Weinberg
> Subject: Re: [css3-background] border-radius color transitions using
> gradients recommended but undefined
 
 
> I think these are both good questions and that we should answer them
> before speccing anything.

If the availability of software and/or hardware primitives do constrain the
feasibility of the rendering that is most expected for this scenario then shouldn't 
we investigate *before* recommending that UAs do it ?

> I know that Microsoft wants everything defined down to the sheen on
> the door nails, but sometimes it is appropriate to intentionally leave
> slack in a W3C specification, and I believe the details of corner joins
> for CSS3 Backgrounds and Borders is one of those places. 

I'm very glad that someone on the WG would state so publicly that Microsoft 
has high standards but I guess I should have expected that when it came, it'd be
as a criticism. 

You're right in one respect: we are going to ship software that implements this spec, and
we expect our implementation to be complete and interoperable. 

As the current prose recommends that we implement an unspecified behavior that will make other 
normative statements in the spec untestable, it is thus simply not acceptable for you as main co-editor 
to summarily dismiss our concern in this manner.

For instance, in http://www.w3.org/TR/css3-background/#the-border-radius:


 #The center of color and style transitions between adjoining borders is at the point on the 
 #curve that is at an angle that is proportional to the ratio of the border widths. For example, 
 #if the two widths are equal, that point is at a 45° angle, and if one is twice the width of 
 #the other the point is at a 30° angle. The line demarcating this transition is drawn between 
 #the point at that angle on the outer curve and the point at that angle on the inner curve.

This is not just implementable (as we know); the correct position of this demarcation line is 
also testable using simple reference bitmaps or Mozilla-style reftests to ensure the color and 
visual 'shape' of each side is valid. 

Until, that is, we follow your recommendation using the apparently so desirable lack of 
guidance around it by applying our own proprietary Microsoft-cooked gradient algorithm. Now no one 
outside Microsoft can write a testcase to verify whether we comply with otherwise clear normative 
requirements as to the position  of the color transition line. As said transition line position 
should presumably affect what any gradient algorithm produces along the curve, it should matter. Thus, in 
the absence of a normatively specified mechanism to opt out of the corner gradient without also losing 
the curve, this recommendation does allow a UA to ship a buggy implementation as long as it looks 
'close enough'. 

That may make writing testcases and completing the spec's CR exit criteria a much more fun exercise, 
but the technical term among us crusty old nail polishers really is: What The F... !?

This is not about extreme border collision testcases almost no one will ever use on a real web site. This is 
about validating clear, simple normative requirements, and ensuring that in common use-cases browsers *can* do 
the same thing and be verified to do so. Or, if they disagree on what the 'same thing' should look like, 
that they keep experimenting behind their respective vendor prefix instead of opting in all of their respective users 
into their preferred temporary solution by hijacking a CR or REC property. The 'slack' for this kind of 
experimentation already exists: it starts with -moz, -webkit-, -o, -ms etc.

Overall, I can't justify implementing this unspecified behavior under border-radius today. We might support it under
our vendor prefix though, in addition to border-radius. Which ultimately implies that for this simple scenario, 
Firefox and IE might end up doing rather different things from authoring to rendering for years to come. And 
the experimentation may not stop at Firefox and IE. 

The web authors who care will, as usual, be caught in the middle.

I would expect one of the spec's main editor to give such an outcome careful consideration during CR. So far, all I have 
heard from you can be summarized as: "I don't want to deal with it because I have better things to do than polishing nails" 

Well, that's dandy. If *you* can't be bothered, I certainly have better things to do than trying to guess the unspecified 
behavior of recommended CR features on the outside hope the result will interop with what my competitors *might* make up 
in their own corner. Someday. Maybe.

There are lots of other important things to, you know, nail around here :)

Received on Wednesday, 27 January 2010 01:45:12 UTC