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
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 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
Hi Steve, Thanks for your work, too :) Regards, Ian On Thu, Oct 18, 2012 at 2:14 PM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, Thanks for the detailed example, your reasoning is clear now and that gives me something to work with, and thanks for filing a bug! will respond on bug. regards SteveF
Re: [whatwg] maincontent element spec updated and supporting data provided
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. In the case of maincontent, there is no problem to be solved, and there is no use case that isn't already adequately handled by HTML. Naturally, anyone is welcome to make proposals and discuss use cases, but I would encourage people participating on this mailing list to focus first on establishing use cases, to avoid returning to topics that have previously been discussed without adding new information, and to avoid discussing 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] maincontent element spec updated and supporting data provided
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, 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. Ian is right, this is not part of the WHATG HTML specification, it is an HTML extension specification that I am developing through the W3C HTML WG with the aim of progressing the extension to a point where it can be folded back into HTML 5.0 if it meets the CR exit criteria or HTML 5.1. And i guess that if it is implemented that it will also become part of the WHATWG HTML specification. I have mailed the WHATWG list and asked for feedback on it as this is where some HTML standards developers and some implementers participate. In the case of maincontent, there is no problem to be solved, and there is no use case that isn't already adequately handled by HTML. There are use cases, and there is as much of a problem to be solved as there was for the addition of header/footer etc, but you do not agree that they are valid which, is fine, other people think they are valid. This is not new information: https://developers.google.com/webmasters/state-of-the-web/2005/classes It is new information, its data about the use of id's not classes, there is no data on id's in the documents you linked to. there is also no data in the linked ocuments about the relationship between id values and their use as targets of 'main content' links or data about the relationship between the use of role=main and such id values. Also its fresh data from 2012, not 2005. 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...). What you are saying does not invalidate the uses case for a maincontent element.the examples illustrate a correlation between the use of the cited id's on an element that is used as a container for the main content of a page, and a high correlation between the use of such id's being used with role=main and as the target form 'skip to main content' links. i.e as a useful semantic identifier. 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. The data strongly suggests that there is a section of the page that can be identfied as the main content area, which tends to be unambiguously recognisable. It should be noted that while I provide the links to the source for the data I provided. there is no such provision in the data you cite from 2005 from which you based the inclusion of various structural elements. regards SteveF On 18 October 2012 20:36, Ian Hickson i...@hixie.ch 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. In the case of maincontent, there is no problem to be solved, and there is no use case that isn't already adequately handled by HTML. Naturally, anyone is welcome to make proposals and discuss use cases, but I would encourage people participating on this mailing list to focus first on establishing use cases, to avoid returning to topics that have previously been discussed without adding new information, and to avoid discussing
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
On Fri, 19 Oct 2012, Steve Faulkner wrote: 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. There's a number of use cases, and I don't recall which we were looking at specifically at the time (it was many years ago), but off the top of my head: being able to jump straight to the main content of the page, being able to jump to the page's navigation, being able to style the header and footer specifically, being able to move sections up and down the outline (e.g. turn a sub-section into a sub-sub-section) without having to update the markup (e.g. h4 to h5), being able to mark parts of the page as being non-critical (e.g. in the spec, a note or example), etc. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] maincontent element spec updated and supporting data provided
On Thu, Oct 18, 2012 at 11:36 AM, Ian Hickson i...@hixie.ch 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. I thought the requirement was that it got adoption by implementations? In the case of maincontent, there is no problem to be solved, and there is no use case that isn't already adequately handled by HTML. I believe there are different opinions about this. I don't have a strong opinion myself, but I don't believe the case is as clear-cut as the above sentence makes it sound. Naturally, anyone is welcome to make proposals and discuss use cases, but I would encourage people participating on this mailing list to focus first on establishing use cases, to avoid returning to topics that have previously been discussed without adding new information, and to avoid discussing minutiae of proposals before firmly establishing that there are solid use cases. Agreed. / Jonas
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 -
Re: [whatwg] maincontent element spec updated and supporting data provided
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
[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] maincontent element spec updated and supporting data provided
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 - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
