This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 13514 as part of operation convergence. Originally filed: 2011-08-02 03:21:00 +0000 Original reporter: Greg Lowney <gcl-0039@access-research.org> ================================================================================ #0 Greg Lowney 2011-08-02 03:21:03 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #1 Tab Atkins Jr. 2011-08-02 03:50:35 +0000 -------------------------------------------------------------------------------- Vector graphics is another, better, solution - they work at every resolution. Just provide the image in SVG format. ================================================================================ #3 Joshue O Connor 2011-08-07 07:51:01 +0000 -------------------------------------------------------------------------------- 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). ================================================================================ #4 Tab Atkins Jr. 2011-08-07 19:31:45 +0000 -------------------------------------------------------------------------------- (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? ================================================================================ #5 Michael[tm] Smith 2011-11-20 15:24:18 +0000 -------------------------------------------------------------------------------- Josh, Greg, this bug is waiting on responses to comment #4. ================================================================================ #6 Ian 'Hixie' Hickson 2011-11-24 02:55:07 +0000 -------------------------------------------------------------------------------- Status: Did Not Understand Request Change Description: no spec change Rationale: see comment 5 ================================================================================ #7 Greg Lowney 2012-01-16 22:10:41 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #8 Ian 'Hixie' Hickson 2012-01-24 20:44:32 +0000 -------------------------------------------------------------------------------- (I assume the assignee should have been changed back with the last comment. Please let me know if I am mistaken.) ================================================================================
Apologies if mentioned or intimated previously, but would CSS media queries help here?
My intent here is to wait until next year, in the hopes of getting implementation experience with srcset="". Then, once we know what the story is with that, we can adopt the same solution for these. So, for example, if it turns out srcset="" isn't adopted and something like the <picture> proposal is adopted instead, we can make sure to use that information to design the solution here in line with that.
Still awaiting srcset implementation experience. Will revisit in Q4 unless new information comes up before then.
I'm delaying this pending <picture>.
The <command> element is no longer in the latest spec as it was never implemented. However, this still applies to https://html.spec.whatwg.org/multipage/forms.html#the-menuitem-element, which is somewhat close to being implemented in two places. I still think we need to wait for slightly wider experience with <menuitem> before working on this.
Please file a new issue at https://github.com/whatwg/html/issues/new if this is still desired. (<menuitem> got dropped too.)