[whatwg] maincontent element spec updated and supporting data provided

Thu Oct 18 15:19:43 PDT 2012

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 <div>s 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 <div>s 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 <article>s
> in their own right, and uses <div id="main" as part of a cascade of <div>s
> 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 <div>s 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 <ian at 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 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 <div>s 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 <div>s 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 <article>s
> in their own right, and uses <div id="main" as part of a cascade of <div>s
> 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 <div>s 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>