[whatwg] maincontent element spec updated and supporting data provided
Ian Hickson
ian at hixie.ch
Thu Oct 18 11:36:52 PDT 2012
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list