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 <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.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 18 October 2012 18:41:06 UTC