Re: [css3-background] PFWG review of css3-background 2009-10-15 LCWD

On Wed, Jan 6, 2010 at 11:53 AM, Michael Cooper <cooper@w3.org> wrote:
> The following is review comments from the Protocols and Formats Working
> Group on CSS 3 Backgrounds and Borders, Last Call Working Draft of 15
> October 2009 <http://www.w3.org/TR/2009/WD-css3-background-20091015/>. We
> are aware these comments are late (due to process difficulties on our end)
> and apologize for that, and will take our delay into account in how we
> address your responses. PFWG approval to send these comments was obtained 6
> January 2010 http://www.w3.org/2010/01/06-pf-minutes.html#item05.
>
> The basic issue is that in low-vision scenarios, CSS backgrounds are often
> disabled. This is correct behavior, because in these scenarios, the user
> agent changes all the colors, and removes background decoration, gradients,
> etc. in order to improve readability. This happens with Operating System
> High Contrast settings, and is also done by some assistive technology.
>
> Many Web developers are using CSS to apply images that are necessary for
> understanding and operating a Web site, for example, a graphic that defines
> a button or other clickable area.  The developers are doing this to improve
> performance, by adding all the graphics for a page to a single image file,
> and using CSS positioning and clipping to apply to it various UI elements,
> thereby reducing the number of http requests.  This approach is sometimes
> called ‘sprites’.  Developers who use sprites are often unwilling to give up
> the performance in order to provide accessibility to low visions users, as
> doing so can often have rather significant monetary costs (additional
> servers, increased bandwidth consumption, etc).
>
> Users who use high contrast settings or AT with similar behavior, will not
> see sprites, and the site will not be accessible to them.
>
> What is needed is a mechanism that allows developers to indicate that a
> particular application of an image by CSS is a sprite, and should not be
> removed when backgrounds are removed.  It would also be nice to have a
> mechanism to provide different graphics to these users, such as graphics
> drawn in high contrast.

The current usage of sprites is a dirty hack, and is a problem only
because (a) as you said, there are performance benefits to spriting in
many circumstances, and (b) using the background property is currently
the only reliable way to extract a sprite from an image.

Better ways to address this use-case are being developed.  There are a
few suggestions about how to generalize the idea of sending multiple
resources in a single item, and easily make the sub-pieces available
to the page.  There is also an effort in the CSS Images module to
address spriting directly and make it generally useful in CSS, rather
than only being useful in backgrounds.  Finally, the Media Fragments
WG is developing a syntax (with a public draft already published) to
allow addressing a portion of an image directly in the url identifying
it, so as to make sprites generally available to all web technologies.

The first and third approach listed apply in HTML as well as CSS, and
would allow authors to use ordinary <img> tags (with alt text) while
gaining the performance benefits of current spriting techniques.

I don't believe layering another hack on top of the current
background-image hack is the correct solution; rather, we should find
ways to meet author's performance needs in a way that is more flexible
and generally useful than current spriting techniques.

> Here’s one suggestion of how to address this issue.
>
> foreground-image:  Foreground images sit on top of background images, but
> are otherwise identical.  They are semantically different, in that they are
> images that are intended to be the only rendered representation of the
> element.  Foreground images MUST NOT be disabled by assistive technology.
>
> foreground-image-high-contrast:  If this property is specified, this image
> MUST replace the foreground image when the user agent is rendering in high
> contrast mode, in response to operating system, browser, or assistive
> technology settings.
>
> background-image-high-contrast:  If this property is specified, this image
> MUST replace the background image when the user agent is rendering in high
> contrast mode, in response to operating system, browser, or assistive
> technology settings.

High-contrast situations should be differentiated through Media
Queries, I would think.  This would allow you to specify different
background images, and also different values for any other property
that requires tweaking.

~TJ

Received on Wednesday, 6 January 2010 19:01:30 UTC