18384 2012-07-24 13:01:30 +0000 Add an adaptive image mechanism 2013-01-28 19:13:32 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified All All RESOLVED LATER https://www.w3.org/Bugs/Public/show_bug.cgi?id=18384 a11y, a11y_text-alt P2 normal --- 18171 1 laura.lee.carlson eoconnor attiks devarshipant eoconnor faulkner.steve mat me mike mjs odinho Paul.Cotton paul.irish peter.winnberg public-html-a11y public-html-admin public-html-wg-issue-tracking robin rubys w3c xn--mlform-iua public-html-bugzilla oldest_to_newest 71375 0 laura.lee.carlson 2012-07-24 13:01:30 +0000 Proposal: http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal Details: http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ June 2012 public-html Email Thread: http://lists.w3.org/Archives/Public/public-html/2012Jun/thread.html#msg105 July 2012 public-html Email Thread: http://lists.w3.org/Archives/Public/public-html/2012Jul/thread.html#msg123l 71376 1 laura.lee.carlson 2012-07-24 13:04:19 +0000 Two things that may be worth consideration: 1. The possibility of responsive text alternatives that could parallel the responsive images if needed. The <picture> proposal allows for different sources for images at different sizes. But authors could use different images at different sizes and not just a cropped down version of a single image. No text alternative mechanism is provided for that use case. Allowing alt on <source> could provide for that use case. Something like the following might work: <picture> <source src="mobile.jpg alt="text alternative"> <source src="medium.jpg" alt="text alternative" media="min-width: 600px"> <source src="fullsize.jpg" alt="text alternative" media="min-width: 900px"> <img src="mobile.jpg" alt="text alternative"> </picture> 2. A picture element could allow for semantic programmatically determinable in-page rich text long description, if a description element was added to the proposal: <picture> <img src="image.jpg" alt="text alternative"> <desc>structured rich text description with headings, lists, tables, etc.</desc> </picture> 71377 2 faulkner.steve 2012-07-24 13:08:54 +0000 copied from email http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0127.html I am concerned about the use of the alt attribute on <picture> when it would be much better to allow text alternatives inside the picture element. Some of the advantages are: Markup can be used to structure text alternative content. The length of the alt text is no longer a constraint, as it is currently for assistive tech. current example <picture alt="Description of image subject."> <source srcset="small.jpg 1x, small-highres.jpg 2x"> <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x"> <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg 2x"> <img src="small.jpg" alt="Description of image subject."> </picture> Is there any reason why you think the use of alt attribute on picture is preferable to <picture role="img"> <p>alt text</p> <source srcset="small.jpg 1x, small-highres.jpg 2x"> <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x"> <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg 2x"> <img src="small.jpg"> </picture> note:role=img is just of polyfill purposes. or <figure> <picture> <source srcset="small.jpg 1x, small-highres.jpg 2x"> <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x"> <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg 2x"> <img src="small.jpg"> </picture> <figcaption>caption text</figcaption> </figure> I can understand that backwards compatibility may be of concern in the first example, but that can be resolved through the use of CSS to clip or hide text content if so desired. 71378 3 laura.lee.carlson 2012-07-24 13:19:58 +0000 > I am concerned about the use of the > alt attribute on <picture> when it would be much better to allow text > alternatives inside the picture element. I agree Steve. Check consult comment 1. I think we would to think about the best way to handle both short and long text alternatives and well as the adaptive functionality of the element. Getting a picture element with accessibility thought out from the start would be a big win. 71380 4 xn--mlform-iua 2012-07-24 14:10:24 +0000 (1) Proposal: Perhaps someone should file a separate bug to track the accessibility of <picture>? (2) To reuse @alt would have backward compatibilty issues for AT tools. How? FIRSTLY: Today @alt is only supported on a finite number of elements. And, frankly, it is only supported (quite) well on the <img> elemetn. (It is not at all supported that well on <area> and <input> - I could mention a numnber of issues.) Even screenreaders do - at least in theory - only look for @alt on elements where they know that it ought to exist. SECONDLY: If instead we use mark-up as fallback/alternative text, the - until support is there - one can use @aria-describedby and @aria-labelledby in order to point to the fallback. By contrast, if one went for @alt, then the only way to be backward compatible would be by duplicating the @alt content with an @aria-label - like so: <picture alt="alternativ text" aria-label="alternative-text" >... </picture> (In reply to comment #2) > <picture role="img"> > > <p>alt text</p> > > <source srcset="small.jpg 1x, small-highres.jpg 2x"> > <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x"> > <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg > 2x"> > <img src="small.jpg"> > > </picture> > I can understand that backwards compatibility may be of concern in the > first example, but that can be resolved through the use of CSS to clip or > hide text content if so desired. Is it not as simple as setting <p>alt text</p> to <p style="display:none">alt text</p> ? Keep in mind that whenever one do <foo role="img">, then the content of <foo> is considered hidden from AT *anyway*. For an <foo role=img>, then one *MUST* use an @aria- attribute in order to hold or point to the accessible text. *OR* one must use an attribute (such as @alt) and - perhaps?- even an element that is especially designated for alterantive text. 71444 5 peter.winnberg 2012-07-25 12:44:35 +0000 Some comments about this. First of all I think it's great if we can get so called "responsive images" into a spec so that there is a recommended way to do it. But I see some issues about this and alternate text. In the proposal [1] it is said that all source elements in a picture element should represent the same subject matter. I don't think that will be the case. Take this example, someone makes a so called "mobile" design for their site. Both the regular site and the mobile design have a top banner image (but the mobile design's banner image takes up less space than the regular one). But they don't share the same subject matter. When the site is viewed with a width that is less than say 15em then the site switches to the mobile design. The problem now is that if we only have alt text for 1 image and the mobile design doesn't have the same content then the alt text would be incorrect. One way to solve this would of course be to have a alt attribute for each source attribute. On the other hand the specification could clearly state that all different source elements needs to share the same subject matter. But if people start (ab)using it the way I described above then there is no way for a validator to check this. I generally feel that if style="display:none" is needed then the design usually needs to be rethinked because it assumes that CSS is available everywhere, which it isn't. So it really only solves it for a subset of the user agents. [1] http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal 71445 6 laura.lee.carlson 2012-07-25 13:10:00 +0000 (In reply to comment #5) > On the other hand the specification could clearly state that all different > source elements needs to share the same subject matter. But if people start > (ab)using it the way I described above then there is no way for a validator to > check this. Hi Peter, I too worry that nothing is stopping authors from using different images and suggested possibility using responsive alt on source (see comment #1). Alternatively we would need some very strong spec text to outlaw different images. Suggestions? Maybe in the future it could be made machine testable? There are such things as TinEye. https://addons.mozilla.org/en-US/firefox/user/3304309/?src=api 71447 7 mat 2012-07-25 13:41:40 +0000 (In reply to comment #6) > (In reply to comment #5) > > On the other hand the specification could clearly state that all different > > source elements needs to share the same subject matter. But if people start > > (ab)using it the way I described above then there is no way for a validator to > > check this. > > Hi Peter, > > I too worry that nothing is stopping authors from using different images and > suggested possibility using responsive alt on source (see comment #1). > > Alternatively we would need some very strong spec text to outlaw different > images. Suggestions? Maybe in the future it could be made machine testable? > There are such things as TinEye. > https://addons.mozilla.org/en-US/firefox/user/3304309/?src=api I think it’s going to be important that this be posed as a means of providing alternate sources for *content* images ( http://www.bostonglobe.com/magazine/2012/07/22 or http://www.apple.com, for example ). A banner that displays different decorative banners would be most appropriately done in CSS -- this would likely be simpler for the authors as well, especially given the new `img-set` CSS syntax. I’m sure we’re apt to see `picture` used incorrectly for decorate images but no more than we already see with `img`, I wouldn’t think. It doesn’t hurt our case that this is such a high-profile issue in the dev community, and that `picture` is likely to see use from advanced and highly visible developers right away -- I think we’re likely to see a number of great examples of `picture` usage springing up almost immediately, paving the way for responsible usage in the future. 71652 8 attiks 2012-07-30 08:05:47 +0000 2 questions: 1/ Is it possible to allow width and height attributes on the source tags, this way the browser knows the dimensions before loading the image? 2/ Is it possible to allow the class attribute on the source tag and/or the picture tag? 72109 9 attiks 2012-08-13 08:53:45 +0000 Regarding 1, see also http://www.w3.org/community/respimg/2012/06/18/florians-compromise/#comment-1673 Strike question 2, class is supported on picture tag (In reply to comment #8) > 2 questions: > > 1/ Is it possible to allow width and height attributes on the source tags, this > way the browser knows the dimensions before loading the image? > > 2/ Is it possible to allow the class attribute on the source tag and/or the > picture tag? 75127 10 eoconnor 2012-10-02 22:33:55 +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: There are now a couple of extension specifications being actively pursued by members of the WG which address this feature request: http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html http://dev.w3.org/html5/srcset/ Instead of trying to separately address this feature in HTML5, we should wait for one or both of the extension specifications meet the CR exit criteria. This is why I've resolved this as LATER, instead of moving the bug into the HTML.next component (as we've been doing with other feature requests). 75211 11 w3c 2012-10-03 10:38:51 +0000 (In reply to comment #10) > Instead of trying to separately address this feature in HTML5, we should > wait for one or both of the extension specifications meet the CR exit > criteria. This is why I've resolved this as LATER, instead of moving the > bug into the HTML.next component (as we've been doing with other feature > requests). I think this is the right approach. I don't want the Responsive Images CG (RICG) to replicate work; And I think Hixie is in a much better position to specify the normative text needed to meet the use cases that the RiCG is pursuing. The RICG is focusing on the use cases to see if img@srcset meets all of them. The RIGC are working from the hypothesis that img@srcset does meet the use cases, but have identified a few places where it may not (Work in Progress): https://github.com/Wilto/draft-prop/blob/master/UseCaseComparisons.md We've also moved work to github: https://github.com/Wilto/draft-prop/ 75309 12 laura.lee.carlson 2012-10-04 17:52:30 +0000 Suggested Tracker Title: Add an adaptive image mechanism to HTML5.0 Suggested Tracker Description: Add an adaptive image mechanism per: http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html This mechanism should be incorporated into HTML5.0 proper and not pushed off into a ghettoized "extension". 75310 13 rubys 2012-10-04 18:25:33 +0000 Does this feature have either a thorough test suite or a single reasonably complete implementation? 75547 14 robin 2012-10-08 09:09:55 +0000 (In reply to comment #12) > This mechanism should be incorporated into HTML5.0 proper and not pushed off > into a ghettoized "extension". There's nothing "ghetto" about being in an extension spec. What matters is that a feature is implemented. Fighting over which document it goes into is the wrong battle. 81465 15 mjs 2013-01-16 08:57:39 +0000 https://www.w3.org/html/wg/tracker/issues/207 81538 16 laura.lee.carlson 2013-01-17 17:06:55 +0000 (In reply to comment #14) > (In reply to comment #12) > > This mechanism should be incorporated into HTML5.0 proper and not pushed off > > into a ghettoized "extension". > > There's nothing "ghetto" about being in an extension spec. What matters is > that a feature is implemented. Fighting over which document it goes into is > the wrong battle. If the responsive images group wants to pursue incorporating the picture element into HTML5.0, they can do so. But I withdraw my tracker request. I wish them the best. 82203 17 Paul.Cotton 2013-01-26 16:53:20 +0000 ISSUE-207 covering the questions of whether an adaptive image mechanism should be included in HTML 5.0 or published as an extension specification was resolved by a WG CfC: http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0185.html