Re: Image sprites use cases

On Fri, Sep 4, 2009 at 7:46 AM, Patrick Garies<pgaries@fastmail.us> wrote:
> On 9/3/2009 6:10 AM, Alex Kaminski wrote:
>>
>> However it still does not provide much help to the developers of web
>>  applications and component libraries who also need an efficient
>> method to address many (possibly hundreds) of image fragments.
>
> Hmm... I went back and looked at some of the emails and it looks like a
> lot of the code [1] you're trying to kill comes from trying to emulate
> multiple operating systems and offering the same UI component at
> alternate sizes. I'm wondering if there aren't better solutions than
> using sprites to reduce code complexity.
>
> I have to ask:
> * How often do authors try to do such things (i.e., offer multiple OS themes
> and component sizes)? Is this primarily useful in libraries? (Libraries are
> expected to be complex, so if this is only useful in libraries, then perhaps
> this feature isn't really necessary especially if packages solve the HTTP
> problem.)

I guess multiple OS themes * multiple component sizes is an extreme
example and it is not common. Other libraries offer multiple OS themes
but usually in separate stylesheets. Most common approach is to make
OS-neutral theme and one fixed component size to keep things simple.
So yes, the complex case is probably a library-specific thing.

> * Do you have any examples of live, public Web sites that currently do
> either of these two things?

Unfortunately not. Most of or clients use the library for internal applications.

> * Could the desire for components in multiple sizes be solved with
> (scalable) vector image formats or better image-resizing algorithms in
> browsers?

Vector graphics - possibly yes. Image-resizing - no, as UI components
must be 'pixel-perfect'.

> * Could the desire for OS-specific appearances be solved with the CSS3
> Basic UI module? Maybe this could solve the sizes problem as well if
> they can be scaled?

I am not sure. The main thing in our library (and I guess most of the others)
is a datagrid control. So the choice is either to make a datagrid to match
the OS or to make everything in OS-neutral theme. That means that
basic UI controls must be fully skinnable. Currently we cannot do it
with built-in controls. So maybe yes, if there was a possibility to
modify the appearance of the system controls we would not need
to rebuild them and much of the problem would go away.

> * Since the style sheet is so repetitive, would it be easier and make
> more sense to just programmatically create it via ECMAScript? (I'm aware
> of accessibility concerns, but, in the example [1], a |div| element is
> used as a form control, so I can only assume that scripting is a
> requirement to use it at all; interestingly, if you were using a normal
> form control, presumably, you'd get the native appearance out of the box
> and a lot of your CSS could be eliminated). You seem to want something that
> a scripting language does better than CSS (specifically: loops).

Yes, this is possible solution and we are actually using it in some
other places.

>
> [1]
> http://www.w3.org/mid/6328fb9a0908301410t16bcb035u8792359b07cfa8ea@mail.gmail.com
>


-- 
Alex Kaminski
http://www.activewidgets.com

Received on Friday, 4 September 2009 07:39:48 UTC