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

Re: Image sprites use cases

From: Alex Kaminski <activewidgets@gmail.com>
Date: Mon, 31 Aug 2009 12:48:48 +0200
Message-ID: <6328fb9a0908310348r534bb5a1j6caebab1696f1d25@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org
On Mon, Aug 31, 2009 at 1:54 AM, Brad Kemper<brad.kemper@gmail.com> wrote:
>
> No, I think you misunderstood. I am saying that the file part only be
> specified once, and that the hash part changes which portion of the image is
> shown. Just as an HTML file is loaded once, and a hash Anchor (<A> tag) does
> not reload the file but just scrolls to a different portion.
>
> So the above would be written this way:
>
> .xp .checkbox.normal.small { background-image:
> url(xp/checkbox/small.png#xywh=0,0,10,10); }
> .true{ background-image: url(#xywh=25,0,10,10); }
>
> That is, the hash part (#xywh=25,0,10,10) only changes the area within the
> image, it does not change which file is loaded from the server. The second
> rule, above, would be equivalent to this:
>
> .true{ background-image: url(xp/checkbox/small.png#xywh=25,0,10,10); }
>
> ...
>
> So, in a sense it is like having two different properties (a later or more
> specific ur() functions with a file name would not overwrite a url()
> function that only contained the hash value), it could still be used
> wherever url() is used, without adding new properties to each url()-using
> property.
>
>

OK, now I understand. That an interesting idea, might work actually.

So what happens if the library user overwrites base url with his own image -
will the hash segments apply to the new image or the old one?


-- 
Alex Kaminski
http://www.activewidgets.com
Received on Monday, 31 August 2009 10:57:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:20 GMT