Re: background-position and -origin

Eric A. Meyer wrote:
>    I noticed the CSS WG tweet about a proposed change to 
> 'background-position' that would extend it to help define the origin 
> corner of a tiled background image.  Since I've occasionally agitated 
> for this ability, and have bounced around a few ideas along those lines, 
> I thought I'd bring up the topic here for more in-depth discussion.
>    I find the ability to declare 'bottom 1em right 33%' to be very 
> interesting, and it definitely meets the need.  There's a smallish part 
> of me, though, that feels like this is mixing two concepts: origin 
> corner and offset.  I do think there's a strong case to be made for 
> mixing the two, since they're so closely related.
>    Another possible solution with its own strengths is to leave 
> 'background-position' at just declaring offsets, and redefine 
> 'background-origin' so that it takes three keywords: two defining the 
> corner, and one defining the "origin edge".  So to get the origin point 
> to be the top right padding edge, you would declare either of the 
> following:
>    background-origin: top right padding;
>    background-origin: padding top right;
> That makes the value syntax something like (I left out the "in any 
> order" magic symbols for clarity):
>    [ [ top | bottom ] [ right | left ] ]? [ content | padding | border ]?
> ...and then do the comma voodoo to extend that to account for multiple 
> background images.  I guess that means defining the above pattern (or a 
> cleaner version of same) to be 'bg-origin' and then defining the value 
> for 'background-origin' to be '<bg-origin> [, <bg-origin>]*'.  The 
> default for 'bg-origin' would be 'top left padding' to reflect 
> historical behavior.
>    In order to disambiguate things ever so slightly, we could change 
> 'content | padding | border' to 'content-edge | padding-edge | 
> border-edge'.  I'm not sure doing so really buys us anything worth 
> obtaining, though.
>    I had been thinking that a reason to take this approach would be to 
> prevent backwards-compatibility problems, since 'background-position' 
> with keywords mixed in will be ignored by old UAs, but then I realized 
> that any page that uses more than one background image (thus invoking 
> the comma-separated syntax) or that uses 'background-origin' to change 
> the origin of even a single background image is going to confuse old UAs 
> anyway.  So the backward-compatibility argument has pretty much the same 
> bearing either way.
>    At this point I'd be just as happy with either one, but thought 
> providing an alternate idea as a starting point for discussion might be 
> helpful.

Hi Eric,
Thanks for your comments. It's an interesting idea, and would certainly
make the property name more meaningful, but Bert and I think the
backwards-compatibility story of specifying the corner and the offset
together is better:

What do you think?


Received on Thursday, 14 August 2008 19:02:45 UTC