This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13514 - Support different resolutions for command elements
Summary: Support different resolutions for command elements
Status: RESOLVED REMIND
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Edward O'Connor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf
Depends on:
Blocks:
 
Reported: 2011-08-02 03:21 UTC by Greg Lowney
Modified: 2013-02-22 18:27 UTC (History)
12 users (show)

See Also:


Attachments

Description Greg Lowney 2011-08-02 03:21:03 UTC
HTML5 should allow the author to link a command elements to multiple images optimized for different screen resolutions and zoom ratios. This is currently supported for page icons but not for icons associated with the command element. It should also allow static images (e.g. the img element) to also reference multiple images optimized for different resolutions, so that pages can better adapt to different screen resolutions and zoom ratios without having to resort to complex scripting.

Use case: Todd is working on a high resolution monitor but has moderately low vision, so he uses his browser's zoom setting so that he can read the text easily and discern the details of images. He goes to a web page that includes multiple buttons implemented using command elements, each represented by an icon. Unfortunately, since HTML5 only allows a command element to link to a single image, the browser has to use brute force methods to enlarge the image, with a result that's blocky and difficult to understand. If the author had been able to link to multiple versions of the image, each optimized for different screen resolutions or sizes, Todd could have been presented with graphical buttons he could understand.

Some competing solutions to this problem have been proposed, including CSS Image Values, multi-resolution images, and of course script solutions, but it is not yet clear which if any of these will survive.
Comment 1 Tab Atkins Jr. 2011-08-02 03:50:35 UTC
Vector graphics is another, better, solution - they work at every resolution.  Just provide the image in SVG format.
Comment 2 Michael[tm] Smith 2011-08-04 05:35:44 UTC
mass-move component to LC1
Comment 3 Joshue O Connor 2011-08-07 07:51:01 UTC
(In reply to comment #1)
> Vector graphics is another, better, solution - they work at every resolution. 
> Just provide the image in SVG format.

Agreed, however the use of SVG in the wild is still not really very widespread, there aren't many editors that support the format etc. Also if the spec could indicate that displaying controls in SVG or other vector formats had benefits like those outlined, that would be helpful. While it's not fully germane to HTML 5, this would help in situations that Greg outlines (if authors where are that vector graphics didn't pixelated and understood the benefits of scalability a la SVG etc).
Comment 4 Tab Atkins Jr. 2011-08-07 19:31:45 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > Vector graphics is another, better, solution - they work at every resolution. 
> > Just provide the image in SVG format.
> 
> Agreed, however the use of SVG in the wild is still not really very widespread,
> there aren't many editors that support the format etc.

Sure, but trying to work around one unsupported feature by introducing another feature (which by definition isn't yet supported) isn't generally a winning game plan. ^_^  As long as the first feature is expected to be supported more widely (which SVG is), time will solve the problem for you without any new features needed.

> Also if the spec could
> indicate that displaying controls in SVG or other vector formats had benefits
> like those outlined, that would be helpful. While it's not fully germane to
> HTML 5, this would help in situations that Greg outlines (if authors where are
> that vector graphics didn't pixelated and understood the benefits of
> scalability a la SVG etc).

Sure, that might be nice.  Could you file another bug saying so, perhaps with some example text to be inserted?
Comment 5 Michael[tm] Smith 2011-11-20 15:24:18 UTC
Josh, Greg, this bug is waiting on responses to comment #4.
Comment 6 Ian 'Hixie' Hickson 2011-11-24 02:55:07 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 5
Comment 7 Greg Lowney 2012-01-16 22:10:41 UTC
Scalable images would address the problem of larger images, but it fails to address other use cases. Ideally we would allow the author to specify multiple images that could be selected based on conditions such as desired size, color depth, and whether the display supports colors vs. grayscale. For example:

(a) If only a single vector image is provided, it will generally work well at larger sizes but often fails at sizes smaller than it was designed for, as details become invisible, or the important details become lost as their distinction from background is reduced. People may want small icons when using small displays, or displaying content in a small viewport in order to reserve screen real estate for assistive technology, or when cognitive disabilities require them to keep a lot of information on the screen at one time rather than scrolling or overlapping windows. 

(b) An image designed for millions of colors may likewise prove unusable on a monochrome or grayscale display, when color depth is reduced to improve performance when using remote access tools over relatively slow connections, or or when the user has reduced the color depth to compensate for a visual impairment. 

I admit these are not the most important problems in the world, but when defining a new specification it makes little sense to ignore these issues.
Comment 8 Ian 'Hixie' Hickson 2012-01-24 20:44:32 UTC
(I assume the assignee should have been changed back with the last comment. Please let me know if I am mistaken.)
Comment 9 contributor 2012-07-18 04:37:18 UTC
This bug was cloned to create bug 17799 as part of operation convergence.
Comment 10 Edward O'Connor 2012-10-16 17:36:50 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: No spec change.
Rationale: Let's consider this for HTML.next.
Comment 11 Robin Berjon 2013-01-21 16:00:16 UTC
Mass move to "HTML WG"
Comment 12 Robin Berjon 2013-01-21 16:03:00 UTC
Mass move to "HTML WG"
Comment 13 Edward O'Connor 2013-02-12 21:58:14 UTC
Changed the title to only be about <command>, since the <img> case is being addressed by the various adaptive image extension specifications (<picture> and srcset="").
Comment 14 Edward O'Connor 2013-02-22 18:27:40 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Additional Information Needed
Change Description: No spec change.
Rationale: Let's wait to see what browser engines implement for adaptive
content images, then base the solution to this bug on that. Resolving as
REMIND so that I remember to check on this later.