- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 25 Jan 2010 21:39:25 -0800
- 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. ~fantasai tempted to add an informative CSS2.1 Appendix J: Joins for Border Corners
Received on Tuesday, 26 January 2010 05:40:05 UTC