13514 2011-08-02 03:21:03 +0000 Support different resolutions for command elements 2013-02-22 18:27:40 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified All All RESOLVED REMIND a11y, a11ytf P2 normal --- 1 gcl-0039 eoconnor cooper eoconnor gcl-0039 ian jackalmage joshue.oconnor laura.lee.carlson mike public-html-a11y public-html-admin public-html-wg-issue-tracking robin public-html-bugzilla oldest_to_newest 51945 0 gcl-0039 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. 51946 1 jackalmage 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. 54062 2 mike 2011-08-04 05:35:44 +0000 mass-move component to LC1 54350 3 joshue.oconnor 2011-08-07 07:51:01 +0000 (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). 54368 4 jackalmage 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? 60204 5 mike 2011-11-20 15:24:18 +0000 Josh, Greg, this bug is waiting on responses to comment #4. 60427 6 ian 2011-11-24 02:55:07 +0000 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 62788 7 gcl-0039 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. 63069 8 ian 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.) 70067 9 contributor 2012-07-18 04:37:18 +0000 This bug was cloned to create bug 17799 as part of operation convergence. 76416 10 eoconnor 2012-10-16 17:36:50 +0000 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. 81752 11 robin 2013-01-21 16:00:16 +0000 Mass move to "HTML WG" 81870 12 robin 2013-01-21 16:03:00 +0000 Mass move to "HTML WG" 83052 13 eoconnor 2013-02-12 21:58:14 +0000 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=""). 83574 14 eoconnor 2013-02-22 18:27:40 +0000 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.