W3C home > Mailing lists > Public > www-style@w3.org > January 2010

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 25 Jan 2010 21:39:25 -0800
Message-ID: <4B5E800D.8090404@inkedblade.net>
To: Sylvain Galineau <sylvaing@microsoft.com>
CC: "www-style@w3.org" <www-style@w3.org>, Andrew Fedoniouk <news@terrainformatica.com>, Zachary Weinberg <zweinberg@mozilla.com>, Brian Manthos <brianman@microsoft.com>
On 01/25/2010 05:25 PM, Sylvain Galineau wrote:
> Both the Candidate Recommendations [1] and the latest editor's draft [2] currently state:
> "It is not defined what these transitions look like, but a gradient
> is recommended for color transitions that don't involve dotted or
> dashed borders."
> The gradient transition is recommended but remains undefined. Thus
> all that could reasonably be tested here is whether the UA does or
> does not perform the border color transition using a gradient instead
> of a 'sharp' line divider.  Whether the implemented gradient behaves
> interoperably across browsers  could not be verified, however (never
> mind whether the result fulfills designers' needs and expectations).
> If this behavior is important to designers - and we believe it is -
> then the spec ought to specify an interoperable solution.
> Alternatively, we might remove this recommendation from the spec;
> the behavior thus far implemented behind vendor prefixes would thus
> remain the default across all border-radius values until a Level 4
> version of the module. This outcome would be less interesting but
> it would be far more likely to result in a matching, testable default
> rendering across two+ implementations than the current prose.
> Given that the spec is in CR and early implementations are already
> dropping their vendor prefix (e.g. Opera 10.50 pre-Alpha), I was
> wondering whether other vendors were interested in designing a
> solution for this recommended behavior during the CR period.

I'm not comfortable with normatively requiring a particular gradient
form or a particular type of corner join in css3-background. I don't
think we have clear answers as to what would look best--other than it
should be a type of conic gradient--so I want to leave implementations
free to experiment. It's fine IMO to leave this detail of border
rendering undefined in CSS3: it gives it a chance to evolve as
implementers learn from each other and from author feedback.

Note that the spec currently defines the "center" of color transitions
normatively, and this definition applies to gradients as well. This
does limit the number of acceptable options for gradients. I could
specify that it should be a conic gradient, but there are some (likely-
to-be-common) degenerate cases whose ideal rendering might not be
exactly conical. [1]

I *am* interested in soliciting ideas for good corner joins, but I think
this should go into an informative appendix, not the normative prose.
Zack Weinberg had some nice mockups for variant style joins, and Andrew
Fedoniouk had posted some great screenshots of conical gradient corners.
I think with a gallery of good examples, we can encourage good rendering
without getting stuck trying to normatively define the right behavior.

[1] See, for example, border-top-right-radius: 100%. Pick different
colors for each side and some thick widths so you can see what's going
on. If we take the (fairly reasonable, imho, though unrequired)
invariant that the left and right border colors must never be directly
adjoining, and follow the rule about the center of color transitions
given in the spec, the result is not going to be a simple conic gradient,
whatever it is.

tempted to add an informative CSS2.1 Appendix J: Joins for Border Corners
Received on Tuesday, 26 January 2010 05:40:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:42 UTC