Re: [whatwg] summary/details - proposal
On 8 April 2014 21:54, Tab Atkins Jr. jackalm...@gmail.com wrote: I still don't understand. Do you think that what Hixie is saying (about clicking on non-interactive text in summary toggling the details) is wrong? nope. The behavior that Hixie describes is roughly what implementations do today. In Blink, clicking on any bare text in the summary toggles the details, while clicking on an input does not. However, Blink current behavior with label is different - it basically ignores the presence of the label, as far as I can tell, and still toggles the details even if the label is redirecting the click to an input. Implementations today have the summary element as the focusable/interactive element. this has several pros/cons what I am trying to achieve is to have the pros defined as part of the feature. I would strongly object to any suggestion that summary should only toggle details when you click on the disclosure triangle, I cannot agree more, which is why I have brought up the issue here and elsewhere. Hixie talks about platform conventions and UAs deciding, and as I have pointed out several times the OSX platform convention is just what you describe. and as you say would be terrible UI. unless you add some additional markup like label. That would be terrible UI. I would prefer that the summary element acted as the label the disclosure triangle of the details element, thus providing a reasonable default click area and focus are and source for the accessible name of the control. I see a few issues, which is why I have suggested allowing the use of label (to provide both a clickable area that can be assigned by the author and provide an explicit method to assign an accessible name) 1. When the summary element also includes links or other controls each with their own accessible name, providing an unambiguous accessible name for the disclosure triangle becomes problematic. 2. I have observed that assigning an accessible name for a control in the shadow DOM from the DOM is not possible. Thus my question to the list/hixie: What's the mechanism by which the anonymous control for details can be assigned an accessible name? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] summary/details - proposal
On 7 April 2014 20:06, Ian Hickson i...@hixie.ch wrote: Should there be a particular need for an accessible name for the details control, ARIA can be used to set the name. But I must admit to not understanding why you would need that in practice, if the page is well written. (I find most pages that use accessible labels in situations such as this tend to be poorly written for non-AT users.) All controls are expected to have an accessible name and it is expected that the author is able to assign one. this is accessibility 101 across all platforms. Lack of an accessible name or a generic accessible name or an ambiguous accessible name causes issues for users. What's the mechanism by which the anonymous control for details can be assigned an accessible name? Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. avoiding unnecessary recourse to web component use is a reasonable and expected goal - built in vs bolt on accessibility is better. Having to use a web component to overcome the inability to make a html control usable without relying on CSS and Js and ARIA is unfortunate, and as you said yesterday once you're using custom components you've pretty much sacrificed the ability for the web to work without css and js, especially if you don't have a fallback element... http://krijnhoetmer.nl/irc-logs/whatwg/20140407#l-396 -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] summary/details - proposal
-- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 6 April 2014 05:11, Ian Hickson i...@hixie.ch wrote: On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. It also provides the best choice for users, large click area and focus ring, Its also simple for authors in the majority of use cases. while on Mac OSX only the disclosure triangle (approx 13X13px) itself is clickable and has a focus rectangle. details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, how so? with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? not to mention all the problems it would cause with the existing label definitions. may be making the details element a labelable control would be simpler, as its be definition an interactive control. would it cause problems for existing label definitions? details id=x summary label for=xFoo/label /summary ... /details -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
-- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 6 April 2014 21:08, Ian Hickson i...@hixie.ch wrote: On Sun, 6 Apr 2014, Steve Faulkner wrote: On 6 April 2014 05:11, Ian Hickson i...@hixie.ch wrote: On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed Not what I said, but the current implementations use of summary as the interactive element matches, the first example under usage patterns http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx#patterns details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, how so? All that should be necessary is: details summary Foo /summary ... /details Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. for the case details summary Foo input Bar /summary ... /details whats the disclosure label? what about? details summary labelinput Bar /label/summary ... /details in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. does this also extend to the author being able to provide an accessible name for the control? Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] summary/details - proposal
note: bringing this to the whatwg list to elicit feedback from implementers and other interested parties that are not involved in the discussion at the W3C Currently the implementation(s) of summary/details elements do not match the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element In the spec, the details element is interactive content, the summary is not, its a summary, caption, or legend. in webkit/blink the summary element is the interactive element (when pressed it opens/closes the details element) This is good because it provides a large default hit region to activate the control example to try in chrome/safari/opera http://codepen.io/stevef/pen/CyauJ/ So as the spec/implementations are at odds, the implementations need to change to match the spec or the spec needs to change to match implementations or the spec needs to change to accommodate the positive aspects of the current implementations while allowing for other use cases An issue with current implementations is that when the summary element includes other interactive elements (as it is allowed to), clicking on them results in the details element being opened/closed (although this can be overcome via scripting). example to try in chrome/safari/opera http://codepen.io/stevef/pen/xjJiy/ Issues with the current spec text: The interactive part of the details element is the disclosure triangle ► which is supposed to be an anonymous control in the shadow DOM The summary itself is not interactive, so only the triangle provides the actionable control. the summary text which is effectively the label for control does not activate the control. There is no method provided to associate a label with the anonymous control that can (a) provide an increased hit region and (b) provide an explicitly associated label for the anonymous control. Given that what we want to provide for the use case of having controls inside the summary, after discussion around the issue[1], I have proposed the following: details summary id=x label for=xFoo/label /summary ... /details what this does is provide the author with the ability to add an explicit label (providing the acc name) to the details control which also increases the click region for improved accessibility/usability, while still allowing interactive content inside the summary element. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25140 feedback welcome! -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] hit regions: limited set of elements for fallback content
Nils Dagsson Moskopp wrote: But still, people (with the exception of Paul Graham) stopped using table for layouts if only that were true, take a look at https://www.google.co.uk or grep the html data available from http://webdevdata.org Also, Faulkner wanting an example of canvas to make accessible ... seems like circular reasoning to me to use that as an example why we need an accessible canvas. ? -- stevef
Re: [whatwg] hit regions: limited set of elements for fallback content
hixie wrote:
But there's plenty of things which make zero sense as fallback content.
input type=color, for example, simply cannot be sanely implemented in
canvas
as implemented input type=color is a button that when activated pops up a
picker dialog. So the following code (as a simple example)
canvas id=myCanvas width=200 height=100
style=border:1px solid #00;
onclick=document.getElementById('button').click();
input type=color id=button
/canvas
in Firefox 30/windows when the canvas is clicked the color picker is
displayed., likewise if the the input receives focus via the keyboard and
the enter/spacebar key is pressed the picker dialog is displayed.
--
Regards
SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
Message: 9
Date: Tue, 12 Nov 2013 10:54:54 -0800
From: Adam Barth w...@adambarth.com
To: John Mellor joh...@google.com
Cc: Jukka K. Korpela jkorp...@cs.tut.fi, Markus Ernst
derer...@gmx.ch, whatwg whatwg@lists.whatwg.org,
Markus Lanthaler
markus.lantha...@gmx.net, Ryosuke Niwa rn...@apple.com
Subject: Re: [whatwg] imgset responsive imgs proposition (Re: The
src-N proposal)
Message-ID:
caje5ia_pzceu9prvaxfy--pqbqjh1t7+kfcaw9fuvmk7mfr...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Nov 12, 2013 at 10:45 AM, John Mellor joh...@google.com wrote:
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
We might even be able to make this work without inventing anything:
style type=text/css
@media (min-width: 480px) {
.artdirected {
width: 30px;
height: 30px;
background-image: image-set(url(small.png) 1x, url(small-hires.png)
2x);
}
}
@media (min-width: 600px) {
.artdirected {
width: 60px;
height: 60px;
background-image: image-set(url(large.png) 1x, url(large-hires.png)
2x);
}
}
/style
div class=artdirected/div
Three downsides to that:
- Doesn't address viewport-switching (variable-sized images), though we
may
be able to fix that by extending image-set to support src-N's
viewport-urls syntax.
Why doesn't it support variable-sized images? In example above, one
of the cases is 30x30 and the other is 60x60. Maybe I've
misunderstood what you mean by variable-sized images?
- Requires you to know the intrinsic aspect ratio of the images in
advance.
That seems like something we should improve about CSS more generally.
- Slightly less semantic (can't include an alt attribute, etc).
- Most sites will end up just referencing all their images by #id, which
is
fairly icky. Since we're inlining the presentation into the content
anyway,
may as well inline it next to the relevant bit of the content.
These seem like minor concerns compared to the cost of inventing new
HTML elements, attribute, and semantics.
I suggest that not being able to provide an associated text alternative for
an image via a simple method is not a 'minor concern' for some.
On Tue, Nov 12, 2013 at 5:50 PM, Adam Barth w...@adambarth.com wrote:
What's most attractive to me about this approach is that it doesn't
require inventing anything new, which means the compatibility story
for older user agents is solid. You don't need a polyfill or anything
like that.
Except that most user agents don't support image-set yet (only Chrome and
Safari 6+ IIRC).
No user agents support src-N or picture, so we're already ahead of
the game. :)
If we did want to split src-N up to separate presentation from content,
you'd probably want to put the size-viewport-list and media-querys
into
inline CSS, and leave just the size-based-urls (which are pure
content) in
the HTML. Then you'd end up with something like the following.
If you just have viewport-switching (and dpr-switching), it'd be:
style
.photo {
image-width: 100%;
}
/style
img class=photo srcs=160.jpg 160, 320.jpg 320, 640.jpg 640, 1280.jpg
1280, 2560.jpg 2560
(and as in src-N, you could use more complicated size-viewport-list
expressions like 100% (30em) 50% (50em) 33% if the image width is a
non-linear function of viewport width)
If you just have dpr-switching (fixed-width images), it'd be:
style
.photo {
image-width: 128px;
}
/style
img class=photo srcs=64.jpg 64, 128.jpg 128, 256.jpg 256
(where the ratio between the widths of the available images, and the
image-width from CSS, is used to calculate the density of each available
image)
If you have art direction and dpr-switching, it'd be:
style
.photo {
image-width: small 128px;
}
@media (min-width: 20em) {
.photo {
image-width: big 400px;
}
}
/style
img class=photo
srcs-small=s64.jpg 64, s128.jpg 128, s256.jpg 256
srcs-big=b200.jpg 200, b400.jpg 400, b800.jpg 800
(here the author has assigned names to each of their art direction cases
[optional if you only have one case], and provides an alternate list of
image srcs for each case)
This actually looks pretty reasonable (and unlike earlier proposals in
this
thread, covers all use cases). One nice benefit over src-N is that the
size-viewport-list -- i.e. 128px or 100% or 100% (30em) 50% (50em)
33% -- doesn't get repeated for every image, if there are several images
with the same relationship between viewport size and image size.
These proposals all invent new syntax and semantics. I'd much rather
start with an approach that doesn't introduce new syntax or semantics
and just makes the web faster by optimizing existing content.
My main concern is that authors won't realise that the CSS must be
inlined;
I'm not sure how to make that
Re: [whatwg] Various threads with feedback on HTML elements
On Tue, 5 Nov 2013, Tim Leverett wrote: 2. Making main being usable multiple times in a document, so we also have a reasonable element to wrap the main content of a blog post. The spec does not limit main to being used only once. Correct me if I'm wrong, but the spec says: Authors must not include more than one main element in a document. http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-main-element I think that's what Ian Yang was originally referring to. Ah, ok. That's the W3C's spec. You'd have to contact them about that. Right, you can file a bug on the HTML spec https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=product=HTML%20WGcomponent=HTML5%20specor send an email to http://lists.w3.org/Archives/Public/public-html-comments/ The WHATWG spec doesn't limit main to being used just once: http://whatwg.org/html#the-main-element In general I would recommend against using the W3C's spec as a reference, as it has differences exactly like this. If you are mailing/commenting on this list then I agree with hixie. If you want to comment on the W3C HTML spec then... In general I would recommend against using the WHATWG's spec as a reference, as it has differences exactly like this. -- Ian Hickson U+1047E)\._.,--,'``. fLhttp://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] Various threads with feedback on HTML elements
Hi Tim, Authors must not include more than one main element in a document. http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-main-element You are pointing to the W3C HTML spec, the WHATWG spec (the one that this mailing list deals with) has a different definition for the main element. -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ Message: 2 Date: Tue, 5 Nov 2013 14:05:42 -0500 From: Tim Leverett ...@gmail.com To: Ian Hickson i...@hixie.ch Cc: whatwg wha...@whatwg.org Subject: Re: [whatwg] Various threads with feedback on HTML elements Message-ID: CAOiS3y6= iocukjf787sq4oyfdxjfjfryxbjzxbwhrkrk-6s...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 2. Making main being usable multiple times in a document, so we also have a reasonable element to wrap the main content of a blog post. The spec does not limit main to being used only once. Correct me if I'm wrong, but the spec says: Authors must not include more than one main element in a document. http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-main-element I think that's what Ian Yang was originally referring to. Tim Leverett ? -- ___ whatwg mailing list whatwg@lists.whatwg.org http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org End of whatwg Digest, Vol 116, Issue 7 **
Re: [whatwg] Should a figure element require a reference? (was: use cases for figure without figcaption?)
a visible caption, and could not find a better element for the job than figure and figcaption. It is not obvious whether the article was edited incorrectly, whether there was a printing error, or whether the unreferenced figure was intended to stand alone. I propose that unreferenced figures set unreasonable expectation, as just described, and that either from looking at real world data (see above) i couldn't actually find any uses of figure/figcaption as you describe. 1) more generic grouping content should be used to group unreferenced data with captions, or 2) a new element be created similar to label with an attribute similar to the for attribute that is not required to be located within a user interface such as form, or 3) a new set of elements similar to figure and figcaption be created to group unreferenced data. I don't think there is any need to add new features, but do think that figure/figcaption definitions and explanations of use need to be modified to take into account cow paths already trodden. --Xaxio References: [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-figure-element On Fri, Jun 21, 2013 at 3:00 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Xaxio, (and martin) i get why figure on its own is OK. I think that it's OK to use the figure/figcaption pattern on any image (for example) that the author wants to provide a caption for. The use case being: I want to provide some text as a caption for some other content. It is unclear to me (at least) whether the whatwg spec says that is OK or not. the latest (single page) whatwg spec says: The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document. There is no normative text that says it MUST be referenced, only a non normative phrase typically referenced so that suggests to me that it is OK to use figure/figcaption for the use case i described and the one you described, but then the there is a lot of other descriptive text about figure that serves to befuddle my understanding. note: the whatwg spec and the w3c html spec which you referenced currently differ on figure, the proposed changes in the whatwg spec are under discussion in the html wg. -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 21 June 2013 08:38, Xaxio Brandish xaxiobrand...@gmail.com wrote: Steve, One *could* use div elements in place of the figure elements; but then again, one could use div elements in place of many elements in order to remove their semantical meaning and send us back into the dark ages ;) I believe that figure is possibly the best element for the job, in agreement what Martin said regarding the spec specifying a figure being something that is *typically* referenced in the document [1]. I also believe that figcaption is necessary for exact specification (such as in medical documents or legal documents), but may be completely unnecessary for certain other documents (such as the font document example we are discussing). The reason I brought up placement and relevance of the figures in the first place is because of this sentence in the specification: This includes, but is not restricted to, content referred to from the main part of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix. However, all of this does leave me wondering about an instance of fluff in an HTML document and how to appropriately define it. Consider a web page that is devoid of color or motion, and is thus less interesting to people who *must* read it. An example of this can be an online driving education course. Now imagine that the author of the page wanted to seem less boring, and so adds a piece of barely related clip art to the page, and said clip art is not referenced anywhere in the main document material. The author wants to add a humorous comment to the image to lighten the mood of the page, and considers using figure and figcaption. Would it be appropriate to caption the aforementioned clip art using figcaption if it is contained in an aside element, claiming that the figure is self-referential yet only tangentially related to the document? If not, is there an element better suited to this purpose, or we can we redefine the figcaption element to encompass a purpose such as this? --Xaxio References: [1] http://www.w3.org/TR/html51/single-page.html#the-figure-element On Thu, Jun 20, 2013 at 3:34 PM, Martin Janecke whatwg@prlbr.comwrote: Hi Steve, The fact that they are enclosed in the figure elements means that they are referenced somewhere, I believe. so if not referenced somewhere, they should
Re: [whatwg] use cases for figure without figcaption?
Hi Xaxio, (and martin) i get why figure on its own is OK. I think that it's OK to use the figure/figcaption pattern on any image (for example) that the author wants to provide a caption for. The use case being: I want to provide some text as a caption for some other content. It is unclear to me (at least) whether the whatwg spec says that is OK or not. the latest (single page) whatwg spec says: The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document. There is no normative text that says it MUST be referenced, only a non normative phrase typically referenced so that suggests to me that it is OK to use figure/figcaption for the use case i described and the one you described, but then the there is a lot of other descriptive text about figure that serves to befuddle my understanding. note: the whatwg spec and the w3c html spec which you referenced currently differ on figure, the proposed changes in the whatwg spec are under discussion in the html wg. -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 21 June 2013 08:38, Xaxio Brandish xaxiobrand...@gmail.com wrote: Steve, One *could* use div elements in place of the figure elements; but then again, one could use div elements in place of many elements in order to remove their semantical meaning and send us back into the dark ages ;) I believe that figure is possibly the best element for the job, in agreement what Martin said regarding the spec specifying a figure being something that is *typically* referenced in the document [1]. I also believe that figcaption is necessary for exact specification (such as in medical documents or legal documents), but may be completely unnecessary for certain other documents (such as the font document example we are discussing). The reason I brought up placement and relevance of the figures in the first place is because of this sentence in the specification: This includes, but is not restricted to, content referred to from the main part of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix. However, all of this does leave me wondering about an instance of fluff in an HTML document and how to appropriately define it. Consider a web page that is devoid of color or motion, and is thus less interesting to people who *must* read it. An example of this can be an online driving education course. Now imagine that the author of the page wanted to seem less boring, and so adds a piece of barely related clip art to the page, and said clip art is not referenced anywhere in the main document material. The author wants to add a humorous comment to the image to lighten the mood of the page, and considers using figure and figcaption. Would it be appropriate to caption the aforementioned clip art using figcaption if it is contained in an aside element, claiming that the figure is self-referential yet only tangentially related to the document? If not, is there an element better suited to this purpose, or we can we redefine the figcaption element to encompass a purpose such as this? --Xaxio References: [1] http://www.w3.org/TR/html51/single-page.html#the-figure-element On Thu, Jun 20, 2013 at 3:34 PM, Martin Janecke whatwg@prlbr.comwrote: Hi Steve, The fact that they are enclosed in the figure elements means that they are referenced somewhere, I believe. so if not referenced somewhere, they should not be in a figure? Probably they should not, as figures are typically referenced as a single unit from the main flow of the document^[1]. I'd like to add that the reference can be implicit, though. A short car magazine article about a particular model might be a good example. Readers who are likely to have seen some cars in their lives will identify a car's front section on a photograph by themselves and make the connection to what the articles writes about it. Here is such an article: http://www.caranddriver.com/news/2014-bmw-4-series-photos-and-info-news Although the webpage does not actually use figure elements, it would be appropriate for the photographs that are embedded in the main article. The photographs illustrate and enhance the article's content by providing more design details than the text, are self-contained, not part of the main flow and implicitly referenced from it. (The photos should have alt-texts though.) Regards Martin [1]: WHATWG HTML spec 4.5.11 The figure element Am 20.06.2013 um 23:27 schrieb Steve Faulkner: Hi Xaxio, pFonts come in many different varieties. The Arial font, for example, does not have serifs./p divarial/div pHowever, font varieties go beyond simple serif and sans-serif distinctions. The Old
[whatwg] use cases for figure without figcaption?
What are the use cases for a figure without a figcaption ? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] use cases for figure without figcaption?
An illustration of a font name, in its respective font? why is figure better in this case than p (for example) ? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 20 June 2013 19:27, Xaxio Brandish xaxiobrand...@gmail.com wrote: An illustration of a font name, in its respective font? --Xaxio On Jun 20, 2013 11:24 AM, Steve Faulkner faulkner.st...@gmail.com wrote: What are the use cases for a figure without a figcaption ? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] use cases for figure without figcaption?
OK so how do you reference figure arial /figure for example? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 20 June 2013 20:16, Xaxio Brandish xaxiobrand...@gmail.com wrote: The figures could be in a document talking about fonts, yet easily moved to the side of the page and still maintain relevance if referenced within the document. I think something important about figures is placement irrelevance as long as they can be referenced, whereas paragraphs don't have the added semantic of this will be referenced at some point. --Xaxio On Jun 20, 2013 12:10 PM, Steve Faulkner faulkner.st...@gmail.com wrote: An illustration of a font name, in its respective font? why is figure better in this case than p (for example) ? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 20 June 2013 19:27, Xaxio Brandish xaxiobrand...@gmail.com wrote: An illustration of a font name, in its respective font? --Xaxio On Jun 20, 2013 11:24 AM, Steve Faulkner faulkner.st...@gmail.com wrote: What are the use cases for a figure without a figcaption ? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] use cases for figure without figcaption?
Hi Xaxio, pFonts come in many different varieties. The Arial font, for example, does not have serifs./p divarial/div pHowever, font varieties go beyond simple serif and sans-serif distinctions. The Old English font is neither of these, instead being considered a decorative font./pdivOld English/div The above example has meaning with or without the divs, and the placement of the divs doesn't matter. They could be in a font index at the end of the document, as long as the data consumer knows to look there if example are needed. right? The fact that they are enclosed in the figure elements means that they are referenced somewhere, I believe. so if not referenced somewhere, they should not be in a figure? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 20 June 2013 20:46, Xaxio Brandish xaxiobrand...@gmail.com wrote: pFonts come in many different varieties. The Arial font, for example, does not have serifs./p figurearial/figure pHowever, font varieties go beyond simple serif and sans-serif distinctions. The Old English font is neither of these, instead being considered a decorative font./pfigureOld English/figure The above example has meaning with or without the figures, and the placement of the figures doesn't matter. They could be in a font index at the end of the document, as long as the data consumer knows to look there if example are needed. The fact that they are enclosed in the figure elements means that they are referenced somewhere, I believe. When referring to multiple figures containing graphs or tables with really long names such as Number of Children With Orange Dreadlocks With Respect to Decade and Periods of Time During Which Dreadlocks Are Popular, Where Orange Is Popular, and Where They Overlap, it's so much easier just to give them a figcaption and refer to Table 1 and Table 2 in the document. --Xaxio On Jun 20, 2013 12:20 PM, Steve Faulkner faulkner.st...@gmail.com wrote: OK so how do you reference figure arial /figure for example? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 20 June 2013 20:16, Xaxio Brandish xaxiobrand...@gmail.com wrote: The figures could be in a document talking about fonts, yet easily moved to the side of the page and still maintain relevance if referenced within the document. I think something important about figures is placement irrelevance as long as they can be referenced, whereas paragraphs don't have the added semantic of this will be referenced at some point. --Xaxio On Jun 20, 2013 12:10 PM, Steve Faulkner faulkner.st...@gmail.com wrote: An illustration of a font name, in its respective font? why is figure better in this case than p (for example) ? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 20 June 2013 19:27, Xaxio Brandish xaxiobrand...@gmail.com wrote: An illustration of a font name, in its respective font? --Xaxio On Jun 20, 2013 11:24 AM, Steve Faulkner faulkner.st...@gmail.com wrote: What are the use cases for a figure without a figcaption ? -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] @aria-labelledby | Re: @generator-unable-to-provide-required-alt, figure with figcaption
Hi again, forgot to mention that the requirements for conformance checkers implementation requirements do differ due to differing the author requirement. so in W3C HTML validator: this results in an error img title=poot In validator.nu it doesn't -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 18 June 2013 12:02, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Jonas I.e. is the difference between the W3C and WHATWG versions here just a difference in authoring requirements? Or also a difference in implementations requirements? authoring requirements only -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 18 June 2013 11:57, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 17, 2013 at 11:35 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Am 07.06.2013 um 23:13 schrieb Ian Hickson: img src=... title=image If you have a caption from the user (as opposed to replacement text), then this is a perfectly valid option. It's as valid as the figure case, and means the same thing. [...] the above statement is bad advice: browsers map title to the accessible name in accessibility APIs when alt is absent, so in the following cases: img src=... title=poot img src=... alt=poot the accessible name is 'poot'. it is only when there is an accessible name already provided that title is used as an accessible description: img src=... alt=poot title=description of poot Also note that as per the W3C HTML spec, use of the title without an alt is non conforming[1] as it does not represent a caption for an image and as you point out is hidden from a variety of users due to a long and consistent history of poor implementation. Steve, Does the spec still require that if an implementation encounters an image with a title but without an alt to present that to users with and without AT in a useful way? I.e. is the difference between the W3C and WHATWG versions here just a difference in authoring requirements? Or also a difference in implementations requirements? / Jonas
Re: [whatwg] HTML differences from HTML4 document updated
Xaxio wrote: If you believe that documenting the (constantly evolving) differences between HTML and its HTML5 and HTML5.1 subsets would be relevant, please do so! It would be a great thing to be able to reference such a document. I have made a start on a document http://www.w3.org/wiki/HTML/W3C-WHATWG-Differences -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
[whatwg] Main element - Rationale? use cases? and data?
Is there any rationale, uses cases or data available that supports the current definition of the main element in the WHATWG spec? In particular the author conformance requirements and advice. I looked around but couldn't find any. Regards SteveF
Re: [whatwg] Is main now an official HTML5 element?
Chaals wrote: The HTML WG is one of the working groups of W3C. The working group has a charter that describes some of how it works: http://www.w3.org/2007/03/HTML-WG-charter for those interested there is the up to date proposed charter which is being reviewed currently: http://www.w3.org/html/wg/charter/2012/ regards SteveF
[whatwg] Is main now an official HTML5 element?
Hi Ian, I cannot speak for whatwg, but from the W3C HTML spec side the main element is in the HTML 5.1 spec and has been implemented in browsers and so will be added to HTML5 spec at some point as it likely meets the CR exit criteria. as for it being a sectioning element, there is currently an open bug on that, which we be dealt with. If you want to discuss the specification of the main element in HTML 5.1 specification feel free mail the html wg list. If you want to discuss definition as per the whatwg spec this is the place, although I will obviously follow ant discussions with interest regards SteveF Date: Wed, 13 Feb 2013 18:31:32 +0800 From: Ian Yang i...@invigoreight.com To: whatwg wha...@whatwg.org Subject: [whatwg] Is main now an official HTML5 element? Message-ID: CABr1FsfcaX8=B8TReG8Sz36W= h1w0hRY61+LG=cebo-zuwy...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi editors and all other folks, I saw the SitePoint article Introducing the New HTML5 main Elementhttp://www.sitepoint.com/html5-main-element/ yesterday. Does that mean main element has been approved by all editors of the working group? However, in spec, it still says that main element is not a sectioning element. That means, in document outline, main content will form another tree structure instead of appearing under the original website tree structure. Can we have somebody advise on this? Is there a special consideration to not making main a sectioning element? Sincerely, Ian Yan
Re: [whatwg] Is main now an official HTML5 element?
Silvia wrote: Even if the specs differ, in the end what matters is what browsers implement. Partially agree, it matters what conformance checkers implement and in the case of main. the major HTML conformance checker will implement the conformance rules in the W3C HTML spec. This will leave the WHATWG spec not matching reality. It should also be noted that as implemented in browsers main is implemented as per the W3C spec i.e. main is mapped to role=main and because of this main is interpreted by AT as a main landmark already. This leaves the WHATWG spec not matching reality. Beyond the priorities and domain of the browser vendors is the conformance requirements and advice the HTML spec provides to authors which can directly impact the experience for users. So I suggest non browser differences matter very much. regards SteveF
Re: [whatwg] use of article to markup comments
Brucel wrote: On Sat, 26 Jan 2013 10:56:10 -, Steve Faulkner faulkner.st...@gmail.com wrote: Lists are appropriate for indicating nested tree structures. The use of lists to markup comments is a common mark up pattern used in blogging software such as wordpress. The code verbosity is not dissimilar to the use of article, less so even option end /li tags are omitted. Besides comments are generated code not hand authored so I don't see a problem with code verbosity [...] (It makes some sense, I suppose, to think of comments as a list, but *unordered*? If you're going to group them at all, wouldn't the order be important? Bruce Lawson ( http://lists.w3.org/Archives/Public/public-html/2013Jan/0111.html)'s observation that comments are heavily dependent on context would seem to support the idea that it *is* important, especially since some comments are responses to others.) agreed it would be better to use order lists. Wordpress blogs, for example, have comments like Bob Smith said at a href=#permalink9.55 on 31 Febtember/a: LOL Thus, every comment has a link that a UA can use to jump from comment to comment. The order is implied via the timestamp. So what's wrong with article h1Witty blogpost/h1 plorem ipsum section h235 erudite and well-reasoned comments/h2 divBob Smith said at a href=#permalink19.55 on 31 Febtember/a: Can I use DRM in Polyglot documents?/div divHixie said at a href=#permalink29.57 on 1 June/a: What's your use case?/div ... /section /article In short, why should the spec suggest any specific method of marking up comments? Good question, in the case of article recommended tomarkup comments it seems like it's an element in search of a use case. For users who consume article semantics it appear to cause issues when used for any piece of content ranging from a one sentence comment to an article containing thousands of words or an interactive widget. regards SteveF
[whatwg] use of article to markup comments
Over on the HTML WG list [1] we have been discussing the use of the article element to mark up comments. I have sketched out a few alternative possibilities to the current recommendation in the spec of using the article element as it has been indicated by users who consume the semantics that its use is suboptimal. I am bringing this over here as well as one of the suggestions I have [2] made may include implementation changes [1] http://lists.w3.org/Archives/Public/public-html/2013Jan/thread.html#msg109 [2] http://www.html5accessibility.com/tests/comments.html -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Feedback on a variety of elements
Ian Hickson i...@hixie.ch wrote: My point stands. aria-has-popup is pointless because it doesn't define an interaction model. There's no useful way for an AT to expose it. oh I missed your point, suggest you bring it up with the browser implementers who have implemented aria-haspopup to map to corresponding properties in MSAA, IA2, ATK/AT-SPI, UIA and Mac AX accessibility API's and the AT's such as JAWS, VoiceOver, NVDA etc, that expose aria-haspopup, as provided by the browser, to users. [1] http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property On 25 January 2013 18:07, Ian Hickson i...@hixie.ch wrote: On Sat, 19 Jan 2013, Steve Faulkner wrote: On 19 January 2013 01:41, Ian Hickson i...@hixie.ch wrote: I don't see any useful explanation of how to use aria-haspopup here. suggest you look at definition of aria-haspopup in the ARIA spec That's what I looked at before this conversation began. My point stands. aria-has-popup is pointless because it doesn't define an interaction model. There's no useful way for an AT to expose it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Feedback on a variety of elements
On 17 January 2013 18:59, Ian Hickson i...@hixie.ch wrote: How does the user agent know how the user is to interact with it? menus like most controls have a defined standard interaction pattern -- with regards Steve Faulkner
Re: [whatwg] Feedback on a variety of elements
On 18 January 2013 23:55, Ian Hickson i...@hixie.ch wrote: Doesn't it differ from platform to platform? How is the author supposed to know what it is on the user's platform? There are some platform differences for some controls. Design patterns for a range of widgets are provided in the ARIA authoring guide [1] [1] http://www.w3.org/WAI/PF/aria-practices/#aria_ex -- with regards SteveF
Re: [whatwg] Feedback on a variety of elements
On 19 January 2013 01:41, Ian Hickson i...@hixie.ch wrote: I don't see any useful explanation of how to use aria-haspopup here. suggest you look at definition of aria-haspopup in the ARIA spec HTH SteveF
Re: [whatwg] Feedback on a variety of elements
hixie wrote: On Sun, 10 Jun 2012, Steve Faulkner wrote: You don't clearly differentiate between roles, properties and states, ther are quite a few states and properties NOT provided in HTML5 that may have use cases for adding to an input element, for example aria-hapopup, aria-labelledby, aria-decirbedby, aria-controls etc Could you give an example of any of these in valid use? the following input (gmail search box) uses aria-haspopup=true input type=text value= autocomplete=off name=q class=gbqfif id=gbqfq *aria-haspopup=true* style=border: medium none; padding: 0px; margin: 0px; height: auto; width: 100%; background: url(quot;data:image/gif;base64,R0lGODlhAQABAID/AMDAwCH5BAEALAABAAEAAAICRAEAOw%3D%3Dquot;) repeat scroll 0% 0% transparent; position: absolute; z-index: 6; left: 0px; dir=ltr spellcheck=false Interesting. Can you elaborate on how this actually works? That is, aria-haspopup tells the AT that activating the element shows a popup, but what does activating the element mean? How does the AT expose this to the user? How does the user know what to do with this? aria-haspop maps to haspopup state in acc APIs Typically the user gets notified that there is a sub menu and may (depending on verbosity preferences) get told how to interact with it. -- with regards SteveF
Re: [whatwg] use cases for untitled article and section elements
bruce wrote: I don't understand the question sorry this example: https://dl.dropbox.com/u/377471/article.html results in this outline: what is the use of the untitle articles? Example of article use from HTML 5.1 spec Bacon on a crowbar Untitled ARTICLE Untitled ARTICLE Untitled ARTICLE Untitled ARTICLE Untitled ARTICLE Untitled ARTICLE what is the use of the untitled articles? or of the 133 untitled articles on http://html5doctor.com/designing-a-blog-with-html5/ what is the use case for using article in this case over the use of other markup such as lists? what does it provide? regards Steve On 15 January 2013 12:59, Steve Faulkner faulkner.st...@gmail.com wrote: bruce wrote: Can anyone point me to or provide use cases for untitled article and section elements? those in which the heading is to be injected via script Ok so in a a rendered page or outline? -- Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
Re: [whatwg] use cases for untitled article and section elements
thanks, makes more sense (i think) On 15 January 2013 14:08, Bruce Lawson bru...@opera.com wrote: On Tue, 15 Jan 2013 13:44:44 -, Steve Faulkner faulkner.st...@gmail.com wrote: what is the use of the untitled articles? or of the 133 untitled articles on http://html5doctor.com/designing-a-blog-with-html5/ what is the use case for using article in this case over the use of other markup such as lists? I can't answer for other doctors, but I see no advantage there (although I see no advantage to using lists, either). On my own blog, which also uses article for comments, I'm considering changing it from article comment by Fred on 12 Dec at 4.52 divcomment text/div /article into article h3Fred said on 12 Dec at 4.52/h3 divcomment text/div /article so there are are headings by which comments may be navigated, -- Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] use cases for untitled article and section elements
Hi Mathias, Comments on blog posts, or forum posts. how is it useful? what does the use of article provide in this case over other markup? why not section or list? who are the consumers of the semantics? regards SteveF On 15 January 2013 14:44, Mathias Bynens math...@qiwi.be wrote: On 15 Jan 2013, at 10:57, Steve Faulkner faulkner.st...@gmail.com wrote: Can anyone point me to or provide use cases for untitled article and section elements? Comments on blog posts, or forum posts. as in who are the potential consumers of document outlines with untitled sections? This is a different question, as there are more sectioning elements than just article and section. nav, for example. (See http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html.) E.g. if there’s only a single nav element in the document, it means that element represents the primary navigation. As such there’s no need to title that section IMHO.
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
Hi Ian, in regards to your post about how main is defined: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0239.html the main element [2] is being standardised at the w3c not the whatwg and as such, the whatwg list moderator has requested that discussion not continue on this list unless new information is provided that will result in a change of his opinion. comments on the spec should be directed as per below: The main element spec is published by the HTML Working Grouphttp://www.w3.org/html/wg/as a Working Draft. If you are not a HTML working group member and wish to make comments regarding this document please send them to public-html-comme...@w3.org (subscribepublic-html-comments-requ...@w3.org?subject=subscribe, archives http://lists.w3.org/Archives/Public/public-html-comments/). If you are a HTML working group member and wish to make comments regarding this document, please send them to public-h...@w3.org (subscribepublic-html-requ...@w3.org?subject=subscribe, archives http://lists.w3.org/Archives/Public/public-html/). All feedback is welcome. Anyone can also file a bug against the spec, as you have in this regard [1], so please add new info there. I will respond to any bugs or comments in due course. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591 [2] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html -- with regards Steve Faulkner
Re: [whatwg] A plea to Hixie to adopt main
Hi Cory, I don't know if this is relevant at all, but according to the spec (section 4.4.1), The body element represents the main content of the document. What would you say is the relation between this use of the term main and your use of the term here? Might it perhaps be more accurate to state, The body element represents the *entire* content of the document (or something like that). I don't really know -- just asking. I filed a bug about this recently: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19967 -- with regards Steve Faulkner
[whatwg] Use of article to identify the main content of a web page (was Re: A plea to Hixie to adopt main)
Hi Ian, hixies suggestion to use article to act as a main content identifier [3] is incorrect, as per the HTML spec [1] The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. The main element as per the main element spec [2]: The main element represents the main content section of the body of a document or application. The main content section consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application. The article and main roles as defined in ARIA have distinct characteristics and those distinctions are also expressed via how they (and the article element) are exposed via accessibility APIs in browsers. [1] http://dev.w3.org/html5/spec/the-article-element.html#the-article-element [2] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html [3] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0221.html -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] A plea to Hixie to adopt main
Hi Ian, Responses in line. FYI For any implementers or other interested parties the main element specification [2] is currently in a call for consensus to publish as a first public working draft (over at the W3C) [3] On Thu, 8 Nov 2012, Steve Faulkner wrote: http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction This page has the following: | Enable users to be able to navigate to and recognise the boundaries of | the main content area This is done by main (because of the likely authoring failures) no more reliably, and possibly in fact less reliably, than is already possible with things like aside. Requiring a the presence of number of elements and having those elements used correctly, (some of which from anecdotal reports author,s find difficult to use correctly), to provide an indication of something else, appears wholey more prone to failure than using one element that as specced [2] is clear in its use and based on current authoring practices. http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0067.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html | Enable authors to style the main content area of a page specifically. This is already possible with div. It would make sense to have a more specific element if there was a cowpath, but there isn't: there is a clear cowpath and the data has been provided. Agreed that people get markup wrong, I don't agree with your supposition that main would be just as prone to mistakes as the other elements you cited. With all due respect, you have to ignore the data to come to that conclusion. Look at your own data: authors put this semantic all over the place. There is _no_ evidence that they'd do better with main. I have looked at the data and no they do not put div id=main content all over the place they put it approx 80% of the time in the right place. http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html Did the year's old previous discussion take into account id value data or skip link data or role=main placement data? I do not recall the specifics. ARIA didn't exist back then, so clearly it wasn't examined, though. What the relevant new data clearly indicates is that in approx 80% of cases when authors identify the main area of content it is the part of the content that does not include header, footer or navigation content. Where do you get this number from? I looked at a couple of hundred pages [1] in the sample that I have added styling to show the use of id=main or id=content noting the borders and what content is and is not contained within them. It also indicates that where skip links are present or role=main is used their position correlates highly with the use of id values designating the main content area of a page. How do you determine this correlation? (Are you just using the word colloquially?) What does this correlation mean? Are they all using both incorrectly? (That would get you good correlation too.) What about pages that do not give skip links or role=main? (Pages that use those features are going to be disproportionally biased towards competent authors, which makes it dangerous to draw conclusions from that sample. see above , approx 80% I have provided the data set from which my statements are derived, if you want to disprove them you can analyse the same data set. furthermore when ARIA role=main is used in 95% [3] of the cases in the data sampled it is used once only which is a clear indicator that authors get how to identify the main content area of a page. I think that's a wildly optimistic conclusion. Lots of pages only use body once, that doesn't mean they use it correctly. :-) again I have provided the data set if you disagree you can analyse the data. * use of a descriptive id to value to identify the main content area of a web page is common. (id=main|id=content|id= maincontent|id=content-main |id=main-content used on 39% of the pages in the sample [2]) As I discuss in the e-mail cited several times above, the area they indicate with these IDs is not reliably the main content. For example, it might or might not include the footer, sidebars, navigation links, headings, etc. well no, you are making suppositions again, the data set is available for analysis if you disagree with my conclusions based on my analysis of the data you can run your own analysis. * There is a strong correlation between use of role='main' on an element with id values of 'content' or 'main' or permutations. (when used = 101 pages) 77% were on an element with id values of 'content' or 'main' or permutations. I don't see what this tells us. Obviously if someone is going to mark an element as role=main, they'll use the same element for id=main
Re: [whatwg] A plea to Hixie to adopt main
Hi Tim, Are you saying we should not introduce a main element... I don't believe I ever said anything about not introducing a mainelement. I'm very much on the fence about it. I've been trying to carefully balance the pros and cons to avoid a biased judgement. Here are some of what I've come up with. Pro: Adding a main element will provide a semantic element that developers can use to indicate primary content of a document. Con: Adding a main element adds redundancy to the [role=main] attribute. I don't see why this is a con, if main is mapped to role=main in the browser it means that authors won't have to. Also adding aside/article/footer etc adds redundancy to the matching ARIA roles. Pro: Adding a main element will allow developers to use a format such as: body header / main / footer / /body which tends to be quite clean and understandable (the easier it is to read code, the easier it is to fix code). Con: Implementing the main element in a backwards compatible manner requires JavaScript. it is/was the same for any of the new structural elements. Pro: Assistive technologies can use the main element as a means to rapidly navigate to the primary content. Con: The main element can only be used once per page. Pages with multiple content areas, or fragmented content would need to pick a single content region as primary, or not use the element. This restriction will likely cause more confusion than if multiple main elements were allowed. From the data it does not appear that authors are confused about use of role=main or the use of semantic id values to designate the main content area. Authors do not appear to have an issue with marking up div id=main and using it once per page. I think that the restrictions make it easier to use and understand rather than harder. Pro: The main element can only be used once per page. This forces the author to decide exactly where the main focus of the page lies, rather than relying on assumptions. Con: The main element is supposed to exclude content that is repetitious across pages, but content is often interspersed with blocks of advertisements, modules, CTAs and the like. authors can use more granular elements within the main element, to structure content, example: main article/ aside advertisements/aside article/ /main can you provide some examples of the sort of pages you are talking about? It would be useful. Personally, I'd rather see main be more about marking up content in general, such as in this example which is invalid given the current state of the spec: article id=1 header / main / footer / /article article id=2 header / main / footer / /article ...although this would probably fit better as a content element, and would require a whole other line of discussion that can wait for another day. Indeed, this appears to be something different from what the main element is designed for. Regards SteveF
Re: [whatwg] A plea to Hixie to adopt main
Con: Adding a main element adds redundancy to the [role=main] attribute. I don't see why this is a con, if main is mapped to role=main in the browser it means that authors won't have to. Also adding aside/article/footer etc adds redundancy to the matching ARIA roles. Redundancy tends to be a source of error if they get out of sync. If one browser supports [role=main] and another supports main, both would be needed to provide compatibility. Obviously this is a bit contrived, as browsers supporting main would likely also support [role=main], but older versions would not support main . Going forward, this would mean that authors wanting to use main would have to use main role=main for backwards compatibility. yes this is true, same goes for the other new elements today. I see little issue with the redundancy though as the roles match the elements. I could be wrong on this, but I was pretty certain that article and the rest were supported by browsers before the ARIA roles model. no - the majority of accessibility APIs did/do not have non ARIA based roles specified for header/footer/article/aside etc some APIs are adding roles based on ARIA (Mac AX, Iaccessible2 etc) accessibility implementation in browsers for the semantics of these elements is variable [1] [1] http://www.html5accessibility.com/ regards SteveF
Re: [whatwg] A plea to Hixie to adopt main
Hi *Tim*, I was just trying to make the point that an algorithmic approach to finding the main content of a document would still be necessary with or without the main element. The same can be said for any of the structural semantic elements, what we know is that some authors mark up headings, nav, footer, articles etc incorrectly or not at all. What we also know is that user agents do not generally implement heuristics to provide semantic information to users, they rely upon explicit markup to expose semantic structures to convey meaning and provide navigation of content. For example, ARIA landmark roles are now supported in most browsers and assistive technology and used by browsers for built in mapping of roles for new HTML structural elements that do not have platform accessibility API specific roles (most do not). regards SteveF Hope you're not just trolling I was just trying to make the point that an algorithmic approach to finding the main content of a document would still be necessary with or without the main element. ☺ On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett ...@gmail.com wrote: Explicit author markup would make such a task so much easier. Only if every author marked up their code correctly. If some authors use incorrect markup, then an algorithm would still be necessary for determining if each usage was correct. Hope you're not just trolling. From a browser perspective, if there is one main element and it sits within body, that would be sufficiently correct. Whether it's semantically correct for a particular application, that's not something the HTML spec should or could deal with. We don't protect people from putting the wrong text in tags - not in microdata, not in article or anywhere else. An application may care - or they may trust the author and if the author cares enough, they will fix up their markup if it doesn't achieve the right goal. But I'm sure you were just trolling... ;-) Cheers, Silvia. http://www.paciellogroup.com/resources/wat-ie-about.html
[whatwg] main spec updated with suggested changes to parser behaviour and rendering
Hi all, have updated the main spec with suggested changes to parser behaviour [1] and rendering [2] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html feedback welcome! [1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0045.html [2] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0054.html -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
; whatever we do here sets a precedent for future elements) inconsistent with the rest of HTML. In the long term, having main and aside parse differently just because we didn't want to change the behavior from 2012-era browsers will seem silly. Indeed. Given how relatively painless transitioning from no parser spec at all to having one at all actually ended up being, at least relative to what I was expecting, I think adding new elements isn't a big deal at all. (Even in the head.) We shouldn't add elements in general, but that's more about not expanding the language, not about the parser. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' [1] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html [2] http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/ [3] http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/ [4] http://lists.w3.org/Archives/Public/public-html/2012Nov/0085.html -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
[whatwg] main element parsing behaviour
Hi all, After discussions with various implementers there appears to be some questions about the main element and the parsing algorithm Can anyone with the requisite knowledge provide advice on what needs to be added (if anything) to the main element spec [1] to define parsing for the element? also any other feedback welcome. https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] main element parsing behaviour
Hi Anne, That feedback as stated was mainly for Hixie, who dismissed it. I have sought further opinion, but do not have the expertise to know what I need to do with it. for example, I get the sense that implementers in general do not want to mess with the parsing algorithm, so does that mean. I don't need to put anything in the spec? regards SteveF On 7 November 2012 10:30, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Nov 7, 2012 at 10:55 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Can anyone with the requisite knowledge provide advice on what needs to be added (if anything) to the main element spec to define parsing for the element? What did you do with the feedback you already got on this front? http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0155.html -- http://annevankesteren.nl/ -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] A plea to Hixie to adopt main
Hi Ben, I generally markup pages using ARIA roles: header role=banner article role=main footer role=contentinfo and variations thereafter— If there were to be a main attribute (with an implicit ARIA role to match), where would it end? contentinfo banner ? What is to be gained by adding an element, rather than using ARIA roles? Isn't that what ARIA is designed for? various new HTML elements are already being mapped to ARIA or platform accessibility APIs aside is mapped to complementary ( IA2, AT-SPI and AX) article is mapped to article ( IA2, AT-SPI and AX) nav is mapped to navigation ( IA2, AT-SPI and AX) header/footer are mapped to banner and conteninfo ( IA2, AT-SPI and AX) etc. this means when fuly implemented authors will not have to add aria roles (built in vs bolt-on) the browsers do it already. ARIA roles are used because the semantics are not fully implemented in browsers yet. If you take the time to read the spec [1] and supporting research you will find the rationale and use cases detailed. Its based on commont authoring practice. [1] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html regards SteveF On 08/11/2012, at 1:23 AM, Simon Pieters sim...@opera.com wrote: Hi, My impression from TPAC is that implementors are on board with the idea of adding main to HTML, and we're left with Hixie objecting to it. Hixie's argument is, I think, that the use case that main is intended to address is already possible by applying the Scooby-Doo algorithm, as James put it -- remove all elements that are not main content, header, aside, etc., and you're left with the main content. I think the Scooby-Doo algorithm is a heuristic that is not reliable enough in practice, since authors are likely to put stuff outside the main content that do not get filtered out by the algorithm, and vice versa. Implementations that want to support a go to main content or highlight the main content, like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using main as a way to opt out of the heuristic works better than using aside to opt out of the heuristic. For instance, it seems reasonable to use aside for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that. If there is anyone besides from Hixie who objects to adding main, it would be useful to hear it. -- Simon Pieters Opera Software -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] maincontent element spec updated and supporting data provided (Henri Sivonen)
Hi Henri,
bikeshedA single-word element name would me more consistent with
other HTML element names. content would be rather generic, so I
think main would be the better option./bikeshed
Have changed name [1]:
After consideration of feedback I have changed the name of the element
from maincontent to main. The reasoning for the change:
Feedback indicates preference for a shorter one word element name.
Most commenter's proffered main as a name.
The element name content is already proposed for use in the shadow DOM
specification [2]
As the element maps onto the ARIA role=main it seems an appropriate name to
use.
It would probably make sense to add
main { display: block; }
to the UA stylesheet.
have added.
If Hixie had added this element in the same batch as section,
article and aside, he would have made the parsing algorithm
similarly sensitive to this element. However, I'm inclined to advise
against changes to the parsing algorithm at this stage (you have none;
I am mainly writing this for Hixie), since it would move us further
from a stable state for the parsing algorithm and, if the main
element is used in a conforming way, it won't have a p element
preceding it anyway.
have captured your feedback on parsing in bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591
[1]
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
[2]
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#content-element
--
Message: 4
Date: Thu, 18 Oct 2012 09:12:41 +0300
From: Henri Sivonen hsivo...@iki.fi
To: whatwg wha...@whatwg.org
Subject: Re: [whatwg] maincontent element spec updated and supporting
dataprovided
Message-ID:
cajqvaudr2qvcpd82s4zriz3itsgq_y1q+fi2s5vnmr++txv...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 17, 2012 at 3:03 AM, Steve Faulkner
faulkner.st...@gmail.com wrote:
I have updated the maincontent spec [1] and would appreciate any
feedback
(including, but not limited to implementers).
bikeshedA single-word element name would me more consistent with
other HTML element names. content would be rather generic, so I
think main would be the better option./bikeshed
It would probably make sense to add
main { display: block; }
to the UA stylesheet.
If Hixie had added this element in the same batch as section,
article and aside, he would have made the parsing algorithm
similarly sensitive to this element. However, I'm inclined to advise
against changes to the parsing algorithm at this stage (you have none;
I am mainly writing this for Hixie), since it would move us further
from a stable state for the parsing algorithm and, if the main
element is used in a conforming way, it won't have a p element
preceding it anyway.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
-
Re: [whatwg] maincontent element spec updated and supporting data provided
Hi Mat, have taken your advice and made an initial draft of a use case/rationale document: http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction feedback welcome! regards SteveF On 18 October 2012 22:27, Mathew Marquis m...@matmarquis.com wrote: On Oct 18, 2012, at 2:36 PM, Ian Hickson wrote: I just wanted to make sure everyone is clear that this maincontent part is not part of the HTML specification, and is not a WHATWG specification. We have previously had miscommunications about this kind of thing, e.g. with responsive images, where there was some expectation from some people that if a proposal got written up, it would be adopted. This is not the case; what decides whether a proposal is adopted or not is whether it has real use cases and compelling reasoning. Off-topic, but just for the record: there was no expectation that the RICG’s proposal would simply be accepted wholesale, for obvious reasons—just that we would be able to collaborate with the WHATWG on it. It wouldn’t have made much sense for us to call it a “proposal” otherwise, after all. :) On-topic: the `main` class/ID pattern is an exceedingly common one, for sure. I use it all the time myself, in conjunction with `role=main`. I was originally of the mind that the role of “primary content” was served by the first `article` element within the document, but where the first `article` just represents the first sectioned stand-alone content in the document, it could be something like an infographic — capable of functioning independent of the surrounding document, but not the entirety of the primary content. Given the clear meaning of the proposed element, the low barrier to adoption by web developers, and the potential benefits this could have in terms of syndication and accessibility: it certainly sounds interesting! The RICG published a stand-alone “use cases” document a while back ( http://usecases.responsiveimages.org ), to facilitate work on the extension specification. Is anything like this in the works for `main`/`content`/`maincontent`, at present? Seems like it would be a good next step! -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] maincontent element spec updated and supporting data provided
Hi Ian, Thanks for the detailed example, your reasoning is clear now and that give sme something to work with, and thanks for filing a bug! will respond on bug. regards SteveF On 18 October 2012 07:28, Ian Yang i...@invigoreight.com wrote: On Thu, Oct 18, 2012 at 1:31 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, Like the succinct and simple name of complementary content (aside), could we make the element name of the main content as succinct as aside? For instance, main? I have responded on the HTML WG list to a similar naming preference comment: http://lists.w3.org/Archives/Public/public-html/2012Oct/0112.html Thank you. Since the complementary content (aside) is a sectioning element, could we make the main content element a sectioning element, too? Can you provide some more reasoning for making the element sectioning content? There is a now W3C bugzilla component for the HTML5 maincontent extension, you can file bugs against the spec there to ensure that your comments get recorded and responded to: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WGcomponent=maincontent%20element regards SteveF Because both being elements for content, it is inconsistent that complementary content is sectioning element and main content is not. Another reason is about document outline. Please take a look at the markup below: !DOCTYPE html titleblablabla/title header h1Branding/h1 nav h1Navigation/h1 blablabla /nav aside h1Search/h1 blablabla /aside /header main role=main h1Main Content/h1 section h1Welcome/h1 blablabla /section section h1Brief Intro/h1 blablabla /section /main aside role=complementary h1Complementary Content/h1 article h1Latest News/h1 blablabla /article article h1Recent Comments/h1 blablabla /article /aside footer blablabla /footer If the main content element is a sectioning element, the document outline formed by the above code will be clear and hierarchically correct: 1. Branding 1. Navigation 2. Search 3. Main Content 1. Welcome 2. Brief Intro 4. Complementary Content 1. Latest News 2. Recent Comments But if the the main content element is not a sectioning element, the document outline will be confusing and hierarchically incorrect: 1. Branding 1. Navigation 2. Search 2. Main Content 1. Welcome 2. Brief Intro 3. Complementary Content 1. Latest News 2. Recent Comments Both main content and complementary content are content, so they are supposed to be at the same level in document outline. A bug report for this issue has been filed on bugzilla. Kind Regards, Ian Yang http://www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] maincontent element spec updated and supporting data provided
minutiae of proposals before firmly establishing that there are solid use cases. On Wed, 17 Oct 2012, Steve Faulkner wrote: What is apparent from the home page data in the sample: * use of a descriptive id to value to identify the main content area of a web page is common. (id=main|id=content|id= maincontent|id=content-main|id=main-content used on 39% of the pages in the sample) This is not new information: https://developers.google.com/webmasters/state-of-the-web/2005/classes The thing is, we already have elements for these cases. Take the pages in this list: http://www.html5accessibility.com/tests/HTML5-main-content/ Site 1 uses id=main-nav where it could use nav, id=main where it could use article, and has multiple divs for styling that would not be removed if we added one more element regardless of its semantics, and uses id=content but doesn't need to to achieve its style. Site 2 uses id=main where article would be suitable, class=main and class=content for cases where a broad main content semantic would not be, and has multiple divs with IDs such that adding a semantic for its element with id=content wouldn't solve the problem of needing divs for its style. Site 3 uses id=content where aside or article would be appropriate, uses an a, of all things, to wrap ads that could arguably be articles in their own right, and uses div id=main as part of a cascade of divs for stylistic reasons (I don't understand its use of 'overflow' to achieve its effect, but I find it hard to believe that it's necessary...). Site 4 has elements with id=content, left_main, right_main, comment_main, etc, and styles its id=content element in a way that could just as easily be achieved without the element being present at all. Plus, this page has deep div stacks that again wouldn't be resolved just by taking away one of the main layers into its own element. Site 5 has multiple elements that could be considered to wrap the main content, with such divs nested at least five deep at one point (content, rightside (where the right side is the main part of the page), module, module_body, chuxing_div...). I could go on, but the point is that this is exactly the results we got in 2005/2006 when we last studied this. There are sections of the page that can legitimately be marked up, for which we've now got header, footer, article, nav. Those tend to be unambiguously recognisable. There are other more generic sections that are still semantically clear sections, for which we've now got section, hr. And then there's the divisions that really are there for stylistic reasons, not semantic reasons. They're not necessary for accessibility (which can determine the position of the main content from the other elements), there tends to be a lot of them at once, different pages tend to have different precise needs for them, and for these, we have div. On Thu, 18 Oct 2012, Henri Sivonen wrote: If Hixie had added this element in the same batch as section, article and aside, he would have made the parsing algorithm similarly sensitive to this element. However, I'm inclined to advise against changes to the parsing algorithm at this stage (you have none; I am mainly writing this for Hixie), since it would move us further from a stable state for the parsing algorithm and, if the main element is used in a conforming way, it won't have a p element preceding it anyway. If main had a use case, I would definitely think we should change the parsing algorithm -- not changing it makes the element essentially unusable, IMHO. But that's academic, since the element has no useful purpose, isn't necessary, and is thus not part of HTML. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' http://www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] maincontent element spec updated and supporting data provided
hi Mat, The RICG published a stand-alone “use cases” document a while back ( http://usecases.responsiveimages.org ), to facilitate work on the extension specification. Is anything like this in the works for `main`/`content`/`maincontent`, at present? Seems like it would be a good next step! right, will work on it. Hixie, can you point me to the uses cases developed for adding header/footer/section/article/aside etc? As it would be good to have some related source material to work from. I had a look on the WHATWG wiki and serached the WHATWG mail archive and couldn't find anything. regards SteveF On 18 October 2012 22:27, Mathew Marquis m...@matmarquis.com wrote: On Oct 18, 2012, at 2:36 PM, Ian Hickson wrote: I just wanted to make sure everyone is clear that this maincontent part is not part of the HTML specification, and is not a WHATWG specification. We have previously had miscommunications about this kind of thing, e.g. with responsive images, where there was some expectation from some people that if a proposal got written up, it would be adopted. This is not the case; what decides whether a proposal is adopted or not is whether it has real use cases and compelling reasoning. Off-topic, but just for the record: there was no expectation that the RICG’s proposal would simply be accepted wholesale, for obvious reasons—just that we would be able to collaborate with the WHATWG on it. It wouldn’t have made much sense for us to call it a “proposal” otherwise, after all. :) On-topic: the `main` class/ID pattern is an exceedingly common one, for sure. I use it all the time myself, in conjunction with `role=main`. I was originally of the mind that the role of “primary content” was served by the first `article` element within the document, but where the first `article` just represents the first sectioned stand-alone content in the document, it could be something like an infographic — capable of functioning independent of the surrounding document, but not the entirety of the primary content. Given the clear meaning of the proposed element, the low barrier to adoption by web developers, and the potential benefits this could have in terms of syndication and accessibility: it certainly sounds interesting! The RICG published a stand-alone “use cases” document a while back ( http://usecases.responsiveimages.org ), to facilitate work on the extension specification. Is anything like this in the works for `main`/`content`/`maincontent`, at present? Seems like it would be a good next step!
Re: [whatwg] maincontent element spec updated and supporting data provided
Hi Ian, Like the succinct and simple name of complementary content (aside), could we make the element name of the main content as succinct as aside? For instance, main? I have responded on the HTML WG list to a similar naming preference comment: http://lists.w3.org/Archives/Public/public-html/2012Oct/0112.html Since the complementary content (aside) is a sectioning element, could we make the main content element a sectioning element, too? Can you provide some more reasoning for making the element sectioning content? There is a now W3C bugzilla component for the HTML5 maincontent extension, you can file bugs against the spec there to ensure that your comments get recorded and responded to: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WGcomponent=maincontent%20element regards SteveF On 17 October 2012 04:17, Ian Yang i...@invigoreight.com wrote: Hi Steve, Thanks for the great research effort on the main content element. Like the succinct and simple name of complementary content (aside), could we make the element name of the main content as succinct as aside? For instance, main? Since the complementary content (aside) is a sectioning element, could we make the main content element a sectioning element, too? Kind Regards, Ian Yang On Wed, Oct 17, 2012 at 8:03 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi all, I have updated the maincontent spec [1] and would appreciate any feedback (including, but not limited to implementers). In the process of developing the maincontent element spec [1] I looked at data from a number of sources [3] on frequency of usage of id values to indicate the main content area of a web page. I also used data [2] I gathered in April 2012 based on a URL list of the top 10,000 most popular web sites. In preparing the data [2] I subsetted the total usable HTML documents (approx 8900 pages - the home pages for sites in the top 10,000 URLs list ) by searching for the use of the HTML5 doctype (approx 1545 pages). I figured that documents using the HTML5 doctype would provide the freshest code. What is apparent from the home page data in the sample: * use of a descriptive id to value to identify the main content area of a web page is common. (id=main|id=content|id= maincontent|id=content-main|id=main-content used on 39% of the pages in the sample [2]) * There is a strong correlation between use of ARIA role='main' [5] on an element with id values of 'content' or 'main' or permutations. (when used = 101 pages) 77% were on an element with id values of 'content' or 'main' or permutations. * There is a strong correlation between use of id values of 'content' or 'main' or permutations as targets for 'skip to content'/'skip to main content' links (when used = 67 pages) 78% of skip link targets # were elements with id values of 'content' or 'main' or permutations. * There appears to be a strong correlation in the identification of content areas (with id values of 'content' or 'main' or permutations.) as what is described in the spec as appropriate content to be contained with a maincontent element [1]: The maincontent element representshttp://dev.w3.org/html5/spec/rendering.html#representsthe main content section of the body of a document or application. The main content section consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application. ... The main content section of a document includes content that is unique to that document and excludes content that is repeated across a set of documents such as site navigation links, copyright information, site logos and banners and search forms (unless the document or applications main function is that of a search form). I have prepared approx 440 sample pages [4] from the same URL set with CSS to outline and identify use of container elements with id values of 'content' and/or 'main' and role=main, these samples can be used to visually assess how closely the spec definition of maincontent matches the reality of element usage with the stated id values. [1] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html [2] http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/ [3] http://triin.net/2006/06/12/CSS#figure-34, http://westciv.typepad.com/dog_or_higher/2005/11/real_world_sema.html, http://dev.opera.com/articles/view/mama-common-attributes/#id note: The first link in each list item links to the original page the second link prefixed with copy is the same page with the CSS added. [4] http://www.html5accessibility.com/tests/HTML5-main-content/ [5] http://www.w3.org/TR/wai-aria/roles#main -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives
[whatwg] maincontent element spec updated and supporting data provided
Hi all, I have updated the maincontent spec [1] and would appreciate any feedback (including, but not limited to implementers). In the process of developing the maincontent element spec [1] I looked at data from a number of sources [3] on frequency of usage of id values to indicate the main content area of a web page. I also used data [2] I gathered in April 2012 based on a URL list of the top 10,000 most popular web sites. In preparing the data [2] I subsetted the total usable HTML documents (approx 8900 pages - the home pages for sites in the top 10,000 URLs list ) by searching for the use of the HTML5 doctype (approx 1545 pages). I figured that documents using the HTML5 doctype would provide the freshest code. What is apparent from the home page data in the sample: * use of a descriptive id to value to identify the main content area of a web page is common. (id=main|id=content|id= maincontent|id=content-main|id=main-content used on 39% of the pages in the sample [2]) * There is a strong correlation between use of ARIA role='main' [5] on an element with id values of 'content' or 'main' or permutations. (when used = 101 pages) 77% were on an element with id values of 'content' or 'main' or permutations. * There is a strong correlation between use of id values of 'content' or 'main' or permutations as targets for 'skip to content'/'skip to main content' links (when used = 67 pages) 78% of skip link targets # were elements with id values of 'content' or 'main' or permutations. * There appears to be a strong correlation in the identification of content areas (with id values of 'content' or 'main' or permutations.) as what is described in the spec as appropriate content to be contained with a maincontent element [1]: The maincontent element representshttp://dev.w3.org/html5/spec/rendering.html#representsthe main content section of the body of a document or application. The main content section consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application. ... The main content section of a document includes content that is unique to that document and excludes content that is repeated across a set of documents such as site navigation links, copyright information, site logos and banners and search forms (unless the document or applications main function is that of a search form). I have prepared approx 440 sample pages [4] from the same URL set with CSS to outline and identify use of container elements with id values of 'content' and/or 'main' and role=main, these samples can be used to visually assess how closely the spec definition of maincontent matches the reality of element usage with the stated id values. [1] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html [2] http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/ [3] http://triin.net/2006/06/12/CSS#figure-34, http://westciv.typepad.com/dog_or_higher/2005/11/real_world_sema.html, http://dev.opera.com/articles/view/mama-common-attributes/#id note: The first link in each list item links to the original page the second link prefixed with copy is the same page with the CSS added. [4] http://www.html5accessibility.com/tests/HTML5-main-content/ [5] http://www.w3.org/TR/wai-aria/roles#main -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Validator.nu: Attribute role not allowed on element h2 at this point.
Hi Ian, you wrote: Can you provide an example of how using a redundant role value can lead to conflicts? Sure. Support someone writes: input type=submit name=submit value=Submit My Form! role=button ...and then someone else copies and pastes it, and changes the type and name and value, but doesn't know what role is: input type=password name=password value= role=button that has nothing to do with it being redundant, it's to do with people copying and pasting code, the same issue would occur for many other attributes. That's why we have conformance checkers to pick up such issues where they cause harm. If the role and the input type do not match the role is no longer redundant, so you did not answer the question. for example: nav role=navigation Under what circumstances can this example lead to 'conflicting information'? User copies-and-pastes this: nav class=fx-2 data-rollup=2s streamB onclick=activateRollup(this) role=navigation ...and tweaks it for their sidebar, getting: aside class=fx-3 data-rollup=3s streamC onclick=activateRollup(this) role=navigation again you have changed the element so it is no longer redundant (not that nav role=navigation is redundant in this case as IE and other browsers have not implemented the mapping and are unlikely in IE's case to in the foreseeable future due to constraints in their accessibility APIs) So it would appear you have no examples of when a redundant role causes harm. Do you have any example where using a role that matches the implied default role causes harm? You're only really going to need it when making custom widgets with divs. (There's a lot of ARIA roles you'd never need to use if you just used HTML correctly, IMHO.) You are incorrect here, there are some cases where putting a role on an input is required as implemented in browsers, to allow the use of non global aria attributes on the element. It would be better if this was not a requirement, but until browsers fix their implementations, in limited circumstances it is necessary. this is detailed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=11557 a bug for which you have chosen not to fix without providing an adequate explanation. I am unlcear why you want HTML not to ignore implementation realities? Bugs should be fixed. We shouldn't warp the language to work around temporary bugs. We certainly shouldn't teach a new generation of authors to use bad authoring styles just because of a transitory issue with certain browsers. Just fix the browsers. If in the meantime there are hacks that can be applied for those browsers, it's fine for those to be done even if they cause validators to raise a red flag -- they _should_ raise a red flag. It's just like writing a paper in school. It's not ok to hand in a paper that has Sellotape around the top of each page, one would get points dinged for presentation if nothing else. So someone who is reviewing one's paper should raise a red flag if one's paper has such tape. However, if one's printer has a problem that causes it to slightly rip each page as it prints the paper, then maybe it's considered acceptable to have the tape on the paper. I would agree with you, except there has been no indication from browser vendors (to my knowledge) that they intend to fix this issue. If you know otherwise please share the good news. Until such times as we do have such a commitment from vendors, the conformance requirements in the spec should reflect not what we would like to happen, but what is required to get the feature to work. On Sun, 10 Jun 2012, Steve Faulkner wrote: You don't clearly differentiate between roles, properties and states, ther are quite a few states and properties NOT provided in HTML5 that may have use cases for adding to an input element, for example aria-hapopup, aria-labelledby, aria-decirbedby, aria-controls etc Could you give an example of any of these in valid use? the following input (gmail search box) uses aria-haspopup=true input type=text value= autocomplete=off name=q class=gbqfif id=gbqfq *aria-haspopup=true* style=border: medium none; padding: 0px; margin: 0px; height: auto; width: 100%; background: url(quot;data:image/gif;base64,R0lGODlhAQABAID/AMDAwCH5BAEALAABAAEAAAICRAEAOw%3D%3Dquot;) repeat scroll 0% 0% transparent; position: absolute; z-index: 6; left: 0px; dir=ltr spellcheck=false the following link (from the gmail 'more' menu) use aria-haspopup and aria-owns a aria-owns=gbd aria-haspopup=true onclick=gbar.tg(event,this) href= http://www.google.com/intl/en/options/; id=gbztm class=gbgtspan class=gbtb2/spanspan class=gbts gbtsa id=gbztmsspan id=gbztms1More/spanspan class=gbma/span/span/a the gmail search button uses aria-label button class=gbqfb aria-label=Google Search id=gbqfbspan class=gbqfi/span/button These are few examples in use, I don't know if you consider them 'valid use
Re: [whatwg] Conformance checking of missing alternative content for images
Hi Ian, I think the changes to the spec in regards to advice for use of title are a practical step in the right direction. The spec currently allows img without alt if the title attribute is present That's a wild over-statement of the case. In terms of conformance checking it is not, as you have said yourself, and others have echoed, most developers will not read the spec and therefore will not understand or take account of the nuances of when alt is required. The conformance checker on the other hand as per HTML LS will not flag this as an error img title=text which is a clear signal that it is allowed. While putting requirements into the spec on what browser implementers must do to conform with it is one thing, whether and when they do is what I am interested in, and for the past 19 years they have not provided input device independent access to the title attribute, lets hope that changes and until it does so conformance should reflect this fact. It is suggested that due to the current and historical implementation of title attribute display in browser, discouraging authors from using the img title=text markup pattern would result in more usable and accessible content. It is suggested by whom? I'm not sure I follow. I suggest. Providing content as text as against it being hidden in an attribute that requires a mouse to access it, will make the content more usable and accessible. While it is unfortunate that we still have a conformance requirement difference between HTML LS and HTML5 I am satisfied at least that the major conformance checking tool on the web will reflect the HTML5 conformance rule disallowing img title=text, and as we are often told, shipping code wins. regards SteveF Message: 4 Date: Wed, 22 Aug 2012 00:43:29 + (UTC) From: Ian Hickson i...@hixie.ch To: whatwg wha...@whatwg.org Subject: [whatwg] Conformance checking of missing alternative content for images Message-ID: pine.lnx.4.64.1208211938550.30...@ps20323.dreamhostps.com Content-Type: text/plain; charset=utf-8 On Fri, 27 Jul 2012, Steve Faulkner wrote: The spec currently allows img without alt if the title attribute is present That's a wild over-statement of the case. To be precise, the specification requires that the alt attribute be present, with the exception of some very specific cases. The specific case where the presence of the title= attribute is in any way relevant is the specific case where the image is obtained in some automated fashion without any associated alternative text (e.g. a Webcam), or because the page is being generated by a script using user-provided images where the user did not provide suitable or usable alternative text (e.g. photograph sharing sites), or because the author does not himself know what the images represent (e.g. a blind photographer sharing an image on his blog). Only in those cases can the alt= attribute be omitted if the title= attribute is instead present with text. In all other cases, img elements in Web pages must have alt= attributes. This is problematic for a number of reasons: 1. One of the functions of alt as implemented is that the text is displayed when images are disabled or not available. I ran some tests a while back[1] and found that while webkit based browsers display title attribute content if images are disabled or not available, IE, Firefox and Opera do not. I did a quick recheck and focund the implementations have not changed in the 2.5 years since I ran those tests. 2. title attribute content is commonly displayed as a tooltip that appears when a user moves their mouse over an element (in this case an img) It is long running issue (14 years or so) that tooltips and thus title attribute content is not displayed for keyboard only users. Browsers vendors are fully aware of the issue, but as yet there have not yet been moves to fix the issue* These are violations of the UAAG, and affect far more than images. Any situation where there is content in a title= attribute would be an accessibility problem, if title= attributes aren't exposed. Either we should therefore drop the title= attribute (unlikely to be a practical option), or we should fix the browsers to expose title= attributes in cases where the user is not able to trigger the tooltip. I've updated the spec to be clearer about this. It is suggested that due to the current and historical implementation of title attribute display in browser, discouraging authors from using the img title=text markup pattern would result in more usable and accessible content. It is suggested by whom? I'm not sure I follow. We could address this problem by making changes along these lines: Remove the clause in the spec that makes the markup pattern conforming: The title attribute is present and has a non-empty value This doesn't solve the problem in the general case, so it's not really a solution worth considering. It just
Re: [whatwg] alt and title attribute exception
Hi Philip, you wrote: To be very clear, you agree with the spec, think that WebKit is wrong and would not offer any applause if Opera were to use the title attribute to replace images when images are disabled and there is no alt attribute? I don't have a strong view on the display of title content as fallback when alt is absent. It would be preferable to disambigaute the source of the text by (for example) prefixing the text with title:. What browsers provide as fallback in the absence of the appropriate content is a different beast than the question of what we should promote as a conforming markup pattern. I do think that if browsers provide a single feature (title) to provide tooltip text and image fallback text (which is what we are talking about), coupled with giving authors the greenlight via the current conformance free pass, it will lead to its use and misuse, which is why the must level requirement on browsers not to display alt in the same way as title was included in the first place AFAIK - To deter browsers from displaying alt both as fallback and tooltip.I do not see a difference between alt being displayed as both fallback and tooltip and title being displayed as both fallback and tooltip. If someone can explain to me why one is good but the other is not, I would be appreciative. you wrote: Yes, the semantic difference is clear. What I wanted to add to this discussion is confirmation that the title attribute is inaccessibly to mobile browser users and likely to remain so. I don't know what conclusions to draw or what the spec should say, but to me it seems unwise to use the title attribute at all... Well this is what I brought up in the other fora that this issue is/was debated. The (almost) complete lack of display of title in mobile browsers. Henri's example of firefox on android is interesting , but of only limited utility since the text is truncated, the same issue occurs (truncation) for both alt and title on in various browsers, in some browsers the alt/title is omitted completely if the text is longer than a certain value [1] regards SteveF [1] http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/screenshots.html On 1 August 2012 13:05, Philip Jägenstedt phil...@opera.com wrote: On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner faulkner.st...@gmail.com wrote: title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. To be very clear, you agree with the spec, think that WebKit is wrong and would not offer any applause if Opera were to use the title attribute to replace images when images are disabled and there is no alt attribute? you wrote: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. Yes, the semantic difference is clear. What I wanted to add to this discussion is confirmation that the title attribute is inaccessibly to mobile browser users and likely to remain so. I don't know what conclusions to draw or what the spec should say, but to me it seems unwise to use the title attribute at all... -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] alt and title attribute exception
Hi leif, you wrote: [I suppose 'the spec' means the W3 HTML5 spec?] no, i believe we are discussing what's in HTML living standard. regards SteveF Philip Jägenstedt Wed Aug 1 05:05:15 PDT 2012: On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner wrote: title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. To be very clear, you agree with the spec, think that WebKit is wrong and would not offer any applause if Opera were to use the title attribute to replace images when images are disabled and there is no alt attribute? [I suppose 'the spec' means the W3 HTML5 spec?] Question: I would be rather simple for Opera, would it not, to add some CSS that makes the @title be used as @alt replacement when the @alt is lacking? -- leif halvard silli
Re: [whatwg] alt and title attribute exception
Hi Henri, you wrote: Firefox for Android (at least on the Nightly channel) displays the content of the title attribute on XKCD comics (up to a length limit which can often be too limiting) upon tap and hold: http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png; that's useful data, too bad about the truncation issue, as I pointed out in my recent email to the list, that is an issue for both alt/title fallback on some desktop browsers. philip wrote: it seems unwise to recommend using the title attribute to convey important information. The title attribute has sever limitations in its utiltity, if one goal is to provide accessible content, I detailed some some cases where it should and should not be used [1] Indeed. In addition to image considerations, I think http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad advice. I agree and have detailed the reasons why [2] [1] using the HTML title attribute http://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/ [2] http://www.w3.org/html/wg/wiki/ChangeProposals/notitle_annotations regards Stevef -- Message: 5 Date: Wed, 1 Aug 2012 15:56:23 +0300 From: Henri Sivonen hsivo...@iki.fi To: whatwg wha...@whatwg.org Subject: Re: [whatwg] alt and title attribute exception Message-ID: CAJQvAufAJp=PN=gAKD3oUCL4suwwWdMg6= cfbqewrvgipvs...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Tue, Jul 31, 2012 at 12:18 PM, Philip J?genstedt phil...@opera.com wrote: When this was last discussed in the HTML WG (January 2012) I opened a bug (MOBILE-275) for Opera Mobile to expose the title attribute in our long-click menu, arguing that one could not enjoy XKCD without it. I meant to report back to the HTML WG but forgot, so here it is. Unfortunately, the bug was rejected... quoting the project management: Sure it is nice to have, but noone else has it so we will not put our effort into this Firefox for Android (at least on the Nightly channel) displays the content of the title attribute on XKCD comics (up to a length limit which can often be too limiting) upon tap and hold: http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png Not to suggest that XKCD's title usage is OK but just to correct the noone else bit. it seems unwise to recommend using the title attribute to convey important information. Indeed. In addition to image considerations, I think http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad advice. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] alt and title attribute exception
Hi Philip, the spec currently says of the alt attribute [1]: the value of the alt attribute provides equivalent content for those who cannot process images or who have image loading disabled (i.e. it is the img element's fallback content). The alt attribute does not represent advisory information. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. And this is how it is treated in modern graphical browsers, it is not displayed unless images are disabled or not available and it is used as the accessible name for the image in accessibility APIs whether the image is available or not. Unlike the title attribute which is available in some browsers when a user hovers their mouse over an image with a title attribute. the spec currently says of the title attribute [2]: The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image. title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. you wrote: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-alt [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-title-attribute regards Stevef On 31 July 2012 12:12, Philip Jägenstedt phil...@opera.com wrote: On Tue, 31 Jul 2012 11:48:52 +0200, Chaals McCathieNevile w...@chaals.com wrote: On Tue, 31 Jul 2012 11:18:37 +0200, Philip Jägenstedt phil...@opera.com wrote: AFAICT there's also no way to read the alt attribute on Opera Mobile. You mean title, right? (alt can be read by turning of image loading - although the famous bug http://a11ybugs.org/bug-3.php (I know a few versions of it in Opera's BTS) doesn't help). I really did mean the alt attribute, I didn't try turning images off, just long-clicking... oops. I suppose that if mobile browsers fix Bug 3 *and* fall back to the title attribute in the absence of an alt attribute then it would be OK to use title instead of alt, but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? -- Philip Jägenstedt Core Developer Opera Software http://www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] alt and title attribute exception
Apologies. the last sentence should have read: The last point is another reason why making the title attribute on images (without alt) conforming, IS NOT good for users, is that the semantics, for all users, are ambiguous. regards Stevef On 31 July 2012 13:03, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Philip, the spec currently says of the alt attribute [1]: the value of the alt attribute provides equivalent content for those who cannot process images or who have image loading disabled (i.e. it is the img element's fallback content). The alt attribute does not represent advisory information. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. And this is how it is treated in modern graphical browsers, it is not displayed unless images are disabled or not available and it is used as the accessible name for the image in accessibility APIs whether the image is available or not. Unlike the title attribute which is available in some browsers when a user hovers their mouse over an image with a title attribute. the spec currently says of the title attribute [2]: The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image. title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. you wrote: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-alt [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-title-attribute regards Stevef On 31 July 2012 12:12, Philip Jägenstedt phil...@opera.com wrote: On Tue, 31 Jul 2012 11:48:52 +0200, Chaals McCathieNevile w...@chaals.com wrote: On Tue, 31 Jul 2012 11:18:37 +0200, Philip Jägenstedt phil...@opera.com wrote: AFAICT there's also no way to read the alt attribute on Opera Mobile. You mean title, right? (alt can be read by turning of image loading - although the famous bug http://a11ybugs.org/bug-3.php (I know a few versions of it in Opera's BTS) doesn't help). I really did mean the alt attribute, I didn't try turning images off, just long-clicking... oops. I suppose that if mobile browsers fix Bug 3 *and* fall back to the title attribute in the absence of an alt attribute then it would be OK to use title instead of alt, but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? -- Philip Jägenstedt Core Developer Opera Software http://www.paciellogroup.com/resources/wat-ie-about.html -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] alt and title attribute exception
Hi Ben I was not talking about being displayed as a tooltip . I was referring to the display as a replacement for an image when images are disabled. There is no indication that the text is advisory information rather than a text alternative. So in this case alt is being displayed in the same way as title. Regards SteveF Sent from my iPhone On 31 Jul 2012, at 15:36, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: On Tue, Jul 31, 2012 at 1:03 PM, Steve Faulkner faulkner.st...@gmail.com wrote: The alt attribute does not represent advisory information. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. [snip] In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. Debatable. It's not showing @alt on hover, so their presentation is different. I think showing @alt on hover, as IE used to do, was the behavior this text was intending to discourage. That this behavior was wrong was after all a major tenet of: http://www.hixie.ch/advocacy/alttext This was premised on @alt being (potentially long) equivalent text rather than being a short name for the image though. Once both @alt and @title can be used to provide what could loosely be called titling information, the rationale for presenting the two differently begins to weaken. -- Benjamin Hawkes-Lewis
Re: [whatwg] alt and title attribute exception
Hi Leif, There is a distinction between what browsers should do to provide fallback and what should be promoted in the spec as a desired authoring pattern. browsers support many non conforming markup patterns. Because webkit browsers display title attribute content if alt attribute is not present, it is not a reason for making the markup pattern conforming. I believe the reasoning for the must requirement for browsers not to display alt in the same way as title, was to remove a reason for authors to use alt to provide advisory information, if so, similarly making the use of title without alt non conforming removes the legitimacy of the markup pattern that results in the same thing. Anyway this discussion is moving off the crux of the issue with allowing title when alt is not available. It promotes the use of the title attribute for the presentation of text content for all users at all times when due to long running browser implementation realities it is not available to some users when it should be. regards Stevef On 31 July 2012 19:57, Leif Halvard Silli xn--mlform-...@xn--mlform-iua.nowrote: Steve Faulkner on Tue, 31 Jul 2012 13:03:02 +0100, wrote, in reply to Philip Jägenstedt: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. So, it is bad that the Webkittens fall back to using @title? I must admit that I don't understand how you reason. Because, when @title is used as fallback, then we _want_ @title to be treated as @alt. So why do need a method to distinguish the two, then? *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). On the old mac I have at hand, right now, then AXImage (of Accessibility Inspector) renders the @title content, when the @alt is lacking. There is no info about the fact that the AXImage stems from @title. But perhaps that has changed so that AT users are informed when the accessible name stems from the @title? The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. And another place in the same letter you say: User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. Comments: (1) It does not follow, from the fact that the spec forbids @alt from being rendered as a tooltip, that a tooltip cannot be rendered as an @alt. (2) If the spec did not forbid @alt from render as a tooltip, then authors would be confused to write @alt texts that were excellent as tooltips but delbad/del inssub optimal/ins as @alt content. (Thus, it is based on the respect for how the two features are distinct.) Conversely, if @title render as @alt, then authors would perhaps write tooltips that served OK as @alt. If that is bad, then why is it bad? (3) The fact that @title is used as last resort when calculating the accessible name is because an accessible name is so important that even a tooltip can be useful for that purpose, when need be. So why would it be a big no no that a lacking @alt causes the @title to be rendered as @alt content? I think the spec's motivation for the current exception might be similar to the generator exception: It is done to not triggers authors to e.g. create empty @alt or repeated, meaningless @alt text of the kind alt=image - just in order to validate. I disagree strongly with the generator exception. But I cannot say I strongly disagree with the @title exception. With the introduction of ARIA, it has become even less critical to remove this exception, since ARIA includes the @title as a last resort anyhow. I'm uncertain about how lack of keyboard access to @title can be used against this exception, when both Webkittens and ARIA give them access to it. -- Leif Halvard Silli -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar
[whatwg] alt and title attribute exception
Hi all, The spec currently allows img without alt if the title attribute is present This is problematic for a number of reasons: 1. One of the functions of alt as implemented is that the text is displayed when images are disabled or not available . I ran some tests a while back[1] and found that while webkit based browsers display title attribute content if images are disabled or not available, IE, Firefox and Opera do not. I did a quick recheck and focund the implementations have not changed in the 2.5 years since I ran those tests. 2. title attribute content is commonly displayed as a tooltip that appears when a user moves their mouse over an element (in this case an img) It is long running issue (14 years or so) that tooltips and thus title attribute content is not displayed for keyboard only users. Browsers vendors are fully aware of the issue, but as yet there have not yet been moves to fix the issue* It is suggested that due to the current and historical implementation of title attribute display in browser, discouraging authors from using the img title=text markup pattern would result in more usable and accessible content. We could address this problem by making changes along these lines: Remove the clause in the spec [2] that makes the markup pattern conforming: The title attribute is present and has a non-empty value If at some point in the future browsers implementations change to: 1. Displaying title attribute content when images are disabled or are not available. 2. Providing input device independent access to title attribute content on non focusable elements. It would then make sense to reapply the clause so that the spec and implementation realities align. * IE 10 has implemented the display of tooltips on focusable elements, but this does not resolve the issue for non focusable elements. Note: further details of the issues are available [3] [1] http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/alt-examples.html [2] http://www.whatwg.org/specs/web-apps/current-work/multipage//embedded-content-1.html#guidance-for-conformance-checkers [3] http://www.w3.org/html/wg/wiki/ChangeProposals/notitlev2 -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] can a click event be handled on an unbacked hit region()?
Hi Ted, you wrote: If the hit region has an unbacked region description, click events are fired at the canvas element. In this case, the click event's 'region' property will contain the ID of the hit region which was clicked. In this case unbacked regions can be used to designate interactive regions, but the interactivity is confined to mouse based events, as the region is not associated with a DOM element that can receive focus. regards Stevef Hi Steve, You wrote: From my reading of the hitregion() [1] section of the spec it is unclear to me whether click events work on unbacked regions It is clear that mouse move events can be used, but will developers be able to detect and make use of click events on backed regions? My guess is yes, which appears to mean that unbacked regions can be used as pseudo interactive controls for mouse or touch events, is that correct? If the hit region has an element in the fallback content as it's control, click events get forwarded to the relevant fallback element. If the hit region has an unbacked region description, click events are fired at the canvas element. In this case, the click event's 'region' property will contain the ID of the hit region which was clicked. Look for the spec text beginning with The MouseEvent interface is extended to support hit regions. Ted -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Hi Bronslav - keeping to the technical as per hixi'e request you wrote: both derives their authority from browser vendors - specification not supported by majority of browsers is irrelevant, developers can only work with what is in the browser (plugins are becoming obsolete, as it would seems). The only thing, that matters is what is in browsers. Not exactly true, the semantics of HTML and the rules on how implemented (or yet to be implemented) features are to be used within the constraints of their implementation is not down to the browser vendors, the rules on how HTML is to be used has an important effect upon the accessibility of authored content. Also there are there are other classes of software such as conformance checkers for which HTML/HTML5 provide normative requirements and advice. And as it happens this is one of the areas where the 2 specs diverge: In the HTML5 spec [5] there are currently only 2 cases (soon there may only be 1 [1]) where lack of alt on an attribute is considered conforming: A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies: •The img element is in a figure element that satisfies the conditions described above. •The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string generator. (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text — validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.) While in HTML living standard there are 3 [2] the one missing from HTML5 is The title attribute is present and has a non-empty value The reasons why the HTML5 specification does not have the same requirement as HTML the living standard is well documented [3] So conformance checkers have to make a decision about which set of rules to implement. I would strongly suggest that one of the major validation tools [4] will implement the rules in the W3C HTML spec, not HTML living standard. [1] http://www.w3.org/html/wg/wiki/ChangeProposals/Issue31cMetaGeneratorUpdated [2] http://www.whatwg.org/specs/web-apps/current-work/multipage//embedded-content-1.html#guidance-for-conformance-checkers [3] http://www.w3.org/html/wg/wiki/ChangeProposals/notitlev2 [4] http://validator.w3.org/ [5] http://dev.w3.org/html5/spec/the-img-element.html#guidance-for-conformance-checkers On 25.7.2012 16:55, Steve Faulkner wrote: hi Bronislav you wrote: I was just looking at WHATWG wiki and there is nice sentence: In general the WHATWG will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the W3C group doesn't demonstrate any serious lapses in judgement. I am sure the same can be said from the other viewpoint, The W3C HTML working group will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the WHATWG group doesn't demonstrate any serious lapses in judgement. Which is why the 2 specs have diverged on author conformance requirements and advice as each group considers the other to have made lapses in judgement. Hi Steve, True, no doubt about that, but that is matter of relevancy of opinion. Mine and yours are irrelevant. W3C and WHATWG as organizations are irrelevant - neither actually have any authority, both derives their authority from browser vendors - specification not supported by majority of browsers is irrelevant, developers can only work with what is in the browser (plugins are becoming obsolete, as it would seems). The only thing, that maters is what is in browsers. Bronislav Klucka -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] canvas hitregion() clarification sought
resending as plain text as the first time the links made it indecipherable, On 25 July 2012 01:13, Steve Faulkner faulkner.st...@gmail.com wrote: Upon reading the hit region section [1] of the spec again I noticed this: If any of the following conditions are met, throw a NotSupportedError exception and abort these steps. ... The arguments object's control member is not null but is neither an a element that represents a hyperlink, a button element, an input element whose typeattribute is in one of the Checkbox or Radio Button states, nor an input element that is a button This reads like it will throw an error if a custom control is referenced by control() canvas div tabindex=0 role=checkbox /canvas is this correct? [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-regions -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
hi Bronislav you wrote: I was just looking at WHATWG wiki and there is nice sentence: In general the WHATWG will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the W3C group doesn't demonstrate any serious lapses in judgement. I am sure the same can be said from the other viewpoint, The W3C HTML working group will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the WHATWG group doesn't demonstrate any serious lapses in judgement. Which is why the 2 specs have diverged on author conformance requirements and advice as each group considers the other to have made lapses in judgement. -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Hi Mat, Yeah, this would be a bit tricky in terms of backwards-compatibility, as you said. I feel the gut reaction from a lot of authors would be “I don’t want that text showing up in some browsers but not others,” then (sadly) omission. It’s hide-able with CSS, as you said, but it would add some complexity. I would have thought a picture polyfill would handle the hiding. and I am not sure that the possible backward compat issues should deter us from providing a better text alternative method in the longer term. besides thinking about it, providing the alt on the img would suffice until such times that lat text as a child of picture is supported (if implemented). which removes the need for alt on picture altogether, which is of no use anyway until it is implemented. 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 alt=Description of image subject. /picture This seems like a great candidate for `figcaption`, and could be pollyfilled, in a way, through the use of `aria-describedby`. I wouldn’t want to discourage the use of `alt` tags on either `picture` or the fallback `img`, but — and correct me if I’m wrong — isn’t `aria-describedby` specced to take precedence over the `alt` attribute? That might be the ideal approach — and even if not, a bit of redundancy may not hurt there. There is one current implenentation [1] (Firefox) of figure/figcation accessibility. this implementation can be illustrated using ARIA. although it does not use ARIA, the acc support is provided through IAccessible2 figure role=group aria-labelelledby=caption1 img figcaption id=caption1 caption text figcaption /figure So the figcaption content labels the figure. Also note that the figcaption has a role=caption (from IA2), but that is not currently defined in ARIA In regards to aria-decribedby it does not override the alt attribute, aria-describedby provides the accessible description, it is not used in accessible name calculation. if aria-labelledby is on an img element it overrides that alt. [1] figcaption http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-43 figure http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-44 regards SteveF On 24 July 2012 16:05, Mathew Marquis m...@matmarquis.com wrote: On Jul 23, 2012, at 5:38 PM, Steve Faulkner wrote: Hi Mat, as I previously previously mentioned, 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. 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 palt 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 Yeah, this would be a bit tricky in terms of backwards-compatibility, as you said. I feel the gut reaction from a lot of authors would be “I don’t want that text showing up in some browsers but not others,” then (sadly) omission. It’s hide-able with CSS, as you said, but it would add some complexity. 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 figcaptioncaption text/figcaption /figure This seems like a great candidate for `figcaption`, and could be pollyfilled, in a way, through the use of `aria-describedby`. I wouldn’t want to discourage the use of `alt` tags on either `picture` or the fallback `img`, but — and correct me if I’m wrong — isn’t `aria-describedby` specced to take precedence over the `alt` attribute? That might be the ideal approach — and even if not, a bit of redundancy may not hurt there. 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. regards Stevef On 23 July 2012 20:06, whatwg-requ...@lists.whatwg.org wrote: Send whatwg mailing list submissions to whatwg
[whatwg] canvas hitregion() clarification sought
Upon reading the hit region section [1] of the spec again I noticed this: If any of the following conditions are met, throw a NotSupportedErrorhttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#notsupportederror exception and abort these steps. ... The arguments object's control member is not null but is neither an ahttp://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-a-element element that representshttp://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#represents a hyperlinkhttp://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#hyperlink, a buttonhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-button-element element, an inputhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element element whose typehttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-typeattribute is in one of the Checkboxhttp://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#checkbox-state-(type=checkbox) or Radio Buttonhttp://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#radio-button-state-(type=radio) states, nor an inputhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element element that is a buttonhttp://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#concept-button This reads like it will throw an error if a custom control is referenced by control() canvas div tabindex=0 role=checkbox /canvas is this correct? [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-regions -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
[whatwg] can a click event be handled on an unbacked hit region()?
From my reading of the hitregion() [1] section of the spec it is unclear to me whether click events work on unbacked regions It is clear that mouse move events can be used, but will developers be able to detect and make use of click events on backed regions? My guess is yes, which appears to mean that unbacked regions can be used as pseudo interactive controls for mouse or touch events, is that correct? [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-regions -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
will function as expected, instead. In terms of selecting a source element, this markup leverages all the strengths of media queries ? the syntax created for this very purpose ? to handle the ?art direction? use case. However, as has been detailed at length here and elsewhere, `device-pixel-ratio` media queries are poorly suited towards these decisions. As an author, using vendor-prefixed `min-device-pixel-ratio` media queries in the example above would involve a massive amount of text and twice as many source elements. This could get unwieldy for authors very quickly, a concern voiced numerous times in these ongoing discussions. Further, implementation of MQ-based resolution switching is far more difficult on the UA side: a very real concern. Once we?ve used media queries to determine the most appropriate source element, srcset?s originally intended usage becomes absolutely ideal for our purposes: simply determining the appropriate image source for a user?s resolution. It?s worth noting that this example is, in fact, the most convoluted this element can ever be. This pattern in no way precludes the use of srcset on an `img` tag for simply preforming resolution switching, nor does it preclude the use of `picture` as originally proposed for the ?art direction?/screen size use cases, with `src` in source elements rather than `srcset`. ## Bandwidth We cannot reliably make assumptions about bandwidth based on client capabilities ? a MacBook Pro with a Retina display may be tethered to a 3G phone; a high-resolution mobile device is as likely to be connected to WiFi as it is an EDGE connection. Based on previous discussion on the list, I think we?re largely in agreement that bandwidth decisions are best left to the browser. It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable ? I?ve expressed that elsewhere, in no uncertain terms. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available ? and further, I believe there should be a user settable preference for ?always use standard resolution images,? ?always use high resolution images,? ?download high resolution as bandwidth permits,? and so on. In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. I think `srcset` affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn?t want to introduce that sort of variance to the media query spec ? a syntax long established as a set of absolutes. It seems `srcset` won?t be going anywhere, and that?s not an indictment. There is a time and a place for `srcset`, and I feel that place is resolution switching ? as it was originally intended. Our best efforts to bring srcset closer in-line with the originally proposed picture element only stand to leave us with a siloed microsyntax that inconsistently serves the purpose of media queries. With that comes further opportunity for errors by implementors and authors alike ? countless new potential points of failure. ## Updated Polyfill In order to better wrap my head around this pattern, I?ve updated Scott Jehl?s Picturefill to make use of the proposed syntax. The source code is available on GitHub ( https://github.com/Wilto/picturefill-proposal/ ), and I?ve posted a demo ( http://wil.to/picturefill/ ) as well. Thank you for your ongoing consideration, sincerely. I look forward to finally putting this issue to rest. Mat Marquis -- ___ whatwg mailing list whatwg@lists.whatwg.org http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org End of whatwg Digest, Vol 100, Issue 28 *** -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Hi Hixie, I believe you have made some spurious claims, one of them being; The WHATWG effort is focused on developing the canonical description of HTML and related technologies The claim that HTML the living standard is canonical appears to imply that the requirements and advice contained within HTML the living standard is more correct than what is in the HTML5 specification. I do not consider this to be wholly that case, in particular in regards to author level conformance requirements and advice, where the HTML standard has no special claim to authority, it is not the domain of browser vendors to decide what is good authoring practise and any authoring requirements that go beyond implementation realities. The HTML living standard is not a canonical description of HTML, if it was there would be no need for the existence of specifications such as HTML to Platform Accessibility APIs Implementation Guidehttp://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html, this document is in existence and is being developed because neither the HTML5 specification nor the HTML living standard contains anything bearing a resemblance of what could be considered and adequate description of how user agents can implement accessibility support for HTML features in an interoperable way. Neither HTML5 in its current form or HTML the living standard can claim to be a canonical description of author conformance requirements for the provision of text alternatives, as there is another document in existence also published by the W3C that provides normative requirements for the subject:http://dev.w3.org/html5/alt-techniques/ The HTML standard contradicts the HTML5 specification (or vice versa) on a number of author conformance requirements and advisory techniques, including use of tables, use of ARIA and use of the title attribute. In respect to those author related requirements mentioned above the HTML5 specification can currently claim to be contain a more accurate set of requirements and advice, that takes into account current implementation realities, thus providing author with more practical advice and thus end users with a better experience. All in all I do not agree with your claim of the HTML living standard being canonical. It is unfortunately the case that we now have at least 2 specifications; HTML5 and the living standard neither of which can claim to be canonical description of HTML for stakeholders other than browser vendors. -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
[whatwg] Using ARIA in HTML - intial draft
I have posted an intial draft of a document I have been working on which attempts to provide practical advice to developers on what ARIA to use in HTML. http://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index.html My intention is to provide a non normative resource that fills in the gaps in the current HTML5/HTML specification and a document that is more readable (i.e. less jargonist) It does deviate from HTML5/HTML in some of its suggestions, these deviations are based on current implementation realities. all feedback welcome -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] content element, which we need in our documents
Hi Ian, ARIA fills the gap in HTML with role=main http://www.w3.org/TR/wai-aria/roles#main I agree that an explicit element would be nice, but the powers that be have rejected the idea. -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
[whatwg] Validator.nu: Attribute role not allowed on element h2 at this point.
where the browser can't do a better job itself. So there's no point putting it on an input element, typically. You're only really going to need it when making custom widgets with divs. (There's a lot of ARIA roles you'd never need to use if you just used HTML correctly, IMHO.) On Tue, 13 Mar 2012, Kornel Lesi�~Dski wrote: On Tue, 13 Mar 2012 15:57:57 -, Hugh Guiney hugh.gui...@gmail.com hugh.gui...@gmail.com?Subject=Re%3A%20%5Bwhatwg%5D%20Validator.nu%3A%20%22Attribute%20role%20not%20allowed%20on%20element%20%20h2%20at%20this%20point.%22In-Reply-To=%253CPine.LNX.4.64.1206082227150.378%40ps20323.dreamhostps.com%253EReferences=%253CPine.LNX.4.64.1206082227150.378%40ps20323.dreamhostps.com%253E wrote: I am using it because VoiceOver does not understand hgroup/document outlines yet, and so announces two headings when there should only be one. It is not ideal markup; I'm merely trying to provide a better experience for AT users until new elements and parsing models are understood. Dusting off hsub proposal, which doesn't have that problem: http://www.w3.org/html/wg/wiki/ChangeProposals/hSub The benefits seem minor and insufficient to overcome the disadvantage of changing the spec again on this front, so I haven't adopted hsub. You wote: I've used role and/or redundant ARIA within the scripting environment to minimize calls in applications checking for roles. Redundancy doesn't harm anything, I actively promote it, as it does help, sometimes. I disagree with that premise, for what it's worth. Redundancy can lead to a number of problems; on the Web, in particular, it's common for redundancy to lead to cargo-cult authoring mistakes. For example, expert A writes a Web page with some redundant roles, author B copies markup from that page and changes it to suit their needs, but ignores the previously redundant bits and thus ends up with conflicting information instead of redundant information. Page ends up being sub-optimally accessible, because the previously redundant accessibility annotations now conflict with the page's real semantics, and are wrong. Can you provide an example of how using a redundant role value can lead to conflicts? for example: nav role=navigation Under what circumstances can this example lead to 'conflicting information'? Note: this example is not currently redundant in all browsers as the mapping is not implemented in some browsers. or this example button role=button Note: I am not advocating the unecessary addition of redundant roles, but would like to understand circumstances where this would cause practical harm, rather than just being unecessary. you wrote: ARIA doesn't have to be specified only from script, but if specified it should only be specified for things where the browser can't do a better job itself. So there's no point putting it on an input element, typically. You're only really going to need it when making custom widgets with divs. (There's a lot of ARIA roles you'd never need to use if you just used HTML correctly, IMHO.) You are incorrect here, there are some cases where putting a role on an input is required as implemented in browsers, to allow the use of non global aria attributes on the element. It would be better if this was not a requirement, but until browsers fix their implementations, in limited circumstances it is necessary. this is detailed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=11557 a bug for which you have chosen not to fix without providing an adequate explanation. I am unlcear why you want HTML not to ignore implementation realities? -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Validator.nu: Attribute role not allowed on element h2 at this point.
Hi Ian, On 10 June 2012 10:16, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Ian, On Mon, 12 Mar 2012, Charles Pritchard wrote: On 3/12/2012 5:52 PM, Ian Hickson wrote: On Mon, 12 Mar 2012, Charles Pritchard wrote: Ignore the error, the HTML5 spec does not reflect implementations in this section about ARIA. The warning is not helpful to authors nor does it accurately describe the means in which ATs work with ARIA. Are you saying you think the spec is wrong here and we should not allow role=presentational? I tend to agree, but I'm not sure it's worth it to try and work out exactly when role=presentational is harmful (as in this case) and when it's not. Consider something like CSS ::outside; it's a nice feature, but it's not in many browsers. If it were, it'd make more sense for authors to mark up decorative/presentation text in CSS. Pragmatically authors they have to make decisions, and sometimes that means various techniques with HTML4 and strange mixes of roles. I don't understand how to interpret your answer with respect to my question (and thus whether you think the spec should change, given your earlier statement). On Mon, 12 Mar 2012, Charles Pritchard wrote: These should only be warnings, not errors. The language Authors must not is inappropriate. Warnings are generally not useful. Either something is fine and we should support it, or it's wrong and we should alert the author. I think must is very much the appropriate requirement level here. From the implementation-side, the spec is wrong, it ranks native HTML semantics above ARIA DOM semantics. I do not understand what this means or why it is wrong. As a best practices note, it seems overly optimistic. There are situations with AT navigation where role conflicts do occur and/or redundancy in tagging is helpful. Can you elaborate on this? Specifically, can you give an example of such a case that conflicts with what the spec says? I don't believe it is appropriate for HTML to place restrictions on ARIA DOM. It's does not reflect implementations. The HTML spec should only specify what the default mappings are for HTML elements to ARIA. Authors may be advised to test AT software with their product. I don't understand what you mean. This statement is more in line with practice: Authors must test accessibility tree as part of development and usage of ARIA semantics.. We can't really put normative conformance criteria on whether authors test or not, that's a bit weird... On Tue, 13 Mar 2012, Charles Pritchard wrote: Some wild guesses: Treating a link as a button or a button as a link. I agree that allowing a button to be reported as being a link is bad for accessibility. The spec currently allows this due to a W3C HTMLWG chair decision that I opted not to challenge. @disabled and aria-disabled may be used via reference with aria-controls. type=range and role=slider for redundancy. various styling tricks with css selectors. Can you elaborate on these? In what way do they conflict with HTML? I've used role and/or redundant ARIA within the scripting environment to minimize calls in applications checking for roles. Redundancy doesn't harm anything, I actively promote it, as it does help, sometimes. I disagree with that premise, for what it's worth. Redundancy can lead to a number of problems; on the Web, in particular, it's common for redundancy to lead to cargo-cult authoring mistakes. For example, expert A writes a Web page with some redundant roles, author B copies markup from that page and changes it to suit their needs, but ignores the previously redundant bits and thus ends up with conflicting information instead of redundant information. Page ends up being sub-optimally accessible, because the previously redundant accessibility annotations now conflict with the page's real semantics, and are wrong. Ian has stated that warnings aren't very useful, he's looking for error or bust. That's confusing when it comes to ARIA testing, as it's more about the pragmatic effects of applying semantics and using a variety of ATs to test them. It's all about the pragmatic effects always. I don't see how this changes things here. Maybe we understand the words error and warning differently? On Tue, 13 Mar 2012, Scott Gonz�lez wrote: It's my understanding that authors should only apply ARIA via script. The redundancy cases seem to be the most reasonable use cases I've heard of for wanting ARIA in the initial markup, but even that seems wrong. What happens when you have type=range and role=slider, the UA doesn't understand the new types, and the script either never loads or has an error? The AT will pick up the role, but none of the functionality will be there. I don't see how that's better than not having the role applied. ARIA doesn't have
