Re: [css3-images] radial-gradient issue raised by Brad

I'm strongly against using background-position and background-size instead of the radial gradient position and size arguments.

As an author, I'd expect that using background-size would constrain the gradient (including its extend color) to a box which is a subset of the background area. For example, I could then use multiple backgrounds to put two, differently colored bulls-eye gradients next to each other.

If we say that background-size only affects where the end of the gradient is, but that the extend color covers the entire background area, then it's impossible to use multiple backgrounds in the same way.

Additionally, when we start using gradient images in other places in CSS (e.g. as inputs to filters), we'll want control over the location and shape of the radial gradient part of the image in situations where background-* rules would not apply.

Simon

On Aug 12, 2011, at 4:28 PM, Brian Manthos wrote:

> http://dev.w3.org/csswg/css3-images/#radial-gradients
> # Brad suggests that we could drop the position/sizing arguments
> # and just use background-position and background-size. This
> # would force all non-background uses of radial gradient to be
> # centered and box-filling. Is this acceptable or not?
> 
> The current grammar is:
> 
> <radial-gradient> = radial-gradient(
> 	[<'background-position'>,]? 
> 	[[
> 		[<shape> || <size>]
> 		|
> 		[<length> | <percentage>]{2}
> 	],]? 
> 	<color-stop>[, <color-stop>]+
> )
> <shape> = circle | ellipse
> <size> = closest-side | closest-corner | farthest-side | farthest-corner | contain | cover
> 
> 
> For a moment, let's ignore the first parameter and the stops.  Thus we have the following combinations:
> 1	circle closest-side = circle contain
> 2	circle closest-corner
> 3	circle farthest-side
> 4	circle farthest-corner = circle cover
> 5	ellipse closest-side = ellipse contain
> 6	ellipse closest-corner
> 7	ellipse farthest-side
> 8	ellipse farthest-corner = ellipse cover
> 9	<length> <length>
> 10	<length> <percentage>
> 11	<percentage> <length>
> 12	<percentage> <percentage>
> 
> As I understand it, the proposed grammar is:
> 
> <radial-gradient> = radial-gradient(
> 	[<bg-position>,]? 
> 	[<bg-size>,]?
> 	<color-stop>[, <color-stop>]+
> )
> <bg-size> = [ <length> | <percentage> | auto ]{1,2} | cover | contain
> 
> Again, ignoring the first parameter and the stops, the following combinations are available:
> i	<length>
> ii	<length> <length>
> iii	<length> <percentage>
> iv	<length> auto
> v	<percentage>
> vi	<percentage> <length>
> vii	<percentage> <percentage>
> viii	<percentage> auto
> ix	auto
> x	auto <length>
> xi	auto <percentage>
> xii	auto auto
> xiii	cover
> xiv	contain
> 
> My initial thoughts of new syntax vs. old:
> A. [+1] Old has 16, new has 14. 
> B. [+2] Syntaxes 'i' and 'v' are added functionality, and potentially convenient.
> C. [-6] I'm unclear on the meaning or value of having the auto parameter (iv, viii, ix, x, xi, xii).
> D. [-1] No ability to distinguish ellipse vs. circle in cover (xiii vs 4, 8).
> E. [-1] No ability to distinguish ellipse vs. circle in contain (xiv vs 1, 5).
> F. [-2] Lost functionality for closest-corner (2, 6).
> G. [-2] Lost functionality for farthest-side (3, 7).
> 
> Tally that up: -9.
> 
> I strongly prefer the current syntax to the proposal.
> 
> 
> 
>

Received on Wednesday, 17 August 2011 17:20:01 UTC