Re: [css3-images] Color as an image type

On Mon, Nov 29, 2010 at 2:39 PM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Tab Atkins Jr.:
>> Now, we have the image fallback function … - if you just provide a fallback color and no images, it'll return an image of that color - image(yellow).
>
> That part of the ED currently reads:
>
>  <image-list> = image( [ <image-decl> , ]*
>                        [ <image-decl> | <color> | <gradient> ] )
>
>  <image-decl> = [ <string> | <url-token> ] [ snap? && <resolution> ]?
>
> This way, you exclude ‘image(<gradient>, <color>)’ which might be useful for backwards compatibility. Therefore <gradient> would have to be a superset of <color>, but then <color> would be unnecessary in the production quoted above.
>
>  <image-list> = image( [ <image-decl> , ]*
>                        [ <image-decl> | <gradient> ] )

The image() function is not meant to aid in *syntax* fallback, just
image-availability fallback.  It's impossible to do the former without
getting really weird with the definition of the function - normally,
using an unknown/unimplemented value is just treated as invalid
syntax, and invalidates the whole rule.  Thus, any UA that doesn't
understand <gradient> won't understand image(<gradient>,<color>)
either.

CSS already handles this case by exploiting the "invalidate the rule"
behavior, so you can provide multiple versions of a rule.  In this
case, you should use something like "background: <color>; background:
<gradient>;".


> Also, you might prefer a CSS gradient over a gradient from a picture resource for clients that support the former. So you should rather use one of those, if I’m not missing something:
>
>  <image-list> = image( [ [ <image-decl> | <gradient> ] , ]*
>                          [ <image-decl> | <gradient> | <color> ] )
>
>  <image-list> = image( [ [ <image-decl> | <gradient> ] , ]*
>                          [ <image-decl> | <gradient> ] [ , <color> ]? )
>
>  <image-list> = image( [ <image-decl> , ]*
>                        [ <image-decl> | [ <gradient> , ]? <color> | <gradient> ] )

Same answer as above.  You should use "background: <image>;
background: <gradient>;".


> Something else; the definitions of the two gradient variants can be described like this:
>
>  <gradients>   = [ <direction> , ]?
>                  [ <options> , ]?
>                  <color-stops>
>
>  <direction>   = <start> || <angle>
>
>  <color-stops> = <color-stop> [ , <color-stop> ]+
>
> where <start> and <options> differ among the two, i.e. <options> being empty for linear gradients and
>
>  <options> = [ [ <shape> || <size> ] | [<length> | <percentage>]{2} , ]?
>
> for radial ones.

I don't think it would gain anything to unify these in this way.  The
treatment of the starting arguments is significantly different between
linear and radial gradients, so I think it would be confusing to
express them in the spec like they were the same thing.

As well, the grammar is incompatible in any case - linear allows a
keyword *or* an angle, while radial allows both (and I may just drop
the angle from radial - it's of very marginal utility, and I think
that now that I have an explicit form for radials that utility has
evaporated completely).


> I wonder whether <start> could be unified to the one from radial gradients, i.e. (the normative references are still missing btw.)
>
>  <start> = <bg-position>
>
> where it’s currently one of background position’s subsets for linear gradients:
>
>  [ [top | bottom] || [left | right] ]
>
> so you can only select edges and corners.

I recently and purposely simplified linear gradients to only take
those keywords, so that I can map them to just an angle.  You can read
my reasoning in the most recent thread about gradients - basically, it
makes transitions between gradients both simple and pretty.


> In the section on <color-stop>, which btw. should be moved to section 5.3 because it’s a feature common to both types,

Yeah, I may do that.


> you already (implicitly at least) allow negative values and values beyond 100%. If you define the angle for corner-only uses as towards the center of the rectangle, which is equivalent to using the opposing corner, as it is specified now, that would be usable for arbitrary starting points, too. The only edge case would be “linear-gradient(center center, yellow, blue)” which should probably be all blue.

I think that most linear gradients will go from one end of the box to
the other.  I don't see what would be gained by this that would offset
the fact that gradient now have to stretch from 0% to 200% to fill the
box.

~TJ

Received on Monday, 29 November 2010 23:05:33 UTC