W3C home > Mailing lists > Public > www-style@w3.org > February 2009

Re: background-position-x & y

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 5 Feb 2009 15:23:28 -0600
Message-ID: <dd0fbad0902051323l2890224bj798f380de21fce2c@mail.gmail.com>
To: Faruk Ateš <faruk@apple.com>
Cc: Jorrit Vermeiren <mercator+w3c@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, www-style@w3.org

On Thu, Feb 5, 2009 at 3:08 PM, Faruk Ateš <faruk@apple.com> wrote:
>> I see one possible drawback to this approach. Doing sprites now, you
>> typically only define the background image URI once, and only need to
>> specify the background-position property for all the alternatives
>> (e.g. see the first post in this thread:
>> http://lists.w3.org/Archives/Public/www-style/2008Nov/0279.html).
>> Would such inheritance still be possible using this function notation?
> You make a good point; perhaps it would be more useful to have this sprite
> syntax:
> background-image: sprite(x-start, y-start, x-end, y-end[, url(path)]);
> With the fifth parameter having to be set only once if desired.
> I know the initial gut reaction to this is probably "but that would allow
> people to specify four coordinates without an image being set and that's
> confusing!"  but this is no more or less confusing than the ability and
> current practice of simply setting background-position: x y; for sprites and
> nothing else. Besides, we can specify all background properties as it is,
> without them making sense when background-image isn't specified, so that's
> nothing new there.

Interesting notion, and good point wrt this essentially already being
common practice.  While explicitness is good for comprehension, the
sprite() syntax is largely *meant* to be used multiple times on the
same image.  Thus it would be nice to simplify that use-case as much
as possible.  Specifying a sprite() with a uri on all the relevant
elements first, and then just specifying cut dimensions on individual
elements, would do this.

Received on Thursday, 5 February 2009 21:24:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:24 UTC