Consider aligning WHATWG main element definition with W3C definition #100

Open
stevefaulkner opened this Issue Sep 4, 2015 · 138 comments

Projects

None yet
@stevefaulkner
Contributor

The main element was designed and implemented based on the concept of there being a single instance within a document, the markup pattern was based on data of id value usage in the wild. The whatwg definition differs markedly from the orginal definition. This leads to confusion for developers.
The W3C nu html checker, which is used by many, throws an error when main is used as per whatwg. Data derived from webdevdata.org shows that >97% of usage of the <main> element is as per the W3C definition and anecdata from users that consume the semantics suggests that one main element per page is the expected and most useful pattern. In general consumers landmark semantics report that the utility of landmarks is reduced as the number/instances of landmark elements in a document increases.
The alignment would involve changes to the main and body element definitions.
current W3C definitions:

@foolip
Member
foolip commented Sep 4, 2015

@Hixie, do you have a summary handy for why the definition is as it is? I remember lots of emails on the topic, so perhaps there's something in the archives.

@Hixie
Member
Hixie commented Sep 4, 2015

From my perspective, the implementors added support for parsing a "main" tag. I came up with something that it could make sense for. Ideally it wouldn't exist at all, but since it was already implemented, it was cheap to add the semantics for it.

The element as specced over in W3C land makes little sense when you think about it.

I doubt the 97% number, as I suspect it categorises a bunch of cases that are "WHATWG-like" as "W3C-like". For example, if a blog uses <main> around the body of each blog post <article>, and has 200 posts (one <main> each) plus six months of archives (one <main> per post in the month), then you'd have 200 pages that appear to be "W3C-like" and 6 pages that appear to be "WHATWG-like", which would give you the 97%, despite the reality of that site being that it uses it in a "WHATWG-like" fashion uniformly.

@domenic
Member
domenic commented Sep 4, 2015

I think the more important deviation is how authoring affects accessibility. @stevefaulkner, my understanding is that accessibility tech relies on one main per document, is that right? Can you give some more details on:

  • What UI accessibility tech presents for listing or navigating related to main?
  • What happens if you specify more than one main per page?
  • Anything else you can think of that us people-who-don't-often-use-screen-readers might need to know?

I guess we really should be testing these sorts of things ourselves too instead of just relying on @stevefaulkner... Is there a good document for how to do such tests, preferably without buying any commercial software?

@Heydon
Heydon commented Sep 4, 2015

The element as specced over in W3C land makes little sense when you think about it.

@Hixie You don't back this statement up, so I'm not sure what you mean?

@domenic I recommend installing the free screen reader NVDA and testing with Firefox. NVDA provides interfaces for navigating by landmark, including main. A list of landmarks in the page are accessible by pressing INSERT+F7 (where heading and links are also listed). In addition, you can navigate by landmark by using "D" for the next landmark (including main) and SHIFT + D for the previous landmark.

JAWS and VoiceOver have similar interfaces.

@domenic
Member
domenic commented Sep 4, 2015

OK. I will try to find free time to do that and experiment with the accessibility consequences of WHATWG-main vs. W3C-main usage. In the meantime, I welcome others to give their report on such things based on their own testing, as I (and the other editors) can more easily find time to respond to such reports than we can install software and do testing :)

@sinabahram

As a screen reader user, the w3c definition aligns with my expectations pretty nicely. There should be one main per page. For moving between other pieces of content, there's headings, article, etc.

This also seems to be the interpretation that jaws has taken as well, given that their keystroke modification to list all elements of type "x", where "x" is main, defaults to block quote instead of main. The reason for this is that they repurposed 'q' in the virtual cursor to move to the main element, and with their model, whenever you modify a shortcut key, such as 'q' or 'a' for radio buttons or 'h' for headings, with JawsKey+ctrl, you get the list of elements of that type. So for example, JawsKey+ctrl+a lists all radio buttons. However, JawsKey+ctrl+q lists all block quotes instead of all main elements, which is what would be mapped if they expected there to ever be more than one.

I don't wish to imply that an AT's interpretation should receive all that much import over figuring out the "right semantics", but it is contributory to at least figuring out where other folks' heads are at with this element.

Also, anecdotally, I've found better success jumping to main, whenever it is available, than jumping to an h1, which so often is abused and used incorrectly.

@stevefaulkner
Contributor

From a quick partial grep of the latest webdevdata files (jan 2015)
20,000 pages
218 with


215 with 1 instance
2 with 5 instances (unsure whether these would be considered whatwg like usage: when i checked 1 http://www.studiocalico.com/ no longer has multiple main elements, the other no longer has any main elements http://www.sympatico.ca/
1 with 2 instances (which appears to be author error as has same id) https://payproglobal.com/

@domenic
Member
domenic commented Sep 4, 2015

I don't wish to imply that an AT's interpretation should receive all that much import over figuring out the "right semantics", but it is contributory to at least figuring out where other folks' heads are at with this element.

On the contrary, I think this is probably the most important indicator of the right semantics. I am just one editor, and this perspective might not be shared by the others, but it's the one I try to argue for.

Thanks very much for this info. Since JAWS is expensive, your report is especially valuable, since fewer of us can test it. Much appreciated.

@bramd
bramd commented Sep 4, 2015

As a screen reader user I also don't expect more than one main element on a page. If it is used on a web page I find it a very useful landmark to navigate to. As @sinabahram said as well, ithink that there are enough methods available to properly mark up multiple blocks of content on a page (article etc).

The blog archive example that has been named earlier in this thread would actually cause me to think I landed on a single article page after jumping to the first main element and landing at the start of a blog post.

@annevk
Member
annevk commented Sep 4, 2015

@sinabahram @bramd it's not really clear from your comments how screen readers deal with multiple <main> elements and why that is a bad experience. If that is something you could try out and report on that would be appreciated.

@sinabahram

I’m a bit confused by this. are we wanting to determine if multiple mains breaks something or whether or not it makes sense?

There are three possibilities to be enumerated based on first principles.

(1), multiple mains doesn’t make sense

We’ve covered this one, I feel.

(2): Multiple mains does make sense and screen readers do not handle it correctly (there’s an entire rabbit hole with browser accessibility APIs, AT expectations, etc., but the results can easily be paper prototyped as follows)

A. Multiple mains exist on a page

B. The screen reader key to navigate to main navigates between them, just like it does with radio buttons, form fields, regular buttons, edit fields, headings, links, paragraphs, etc.

C. We end up discussing/debating things with AT folks like “list all mains on the page”, etc. etc.

(3): Multiple mains does make sense and screen readers handle it correctly.

Then there’s probably less to discuss, although even if this were to be true, we could still debate the points A through C from (2) a bit.

So before we even begin discussing those issues like how the AT handles it, etc., can you help clear up my confusion on whether we are even interested in those mechanics before establishing whether multiple mains does make sense?

I’m simply trying to apply short circuit evaluation to the logic of this discussion so as not to waste time going through specifics of (2) and (3) if we don’t need to, or to ask why the specifics of (2) and (3) would affect their leading point, which is to state that multiple mains does make sense.

I hope that makes sense.

@domenic
Member
domenic commented Sep 4, 2015

My perspective is that multiple mains do make sense. I've used them in a few large apps before (internal mostly, for finance firms), and the spec documents how to do so. As such, I like the current spec.

However, if such usage of mains is causing problems for users of accessibility technology, then we need to reconsider.

So basically: (1) is false (I know some people love to debate this, but from the perspective of the current spec and at least a couple of its editors, that's the case). (2) would mean we should change the spec. (3) would mean we probably shouldn't change the spec, depending on what "correctly" means. Although even if it's (3), there have been some comments about screen reader user expectations on this thread that might change things.

@stevefaulkner
Contributor

(I know some people love to debate this, but from the perspective of the current spec and at least a couple of its editors, that's the case)

What would be helpful is for the spec editors to provide some data and detailed reasoning to back up their perspective, otherwise it sounds like argument from authority.
How does multiple main elements benefit the users who consume the semantics?
What cowpaths are being paved by the WHATWG definition of main?
When researching and developing the main element I provided data and reasoning about why it was specced as a singular instance element, I have never seen any data or substantive reasoning for the conflicting whatwg definition.

@CuriousNetEntity

I am a screen reader user and I really do not want more than one Main landmark on any webpage. I tested to make sure my screen readers didn't malfunction in any way when I put 2 mains on a page, but it just isn't user-friendly. In all the cases I can imagine, it would be better to stick with one main and have multiple article tags. Besides screen reader usage, consider a definition of the word. Main: "Of chief or principal importance." Having more than one main landmark on a webpage makes no more sense than having more than one main street in a city.

@LJWatson
LJWatson commented Sep 7, 2015

Multiple instances of main do not break current screen reader support. Those that provide a mechanism for cycling between all landmarks include multiple instances of main in the cycle. Those that provide a shortcut specifically for the main landmark treat it as cyclical if there are multiple main elements on the page.

The model for landmark navigation is based on the same model that screen readers have been using for all element types since the early 00s. In other words, the fact it works with multiple main landmarks is not by specific design, but by dint of the fact that's how element based navigation has always worked in screen readers.

The issue isn't one of AT support though, it's the usability of the thing that's important.

The definition of "main" is generally accepted as something that is predominant. Dictionary.com defines "main" as "chief in size, extent or importance; principal; leading". Linguistically we tend to use "main" and its synonyms in the singular - the main road, the principal designer, the chief problem, the main force etc.

If we agree to meet "by the main entrance to the building", that's pretty clear. It's probably those big doors at the front of the building, possibly leading out onto a/the main street. It's the same with the main element. When we say/hear the "main content" or "main region" of a page, the expectation is that it'll be that predominant chunk of content.

So the user expectation is that there will only be a single main area on a page. From the stats @stevefaulkner has shared, it seems that developers are working on the same expectation too. Speaking as both screen reader user and developer, a single main element seems like the sensible thing to me.

@DavidMacDonald

If I tell my friend to meet me at the main entrance of the hotel, we both know where to meet. There is only one. It is a clear distinguishable important landmark. I teach web developers to use only one Main element on page.

@Hixie
Member
Hixie commented Sep 8, 2015

There's only one main entrance to a hotel, which is fine, if the page is a single-article (single-hotel) page. but what if the page is a multi-article page (a street of hotels?). Then there's many main entrances.

@stevefaulkner
Contributor

@hixie difference bewteen the 2 is that whatwg definition is at odds with user needs and is without any data to back up its definition.

@karlgroves

@Hixie says "a street of hotels?"

You answered the question yourself, then. It would be a <main> of <section> s

@MarcoZehe

@Hixie think of it this way: An archive page is a collection of articles, but there is still only one main area of focus. There may be side bars, other navigation mechanisms etc., but there is one main area of a page that, coincidentally, might host more than one article, or just one article. To bring up an analog analogy: A printed book has one main section, it may have one table of contents, it may have a glossary or something other. But it will have one main section that consists of one or more chapters. These might again be divided into sub sections etc. But what you will not find is a book that has more than one table of contents strewn about throughout the book, or more than one glossary or even more than one cover page. There may be several complementary items in a book, like said glossary, like an author index, and others, but you will only find one main element in a book, not several. If there were several, these should be separate volumes.

The same is true for any web page, be it a single article on a blog, or a collection of articles because we might be dealing with an archive page. There is only one main area that contains such archive articles, not several.

This is my expectation of web pages. This is how I navigate as a screen reader user. This is what makes sense to me when I deal with the wilderness the web is. I support aligning the WHATWG spec with the W3C one because of exactly this reason.

@BimEgan
BimEgan commented Sep 9, 2015

Having multiple main regions on a page seems illogical. It can also cause real confusion for people who can't see the screen. Screen readers often start to read the page as soon as it has loaded and if the site is visited frequently, some of them can also bypass content at the top of the page that is recognised as being repeated on other pages.

To help users understand where they are on the page, as @sinabahram said in a previous comment, JAWS provides a single key shortcut "Q" to take users to the main content region. If the screen reader has already reached or passed the start of the first of multiple main regions, pressing the "q" key will take the user to the second one. If there is only one main region then the same keystroke will take users back to where the main content starts.

So multiple main elements could mean that screen reader users can't be really sure where they are on the page and may miss the most recent article (at the beginning of main content) without knowing that they've done so.

As a screen reader user, My vote is for just one main element to enclose the content that is unique to the page. It can contain many article elements, but in these days where websites frequently use multiple h1 headings, there really needs to be one reliable way for blind people to find out where the good stuff actually starts.

@domenic
Member
domenic commented Sep 9, 2015

Just a warning that re-treading old arguments is not likely to change anything. The new information about screen readers is useful but telling us how you feel about the English definition of the word main, or similar things, is not useful.

So far the only actually new content gained in this thread can be boiled down to two sentences:

  • JAWS does not provide an appropriate shortcut key for multiple main elements in the same way it supports multiple other elements. However, it does allow you to progress through multiple main elements in sequence.
  • @LjWatson's screen reader(s) do not have any problem with multiple mains.

Everything else so far in this thread has been a rehash or a statement of personal preference, and is in danger of obscuring the issue.

@stevefaulkner
Contributor

@domenic I thought the utility of a features use to people who consume the semantics (i.e. actual screen reader users) and how developers use the element would be useful data points?

a statement of personal preference

appears to be the only reasoning offered by the editors currently and historically.

@domenic
Member
domenic commented Sep 9, 2015

Those data points have been amply made in previous discussions that led us to where we are today. Repeating them is not helpful.

@stevefaulkner
Contributor

@domenic OK, are we to expect some reasoning and data from the editors on why their personal preference is better for users?

@domenic
Member
domenic commented Sep 9, 2015

Again, I would really encourage you to read previous threads on this matter. I would appreciate if nobody replied to this thread unless they have new information, not questions about old information.

If you want to continue old debates, those are best done on old threads.

@stevefaulkner
Contributor

Again, I would really encourage you to read previous threads on this matter.

That is my point, there was never any reasons or data provided in the first place despite it being asked for, I was involved in all the orginal discussions.

@karlgroves

If you want to continue old debates, those are best done on old threads.

Thank you for this information. Can you please cite the thread where the data that @stevefaulkner is asking about has been provided?

@stevefaulkner
Contributor

@karlgroves
In February 2013 as part of main discussion on the WHATWG list I wrote:

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.

https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0172.html
There was no reply.

@stevefaulkner
Contributor

New info:
2013 Ian Hickson wrote:

When it comes to conformance requirements, the reality that is most
important to follow is usage

https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0103.html

5 days ago I wrote:

From a quick partial grep of the latest webdevdata files (jan 2015)
20,000 pages
218 with
215 with 1 instance

#100 (comment)

@bkardell

Ok, I'm taking no position here - simply asking a question and I'm doing it here simply because I don't have a "better" place to ask it conveniently. Feel free to redirect me. The situation as I see it: @stevefaulkner is providing usage data, @Hixie says he finds the data suspect. If we could imagine for a moment that the data was somehow "agreeably correct to all parties," my question is: Would it change things substantially? In some sense, the way authors use "words" is far more important than the committee/editor intended meaning. If we created, for example,

and found that no one used it as spec'ed but overwhelmingly they used it in a pretty consistent fashion where it was clear what they "meant" and it didn't break anything, it seems kind of logical to think about changing the spec to match the "real world meaning" - would we? Here it is a little less clear cut perhaps, but the question remains: If the data was not (hypothetically) suspect, would @Hixie or anyone else have something like a change of heart? why or why not?

@Hixie
Member
Hixie commented Sep 18, 2015

@stevefaulkner The reply was here:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0173.html

@bkardell The data I suspected was the data described in the first comment, which it turns out indeed isn't supported by the data @stevefaulkner has since posted. Just having one element in the document doesn't say which meaning is being used. Both meanings support being used only once per page. Plus 218 instances isn't close to enough to draw any conclusions other than "maybe we should drop the element entirely".

Fundamentally, though, the problem with using data here is since one model is a subset of the other there's no way to use data to say that the subset is the one being used. You could show that people aren't using the subset to some degree (around 3%, according to the numbers in the first post above -- note that we have kept features in for usage as low as 0.03% before), but not the other way around.

This whole conversation is a bit silly though. There's no harm with the way the WHATWG spec defines <main> (in particular ATs seem to support multiple elements fine), there's distinct advantages (e.g. it makes it trivial to have a single string describing an article, while still supporting using that string in pages with multiple articles), the spec as written makes fine sense (there's no internal contradictions or the like), and the WHATWG model supports authors who want to use the other model fine. The whole element is largely pointless anyway, so it's hard to get really worked up about it...

@sinabahram

With due respect, this is a truly ignorant statement:

“The whole element is largely pointless anyway, so it's hard to get really worked up about it...”

I consume information at 1,000 words per minute, and am fluent in over a dozen programming languages, but all of that does not obviate the utter misery of tabbing over 40 to 100 elements just to get at the damn content of a particular page so I can achieve a simple goal like reading a news story, answering a development-related question, arriving at the content of a blog, targeting the main content of a doctor’s office, etc.

I can get plenty worked up about it and based upon actual evidence, not just opinion. You have more examples here from screen reader users, than I’d argue on most other similar threads, which if you accept any form of statistical framework, implies rather strongly that many share such assumptions.

Simply dismissing an element that saves some of us, quite literally, hours per week of wasted time dealing with useless crap, is ignorant.

The good thing about ignorance is that it is resolvable with evidence. You’ve been presented with such. the good thing about ignorance is that it is addressable with arguments rooted in first principles. You’ve been presented with such, again.

You can definitely disagree with those things, and I welcome such debate, but dismissing this as pointless, is frankly moronic and completely clueless for someone in your position that knows the significant order of magnitude time savings such a simple element can provide an entire class of user.

So, shall we return to an evidence-based and logical discussion, or do we need to actually continue this debate within the completely unproductive domain of emotionally charged words such as “pointless”?

@Hixie
Member
Hixie commented Sep 18, 2015

It's pointless because HTML provides sufficient information to do everything you need to skip to the main content without it. It's just that the ATs haven't implemented that well enough. The element is a workaround for poor AT implementations.

@sinabahram

I disagree with that, as do many others.

An h1 was thought to be sufficient, and from a decade of experience, we know it’s not.

Multiple mains are going to cause templates containing multiple of them and other incorrect uses to validate, and this will simply perpetuate the problem.

I still have not heard a single good example on this thread for where multiple mains are useful to AT users. I single out AT users, because frankly, other users have means such as section/article/etc. to indicate such repeated content visually.

@Hixie
Member
Hixie commented Sep 18, 2015

<h1> isn't what I'm talking about. I'm talking about <aside>, <section>, <article>, <footer>, <header>, etc. It's straight-forward to wrap anything that isn't main content in the various "non-main" elements we have, and ATs could implement that to have the same effect as <main>. (Actually a better effect, really.) But whatever.

@sinabahram

I don’t agree. To that end, please provide an example of where Aside, Article, section, and footer are used in such a way to easily identify the main content. Furthermore, then provide some proof that this is done more often than not by web developers. not only do AT not facilitate this. web developers do not facilitate this.

@Hixie
Member
Hixie commented Sep 18, 2015

Most developers don't use <main> either.

@sinabahram

That’s not in any way productive. In fact, it’s all the more reason to define the semantics correctly. Developers do use article and section and such, and these do not lend themselves to identifying the main content of the page.

@bkardell

All, It wasn't my intent to open a can of worms here with the question - I've really no position on this particular issue at this time because I can see both ends of it to an extent... Just to sum up though so I'm sure I understand... @Hixie, I take your point that you're arguing that it's largely irrelevant to the important questions of accessibility/parsing/etc/etc here whether >1 are a validation error, so the point of data is somewhat moot - but on the whole, I'm still curious: If we could agree on good data that somehow showed what it is that @stevefaulkner was originally saying his data was showing, should we update the WHATWG spec (in your opinion)? In other words - does the data matter at all in this case in your estimation? I'm really not asking this to paint you into saying something that sounds like "damn the data, I do what I want," I'm genuinely curious about how can can hope to (maybe not in this specific case, but others) use data, (or not, and why) to retroactively shape the meaning/recs around an element.

@Hixie
Member
Hixie commented Sep 18, 2015

@sinabahram I don't see what you mean. They are literally designed specifically for that purpose.

@bkardell Data is the best way to make decisions, generally, so yes. If there was data showing, for example, that pretty much all authors wanted to only use <main> once but kept accidentally using it multiple times, and that doing so made the user experience worse, and that were validators to complain about it they would catch this mistake and fix it, then yes, I'd want to change it.

This kind of thing is very hard to measure, though. Getting useful data in volumes large enough to be meaningful is very hard. (Surveying a few hundred authors is unlikely to give good results unless the selection of authors was truly random across the entire range of authors, for instance.)

FWIW, the data we do have shows that ATs work fine with multiple <main>, and that some authors, though not many, use it. So...

Generally speaking, you can use data to guide element design. For example, if you survey a large enough portion of the trillions of Web pages (by large enough, I mean in the billions, so you're getting at least a percentage point or so of the Web, ideally distributed widely across cultures, languages, subject domains, etc) then you can look at common class names to determine what kind of semantic is missing from the language. It's hard to do more fine-grained things like tweaking element semantics, though, since that generally requires semantic understanding of the data set, which is very hard to do at any sort of reasonable scale.

Also unfortunately the portion of authors who write poor-quality markup (in terms of using semantics) is so high that most sufficiently-randomly-selected data sets would just lead one to conclude that trying to expose semantics is a waste of time. :-( (And non-randomly-selected data sets are near-worthless because they're not representative.)

@Heydon
Heydon commented Sep 18, 2015

@Hixie Are you really saying that a lack of <main> can actually work? That developers can be expected to uniformly wrap all content that isn't main content in <header>, <footer>, <section> and <aside>? It's so absurd it seems disingenuous. Not least because <section> (for example) could sensibly be used within main content to denote subsections. What then?

I'm also a bit baffled by your disregard for the data. You seem to be saying "instances of 1 <main> are inconclusive evidence because people might have used more than 1, even though they didn't". Any guesses about intention on the part of the developer cannot be considered evidence.

@stevefaulkner Any data on how many people use <aside> versus <main>?

@frex65
frex65 commented Sep 18, 2015

I'm curious here about what mechanism is being proposed for flagging up unique page content to AT users. The <main> element would seem like the perfect candidate to me. If I understand @Hixie's proposition, AT should regard anything that's in the document body, outside any <header>, <footer> etc. elements, as main content. But this feels like quite a hit and miss approach to me, prone to all sorts of error. Unless I'm misunderstanding the function of the <main> element, it was created specifically to wrap the main/unique content on a page. So why would it be necessary to use multiple instances of <main> inside <section> and <article> elements?
As an AT user, all I want is to be able to press a key (probably an AT shortcut key) and be taken straight to the first line of unique content on the page.

@MichielBijl

I too am interested in a demo of the proposed technique to determine the unique page content without the <main>-element.

@DavidMacDonald

687474703a2f2f6a756e6b796172642e64616d6f776d6f772e636f6d2f353230

I think I would name this 'main' street, with three 'article' entrances

@jameswillweb

To me it seems obvious that there is harm in allowing more than one <main> element per page. Multiple <main> elements would suggest that all are equal in terms of importance, as there’s no mechanism that suggests any type of hierarchy among them. How then, are AT or other user agents supposed to present them to the user? In the order they’re encountered? If that’s the case we have existing semantic tags such as <article> and <section> that do the same thing. I’d submit that the definition of the <article> and <section> tags are sufficiently vague as to confuse most authors currently. Adding another element to the mix with roughly the same semantic value muddies the water with no significant benefit. The <main> element should exist to identify unique content that is the focus of the page or it shouldn’t exist at all. Given the fact that there is no demonstrable mechanism currently for identifying main page content I’d say the case for it is strong.

Honestly reading through all the threads it seems like the WHATWG’s position can be summed up as “because we said so” with little to no evidence to back it up.

@Hixie
Member
Hixie commented Sep 18, 2015

The DOM is the hierarchy. It gives most order and depth. We use the same hierarchy for everything else in HTML.

@sinabahram

I have a question. is there an actionable outcome goal for this discussion?

Is something going to be decided or are we just gathering opinions and evidence?

@Hixie
Member
Hixie commented Sep 18, 2015

No new information has been provided since 2013, so the current decision stands. If new information comes to light, we would of course give it its due consideration.

@Hixie
Member
Hixie commented Sep 18, 2015

@frex65 said "As an AT user, all I want is to be able to press a key (probably an AT shortcut key) and be taken straight to the first line of unique content on the page."

That's exactly what you get right now, right?

@sinabahram

What form would such new information take?

It is unclear to most of us what the necessary and sufficient criteria are for changing this decision.

@Hixie
Member
Hixie commented Sep 18, 2015

It's unclear to me why you would want to change the decision. What's wrong with what the spec says?

@Heydon
Heydon commented Sep 18, 2015

@Hixie Here's a question: what would be so bad about changing the spec to say that only one <main> per page is advised? We've heard from numerous people on this thread who benefit from it being one <main> only and from nobody who'd prefer it as multiple <main>s. Let's just change the advice and save ourselves a lifetime of aimless quibbling.

@domenic
Member
domenic commented Sep 18, 2015

from nobody who'd prefer it as multiple

s.

This is false.

@Hixie
Member
Hixie commented Sep 18, 2015

I've explained several times on this thread the advantages of the current design. Losing those advantages is what would be "so bad". But what would be "so bad" about keeping the current spec? As far as I can tell, it supports everything that the one-main-only model supports, including in particular the most important feature, namely, jumping to the first piece of main content in an AT environment.

@marcysutton

Parts of this conversation sound a lot more about the opinions of spec writers than those of actual users (namely AT users, who stand to actually benefit from this element). People are telling you directly what they want and expect. Those messages are worth a lot more than you're giving them credit for.

@karlgroves

@Hixie says: "including in particular the most important feature, namely, jumping to the first piece of main content in an AT environment."

From this, it appears that you acknowledge the actual use case for this element, yet you dig your heels in when the actual users that this benefits tell you that > 1 main element is a bad idea.

In fact, there's really only one user population that benefits from this element and that's users of AT. What more data do you need than the voices of these users?

The arrogance displayed in acting as though you know more about what they need than they do is actually comical.

@Hixie
Member
Hixie commented Sep 18, 2015

It's not the only population that benefits from the element. Authors also benefit from it, for styling purposes.

But that's besides the point. People can make claims all they like, what matters is whether those claims are backed up. So far nobody has actually explained a problem with allowing authors to have multiple parts of the page marked with <main>. Indeed, it seems based on the descriptions of AT behaviour that ATs handle that fine. (Even if they just ignored all but the first, it's hard to see where the harm would be -- it would be just like allowing one, and then saying all the others are nothing but styling hooks.)

Let me ask a different question which maybe would help. Suppose we required that there only be one <main> per page. What do you think ATs should do with the second <main> in a page? What should ATs do with the <main>s found in seamless iframes?

@karlgroves

Authors also benefit from it, for styling purposes.

That's a useless red herring. God forbid they'd have to learn WTH they're doing and choose another element. There's no styling benefit from <main> over any other element that has a flow content model like, I dunno, <div>.

So far nobody has actually explained a problem with allowing authors to have multiple parts of the page marked with <main>.

I'm pretty sure that's not true, but I'll entertain you anyway. <main>, as a sectioning element, is mapped in accessibility APIs to "grouping" roles - for instance, 'ROLE_SYSTEM_GROUPING' in MSAA + UIAExpress (See http://rawgit.com/w3c/html-api-map/master/index.html#el-1)

This is why assistive technologies treat <main>, <nav>, etc. as navigable landmarks. It bears mentioning that all accessibility APIs use similar mappings for <main>. In other words there is (ostensibly), consistency across platforms.

What's wrong with > 1 main? Predictability. With each additional <main> the usefulness of the element decreases. More mains === more problems. We saw this with the <section> element, in fact. When HTML5 started gaining popularity, web developers thought "Oh, I'll just replace my <div>s with <sections>!!! I HAZ HTMLFIVED MY WORKZ!!!!11" and where we used to see pages composed of <div>s nested 27 deep, they became <sections> nested 27 deep.

Ultimately, AT vendors do what AT vendors frequently have to do, they compensated for developer idiocy by no longer announcing the <sections>

Back to the case of <main>, whether you want to admit it or not, the meaning of the word "main" is clear. While I feel comfortable calling you arrogant, I'll never call you stupid. You know what "main" means and I know you know what it means. There should be one. When there is > 1 its utility is diminished each time a new <main> is introduced. Have too many and it goes from being useless to being confusing mess, just like <section>

@Hixie
Member
Hixie commented Sep 18, 2015

I don't understand how the utility of <main> is diminished if there's more than one. The utility is "jump to the main content". So long as ATs jump to the first main, then the author can put in a million of them and it won't make any difference.

The advantage comes from the fact that if their page mixes "main" content and "boring" content, then they can mark up all the disjoint parts that are "main" so the user can easily jump between them. If ATs start ignoring the other mains and only allow jumping to the first one, then... nothing is lost if you only even wanted to honour one anyway. I really don't see the problem.

BTW, relying on authors to get any of this right is a lost cause, whatever we say in the conformance rules. Conformance rules are only relevant to the few authors who care about conformance. Implementations, including ATs, have to deal with the real world regardless. Case in point, <section> was never allowed to be used in place of <div>, yet q.v. what you described.

@karlgroves

I really don't see the problem.

Of course not, which is why you've consistently been on the wrong side of accessibility since the very beginning.

OK, so you have 1 main: 1 main is easy. It should be the single area where the main content is.

What about 2? Well other than the fact that > 1 main means neither one is actually "main" now the user doesn't know which is which. But lets give the benefit of the doubt and say there could be an extreme edge case for two main areas: Which is which? Which main represents what stuff? Well, we could use aria-label or aria-labelledby to label each one. Differentiating between two is pretty low cognitive load.

3? Well three is just stupid because now things are getting out of hand. No rational person would think there could be 3 "main" parts of the page. But let's keep going with the labeling. No matter what you say from 3 and up, the "Principle of Least Astonishment" is irreparably broken in this interface. Now the multiple mains are working against the user. Because a screen reader user has no visually-oriented cognitive model of the page, they're faced with guessing which is actually the "main" of all the "mains"

So long as ATs jump to the first main, then the author can put in a million of them and it won't make any difference.

Come on. You're smarter than that. Any time an AT has to guess what's going on, you're introducing a lack of reliability. For years AT vendors have had to resort to this sort of thing and it rarely works out as planned. Since we're tossing out red herrings: What if I replaced all my <div> elements with <main> elements?

BTW, relying on authors to get any of this right is a lost cause,

Now that is hilarious. See, I remember having this exact argument with you back in 2006, when (at the time) you wanted to strip out the @scope attribute from TH, among other things (like making @alt optional).

You can't have it both ways. You can't say we must get rid of feature x because authors get it wrong, but keep feature y the way it is because they get it wrong. What is obvious in this case is that saying "multiple mains are a bad idea but you can still do it" is far less clear than "main: use one and only one, always"

Again, you have actual constituents for this feature telling you that > 1 main is bad and you refuse to admit you're wrong.

@domenic
Member
domenic commented Sep 19, 2015

Karl, please do not resort to as hominem attacks on this issue tracker.

Can you explain in more detail, with examples from real ATs, the harm caused be more than one main? You say it rarely works out as planned, in which case such an example should be easy to produce.

@karlgroves

Can you explain in more detail, with examples from real ATs,...

Oh, this isn't my first dance. I've played that game before. I stopped playing it years ago, back when WHATWG and W3C tried playing nice with each other.

The cycle usually goes like this:
"We want to do this thing"
"You shouldn't do that thing"
"We're gonna do that thing unless you give us some data to prove we shouldn't do the thing"
"Here's the data. See, it shows you shouldn't do the thing"
"We're doing the thing anyway because of [fallacious logic]"
"But we gave you data."
"We're doing the thing. We found data that shows we're actually right"
"Where's your data?"
"This is proprietary data, we can't/ won't/ don't need to show you."
"But we gave you open data, you can verify for yourself that our data is legit."
"We don't like your data. We're doing the thing anyway. Here, smell this red herring. But hey, if you have more data, please share it. "

Here's the only data you need:

  1. The word "main" is semantically clear. I know it, you know it, and everyone else knows it.
  2. The "main" element's primary constituents are AT users.
  3. A half-dozen of those constituents have said in no-uncertain terms that they want one-and-only-one "main" element.
  4. Another half-dozen accessibility consultants - people who deal with AT users on a daily basis - say that there should be one-and-only-one "main" element.

Please, by all means, continue to argue that you know better despite your clear lack of perspective, knowledge, or experience in dealing with the primary constituents for this feature.

@bkardell

Let me reiterate that I am taking no position here, but as a somewhat neutral observer I think it is worth mentioning that @Hixie asked what seems, to me anyway, as a pretty rational question:

Let me ask a different question which maybe would help. Suppose we required that there only be one <main> per page. What do you think ATs should do with the second <main> in a page? What should ATs do with the <main>s found in seamless iframes?

and I don't see anyone offering an answer to that. We know for a fact this will happen, it happens with everything, even <html> and <head> etc -- and it's not just authors -- CMS' and mashups especially frequently help create some pretty horrific things. I'm asking because, I could be wrong about this, but it seems to me at the heart of @Hixie's objection. Everything we have like this is set up for multiples - id doesn't identify uniqueness in practice, it's the first one in the document if you get it with getElementById or querySelector, for/describedby/etc all have to take these same things into account. I think what Hixie is saying is that AT could do the same with <main> now if the a11y community thought that was the right thing to do, but apparently they don't. This too though seems a bit double-edged - if the a11y community convinced ATs that they should treat the first <main> specially, would this sway you at all @Hixie or would that really accomplish nothing because the AT is dealing with it, as you said. This said, ID is defined as a "unique identifier" in the WHATWG standard, even though it doesn't actually work that way for reasons above and I think that all the a11y people here are saying is that they want the same kind of advice/description consideration here.

@karlgroves

I don't think anyone's advocating for breaking the Web. One of the best features of the Web is that user agents are particularly adept at dealing with horrible markup.

The request is, quite simply, to become aligned with the W3C specification of <main>
http://www.w3.org/TR/html51/semantics.html#the-main-element

@jameswillweb

It seems to me that it would be pretty simple to write error-handling for those edge cases without breaking anything. In the case of nested <main> elements you could give primacy to the one closest to the root, in the case of sequential you could recognize the first element as the "main" element and treat all other instances as generic content groupings. Karl is correct, it's an issue of semantics not that authors may incorrectly implement it. "Main" has really only one possible semantic meaning, if we ignore that because of the possibility that multiples could be used in error than what's the point of adding semantics to specifications at all?

@Hixie
Member
Hixie commented Sep 19, 2015

Consider a page like the following:

[boilerplate text]
main content
[advertisement]
main content
[sidebar]
main content
[footer]

What would you wrap in the <main> element?

For an example of such a page, just go to cnn.com, and follow the link to the main story. It's a blob of content, the main article, with inline sidebars all the way along.

The word "main" is semantically clear. I know it, you know it, and everyone else knows it.

Right. It means the main content. But the main content can be dotted around the page. There's no one place on the page that has the main content.

The "main" element's primary constituents are AT users.

This just isn't true. The <main> element's definition doesn't have anything to do with ATs or AT users. It's like saying that <aside>'s main constituents are AT users. I mean, sure, it's a semantic element and semantic elements are eminently useful for being interpreted by non-mainstream renderers in a useful way, but that's the whole point of having semantic markup in general. It doesn't mean that HTML's main constituents are AT users.

A half-dozen of those constituents have said in no-uncertain terms that they want one-and-only-one "main" element.
Another half-dozen accessibility consultants - people who deal with AT users on a daily basis - say that there should be one-and-only-one "main" element.

The WHATWG does not base decisions on volume of agreement, nor does it base decisions on what any particular group of people think. Decisions are based on rational arguments, of which there have been remarkably few in this thread.

Well other than the fact that > 1 main means neither one is actually "main" now the user doesn't know which is which.

The user knows exactly which is which. The first one is the first one and the second is the second. I really don't understand what you're trying to say here.

Any time an AT has to guess what's going on, you're introducing a lack of reliability.

There's no guesswork here. There's just a list of places in the document that the author has marked as being important. This is exactly how ATs work today. There's no magic, no guesswork, no unreliability involved.

What if I replaced all my <div> elements with <main> elements?

Then navigating by <main> landmark would be no more useful than just reading the entire page. It's trivial for authors to make UA features useless. For example, what if the author sets the text colour to the same as the background colour? I really don't see what relevance this has to the argument.

Conformance rules, which as far as I understand is all we're talking about here, only matter to authors who are already a priori trying to do the right thing. So authors who would do such inane things aren't relevant to the discussion.

Again, you have actual constituents for this feature telling you that > 1 main is bad and you refuse to admit you're wrong.

Again, making assertions with no supporting evidence or reasoning is of no consequence here. If I were to say "all Web pages must have exactly three <main> elements", without explaining why, then my argument would be equally useless and thus we wouldn't update the spec.

The arguments that lead to the spec being the way it is are:

  • UAs already support multiple <main> elements in a usable and useful fashion, same as <div>.
  • ATs already support multiple <main> elements in a usable and useful fashion, according to AT users in this very thread who described the actual behaviour: it is treated as a normal landmark role, in document order. This is a mechanism with which AT users are presumably comfortable since it is used for the other landmark roles and general document navigation.
  • There are many scenarios (e.g. an article with inline sidebars and advertising, a blog post with multiple articles, etc) where there are multiple disjoint parts of the page that consist of its primary content.
  • Being able to style the primary content of a page or <article> is (mildly) useful. Since it can be disjoint, this requires multiple <main> elements. (This use case isn't enough to justify introducing an element, but since it's already implemented it's enough to justify specifying it as conforming.)
  • Being able to jump to primary content on a page or <article> is useful. This can be achieved in a variety of ways, e.g. by skipping headers and other content marked as non-primary using the semantic elements in HTML, but it can also be achieved by having an element (such as <main>, which happens to already be implemented for this purpose in ATs) that highlights the primary content. Since the primary content can be disjoint, this latter approach requires being able to use multiple <main> elements.
  • According to the ARIA spec and RFC2119, there may exist valid reasons in particular circumstances when it is acceptable or even useful for ARIA's "main" landmark role, on which <main> relies for its AT mapping, to be included in a document multiple times.
  • Since documents can be nested, ATs and UAs are in any case required to support the situation where multiple <main> elements can be nested.

The arguments against, as far as I can tell, are:

  • It's confusing to AT users. No particular backing for this claim has been presented, however. It's just been stated as fact. This seems to be contradicted by the descriptions of actual AT behaviour.
  • It's contrary to the meaning of "main". This is irrelevant, we have plenty of elements whose semantics bear little relationship to their name (e.g. <address>, <cite>, <b>). It's also debatable, as described above -- primary, or "main", content on a page can be disjoint.
  • Certain classes of people don't want this behaviour. This argument is an appeal to consensus, which is contrary to the documented WHATWG values, and therefore irrelevant.
  • Not many pages use multiple <main> elements. This is based on very sketchy data (less than 300 pages that use the element at all) and generally speaking isn't a reason to disallow a usage.
  • "What if people misuse <main> in a harmful fashion?" This applies to the element regardless of the conformance rules and therefore isn't a relevant argument.
  • "You (me, @Hixie) are personally against helping people with special accessibility needs." This is a patently absurd ad hominem contradicted by years of work, and, more to the point, is not an argument for or against anything to do with the spec.
  • "There should be only one element". This is an argument by assertion and therefore doesn't actually help make a decision. It might be true or it might be false, there's no way, from just that argument, to know.

Are some of the arguments I've presented wrong? Did I miss some arguments against? Please only add comments to this thread if either one of the arguments above is wrong, or if I missed some arguement. Please don't post just to repeat one of the arguments (for or against) that I've already presented in this comment.

@LJWatson

@Domenic

"Can you explain in more detail, with examples from real ATs, the harm caused be more than one main?"

AT handling isn't the important thing. It's the usability that's important.

ATs can handle multiple <main> elements. They can handle single <main> elements just as easily. If no additional <main> elements are present, the screen reader will announce something like "No further main regions".

The usability of multiple <main> elements is a different matter. It's what I tried to explain before… the concept of "main" is a singular thing to most people. Encountering multiple main regions on a page breaks this expectation, but where a sighted person may be able to differentiate them visually, there are no such cues available to screen reader users.

@LJWatson

@Hixie

"But that's besides the point. People can make claims all they like, what matters is whether those claims are backed up. So far nobody has actually explained a problem with allowing authors to have multiple parts of the page marked with <main>. Indeed, it seems based on the descriptions of AT behaviour that ATs handle that fine. (Even if they just ignored all but the first, it's hard to see where the harm would be -- it would be just like allowing one, and then saying all the others are nothing but styling hooks.)"

The harm is that content consumers for whom semantics are important expect "main" to be a singular thing. ATs can handle multiple <main> elements, but they can't differentiate *the main region from all the other main regions on the page. So a screen reader user has no mechanism to make the differentiation either.

"Let me ask a different question which maybe would help. Suppose we required that there only be one <main> per page. What do you think ATs should do with the second <main> in a page?"

They will do what they do when they encounter a single instance of any other accessibility supported element: they will indicate the presence of the first instance, and if the page is queried again they will inform the user that no further instances are available.

"What should ATs do with the <main>s found in seamless iframes?"

The same thing they would do if they encounter multiple <main> elements in the parent document. Again, this is not about the AT's capacity to handle multiple main regions, but the semantic usability of doing so.

@Heydon
Heydon commented Sep 19, 2015

@Hixie @domenic

I mean, sure, it's a semantic element and semantic elements are eminently useful for being interpreted by non-mainstream renderers in a useful way, but that's the whole point of having semantic markup in general. It doesn't mean that HTML's main constituents are AT users.

It's not the only population that benefits from the element. Authors also benefit from it, for styling purposes.

The benefit of <main>, and the purpose of any semantic HTML is so that it can be interpreted interoperably. I think we agree on that. Since differentiating elements merely for styling using, for instance, the class attribute is utterly trivial, can we not also agree that the importance of the existence of <main> as a styling hook is rather missing the point?

The element was conceived to fill a semantic hole, in order to assist a class of users who depend on interoperability to achieve actual tasks. Anything else is a side benefit or irrelevant frippery.

@stevefaulkner
Contributor

Preface: I am no longer posting to try to convince the whatwg editors to change their definition of main. The fact that we have two disparate definitions is annoying, but not overly problematic in practice as the whatwg definition is largely ignored by authors and therefore does not negatively effect users, neither is it implemented in the authoritative HTML conformance checking tool. The following is merely and attempt to provide information that may be helpful in understanding why main was defined as it is.

It has never been claimed by anyone anywhere that multiple mains break or cannot be handled by AT, so am glad we have cleared that up. The definition and restrictions on usage of main have always been about encouraging authors to use main as it was intended to be used in its orginal and current definition. The aim being to maximise the benefits for users (actual users not authors). However 'sketchy' the ONLY publicly available data indicates that the W3C defintion of main fits with authors understanding as well. There has been no evidence or opinion offered to indicate that multiple mains provide a more usable or understandable UI, all opinions offered here from users indicate the opposite.

Landmarks were designed to provide users with a method to quickly navigate macro regions of a document:
landmarks

AT implementations generally provide access to landmarks via a single key stroke, for example R in JAWS. by pressing the R key users move from one landmark to the next, the landmark name is announced (along with any accessible name the element has). When users land on the content area they are interested in they can then drill down into that content via heading, link, form controls or the host of other micro navigation methods available to them. In most AT landmarks are also presented via a dialog:

Example of a JAWS landmark dialog displaying banner, main, complementary and content info
jaws-landmark1

Due to the common implementation of landmarks (single keystroke for all landmark types), it is not a big leap conceptually to understand that the greater the number of landmarks, the decrease in the usability of them for navigation of the page, as a page cannot be navigated from top to bottom in a few keystrokes when there are many landmarks. This is reflected in anecdotal reports by users. This has also informed implementation of landmark semantics when mapped to HTML elements. Which is why header/footer only map to landmarks when scoped to the body element (sketchy data indicates that in the majority of documents 1 header/footer are used, but some documents contain large numbers of these elements). It is why section, which was originally mapped to role=region is only announced by AT that support it, when it has an accessible name (as a result of users complaining about its overuse and the consequent semantic noise it created) and it is the reason why main was defined the way it is, in attempt to maximise uitility to users and minimise author use that undermines utility. Further changes to the mappings may well occur in light of the design of landmarks. For example <aside> currently maps to complementary, the usage patterns of the element indicate that some muting of the semantics may be necessary to improve usability.

@joe-watkins

@Hixie If you have an interface that calls for multiple <main> tags you own a content problem. This is an automatic red flag that further distillation of content priority should occur.. much in the way that if your document consists of 76 <h1> tags.

Thankfully AT and browsers swallow the poor UX semi-gracefully.

@Hixie All I can imagine when you make us visualize a site that has a need for multiple <main> tags I visualize non-performant, ad riddled websites that are soon becoming victims of content blocking, and punished by search engines for poor practice. Do you maintain one of these?

Inconsistent documentation as a result of Rebel Alliance vs. Galactic Empire drama is harmful for developers that lean on these docs for how to write great code and exasperates our already inaccessible web.

As a developer, I’ve always considered WHATWG’s documentation a bit out of touch and really just a step above w3schools. Should we trust a source who’s using deprecated tags themselves? http://www.screencast.com/t/Z1L8LZArH | https://validator.w3.org/nu/?doc=https%3A%2F%2Fwhatwg.org%2F

I thought the <hgroup> tags was deprecated? https://html.spec.whatwg.org/multipage/semantics.html#the-hgroup-element

It’s time you get your docs in order and while you are at it I’m +1 for aligning with the W3C on the <main> tag.

@jpv66
jpv66 commented Sep 19, 2015

I work in accessibility since twenty years, I work with dozen of users, teach thousand of developpers. I totally agree with the views expressed by Steve, Leonie and all those who campaigned for a unique <main>.
I would add just one thing. "One more thing" : beyond these incessant debates and decisions you make, whatever they are, there are people like me whose role is to turn specifications into content truly accessible for users and my duty is to provide them the best. More than your bickering on a formal or theoretical definition and philosophical debates over semantics as interesting as they are, we need a unique <main>. simply because it's better for users. A simple feature, natural , clear and easy to use, wow... what a dream ! I don't even need to analyze data, I don't need to know how developers perceive or use this element, I don't, especially, need to know whether this represents some sort of theoretical vision . It was proposed a unique <main>. to solve an important usability problem. Problem solved.
By choosing an intrangisant position based on theory you are wrong fight. The only thing you get is to make our task even more complicated, and beyond for users for which we try to make things a little easier. Yes, this is not a theoretical, scientific or statistic argument :) .

Basically its not so serious, main will be unique because users need it.

@aardrian

Assuming you don't want to read my point-by-point response, you can just skip to the end of my comment for a question about the next step.

Now that you've laid out arguments why the spec is what it is, it's easier to address directly:

  • UAs already support multiple <main> elements in a usable and useful fashion, same as <div>.

You are making an assertion about "usable" and "useful" with no evidence to back it up.

UAs historically support lots of things in a usable and useful fashion -- for developers. Which is why we still find <font> and <center> in the wild. UAs graciously accepting bad code is not the same as implementing a spec properly else we'd be back to XHTML2. It is not for you to assert whether it is usable for a user.

  • ATs already support multiple <main> elements in a usable and useful fashion, according to AT users in this very thread who described the actual behaviour: it is treated as a normal landmark role, in document order. This is a mechanism with which AT users are presumably comfortable since it is used for the other landmark roles and general document navigation.

Two comments above dispute your assertion, suggesting only knowledge of the code on the page itself can mitigate confusion:

According to @bramd:

"The blog archive example that has been named earlier in this thread would actually cause me to think I landed on a single article page after jumping to the first main element and landing at the start of a blog post."

And from @BimEgan:

"So multiple main elements could mean that screen reader users can't be really sure where they are on the page and may miss the most recent article (at the beginning of main content) without knowing that they've done so."

  • There are many scenarios (e.g. an article with inline sidebars and advertising, a blog post with multiple articles, etc) where there are multiple disjoint parts of the page that consist of its primary content.

Except elements like <aside>, <section> and <article> already do that in a semantically better and more usable way.

In the world of site building, when the stakeholder says the most important thing should be font-and-center on the page, and then tells us that 10 items are equally the most important, we get carousels. Let's not allow us to codify its analogue.

  • Being able to style the primary content of a page or <article> is (mildly) useful. Since it can be disjoint, this requires multiple <main> elements. (This use case isn't enough to justify introducing an element, but since it's already implemented it's enough to justify specifying it as conforming.)

Your example also does not require multiple <main> elements for styling. You are just trying to re-state your third point; it is not a distinct argument.

  • Being able to jump to primary content on a page or <article> is useful. This can be achieved in a variety of ways, e.g. by skipping headers and other content marked as non-primary using the semantic elements in HTML, but it can also be achieved by having an element (such as <main>, which happens to already be implemented for this purpose in ATs) that highlights the primary content. Since the primary content can be disjoint, this latter approach requires being able to use multiple <main> elements.

This is a restatement of your points # 2 and # 3, which means it should be dismissed out of hand. Except here you are trotting out the Scooby-Doo algorithm, which has already been dismissed (hence <main>).

  • According to the ARIA spec and RFC2119, there may exist valid reasons in particular circumstances when it is acceptable or even useful for ARIA's "main" landmark role, on which <main> relies for its AT mapping, to be included in a document multiple times.

For those reading at home, RFC 2119 (https://www.ietf.org/rfc/rfc2119.txt) defines the keywords MUST, REQUIRED, SHOULD, etc. ARIA 1.0 and 1.1 say there SHOULD be no more than one main landmark role per page (http://www.w3.org/TR/wai-aria/roles#main, http://www.w3.org/TR/wai-aria-1.1/#main). Except we're talking about an element that manifests that role. As such, its implementation can go beyond what ARIA defines, enabling authors to create a better experience by following just the HTML spec without needing to call the ARIA landmark roles.

  • Since documents can be nested, ATs and UAs are in any case required to support the situation where multiple <main> elements can be nested.

And yet, those would each apply to one document, making it even more important that <main> is restricted to only once per, especially in consideration of my response to point # 2 above.

Your arguments against:

  • It's confusing to AT users. No particular backing for this claim has been presented, however. It's just been stated as fact. This seems to be contradicted by the descriptions of actual AT behaviour.

See the two examples I cited above. Actual AT behavior does not contradict those statements at all, if anything it shows a deficiency in how AT handles multiples.

  • It's contrary to the meaning of "main". This is irrelevant, we have plenty of elements whose semantics bear little relationship to their name (e.g. <address>, <cite>, <b>). It's also debatable, as described above -- primary, or "main", content on a page can be disjoint.

I think you need to consider that content authors have a meaning of the word in their head that doesn't match yours, and since this is a new element we have the opportunity to not lie about its name for once.

  • Certain classes of people don't want this behaviour. This argument is an appeal to consensus, which is contrary to the documented WHATWG values, and therefore irrelevant.

The opposite of that is appeal to authority, which is where I think nearly everyone feels we stand now based on the arguments. I would hope that isn't in the documented WHATWG values (for which I cannot find a link).

  • Not many pages use multiple <main> elements. This is based on very sketchy data (less than 300 pages that use the element at all) and generally speaking isn't a reason to disallow a usage.

Since you have already stated that you will discount any data that is not "in the billions," and since you know a data-set of this size is beyond the means of anybody other than someone on the scale of Google to gather, you are essentially tying anyone's hands on bringing data to bear.

  • "What if people misuse <main> in a harmful fashion?" This applies to the element regardless of the conformance rules and therefore isn't a relevant argument.

I tend to agree, but being more explicit in its documentation can help mitigate this.

  • "You (me, @Hixie) are personally against helping people with special accessibility needs." This is a patently absurd ad hominem contradicted by years of work, and, more to the point, is not an argument for or against anything to do with the spec.

I agree it's not relevant to the discussion (nor do I believe you are personally against helping people with special accessibility needs).

  • "There should be only one element". This is an argument by assertion and therefore doesn't actually help make a decision. It might be true or it might be false, there's no way, from just that argument, to know.

The assertion is supported by the original intent, feedback from professionals, current use, validation rules, the W3C specification, educational materials, and anecdotal feedback. If there was no assertion, there'd be nothing to test.

Put it all together, and I believe this is where we stand:

  • You find consensus from the original spec author, users, and professionals on this bug report insufficient.
  • You will not find any data-set demonstrating single instances of <main> to be sufficiently massive.
  • You do not accept anecdotal negative experiences from real users (even as a possible trend that can be averted).
  • You believe that the primary content of a page is not singular or can span multiple regions.
  • You believe the ARIA role implicit in the element overrides the element's intent.

Given that, assuming you disagree with everything I've argued above, have we reached an impasse or is there some other scenario that you would find sufficiently compelling to re-examine the element?

@foolip
Member
foolip commented Sep 21, 2015

There is one thing that I would like clarified. In those ATs that have a shortcut for jumping to <main> (or the landmark it maps to), can a user tell after using the shortcut whether there are more main sections? It seems to me that if there's almost always a single main section, then that would be an incentive for ATs to not bother announcing "no more main sections" or similar, and users would also not have much reason to try the shortcut again just to make sure, if there very seldom is another section.

@aardrian

@foolip, no. ATs supporting region navigation do not communicate to users whether there is more than one of a particular region. As such, there is no incentive for users to repeatedly activate the landmark navigation shortcut.

@Hixie
Member
Hixie commented Sep 21, 2015

@LjWatson @jpv66 Your most recent comment does not include any information that was not already stated on this bug. If you wish to contribute to WHATWG discussions, please be considerate of our culture, which specifically discourages repetition of already-stated points and statements of opinion without solid arguments or data.

@Heydon Styling is a big part of how people create documents on the Web. It's not besides the point, it's one of the main points. If it wasn't for styling, I think we would see even less usage of <main> than we do now. In general, the way to get accessible documents is to design features where using the feature for its non-accessible purpose in the most obvious way is coincidentally also the way to use it to improve accessibility. Features that are exclusively for accessibility tend to fail to achieve their purpose at scale because, unfortunately, most authors never test for accessibility and untested code is almost always wrong. This is why, for instance, longdesc="" and summary="" failed on the Web; it's also why alt="" has had a poor showing but a slightly better one (it has a secondary purpose for people who have images disabled -- I wouldn't be surprised if this got worse over time since images being disabled is no longer a thing, especially on mobile).

The element was added to the spec because it was implemented. It wasn't added to serve any specific purpose, the purpose was retrofitted on the implementations. (There was discussion of purpose prior to the implementations, but, at least at the WHATWG, those discussions concluded with the decision that the arguments were not sufficiently convincing to be worth adding the element, so they are not relevant.)

@stevefaulkner If you're not posting to achieve a change to the spec, please do not post at all. The only point of these bug trackers is to discuss changing the spec.

@joe-watkins We have to design for the Web we have, not the Web we wish we had. The reality of the Web is that pages have inline advertisements, asides, and so forth. Even the spec itself (which has far more than 76 <h1>s) has asides scattered all along it. Now I wouldn't think that <main> would make any sense for the spec, but if one were to use it, I don't see how one could use only one.

@aardrian That non-AT UAs support <main> usably is a trivial statement; they support it the same way as any element, namely, it's styleable. If that's not usable or useful then we have much bigger problems. By usable here I mean for authors. Users of non-AT UAs can't tell what element was used.

For AT UAs:

"The blog archive example that has been named earlier in this thread would actually cause me to think I landed on a single article page after jumping to the first main element and landing at the start of a blog post."

I've always felt that's a risk (even without <main>). How would you avoid it with a single <main>?

"So multiple main elements could mean that screen reader users can't be really sure where they are on the page and may miss the most recent article (at the beginning of main content) without knowing that they've done so."

I don't really see how a single <main> helps with this either. It just means there's a single spot on the page they can jump to (which they could do by jumping to the top of the page then jumping to the first <main>, in the multi-main case). How do you accidentally jump past the first one? Does the same problem exist with <h1>? Should we limit pages to only one heading for the same reason?

You say that "elements like <aside>, <section> and <article> already do that in a semantically better and more usable way", which is what I've been saying for a long time about <main> in general. This is an argument for removing <main> entirely, not for limiting it to only one instance per page.

You say we shouldn't codify analogues to what authors are doing (carousels, etc), but why not? That's exactly what we should be codifying! If we don't codify what people are doing, then we'll get a language that isn't relevant for the real world.

You are just trying to re-state your third point; it is not a distinct argument.

Sorry if it wasn't clear. My points were not peers, they were building a case. For example, the fourth bullet relies on the third bullet; without the third bullet, the fourth bullet would be without basis. The third bullet isn't an argument for multiple-<main>, it's just presenting a basis for further arguments.

And yet, those would each apply to one document, making it even more important that <main> is restricted to only once per, especially in consideration of my response to point # 2 above.

I don't understand what you're trying to say here. With seamless documents, there's not supposed to be any AT-exposed seam between nested documents.

I think you need to consider that content authors have a meaning of the word in their head that doesn't match yours, and since this is a new element we have the opportunity to not lie about its name for once.

There are many authors. They don't all agree on this point (for example, I'm an author, and I don't agree).

The opposite of [appeal to consensus] is appeal to authority

No, that's a false dilemma. The WHATWG process is documented on our FAQ, I urge you to read it.

Since you have already stated that you will discount any data that is not "in the billions," and since you know a data-set of this size is beyond the means of anybody other than someone on the scale of Google to gather, you are essentially tying anyone's hands on bringing data to bear.

One has to be realistic about what a useful data set is. That getting a useful data set is something that requires more than just a laptop and a few hours of Web crawling is unfortunate, but it's the truth.

FWIW, I've done research on other people's behalf before. If you present me with a data mining exercise that I believe has the possibility to bring new and actionable data to the table, then I would be happy to spend Google's resources obtaining that data. I'm sure people at Microsoft, Amazon, Yahoo, and other companies that have similar resources would be willing to help as well. The problem is that this requires describing a rigorous and well-defined study, including how to interpret the results. It's not at all clear to me what data one would collect here that would reasonably be used as evidence one way or the other.

The assertion is supported by the original intent

The original decision, at the WHATWG, was that the element was not needed; once it was implemented, the decision was just to retrofit the most useful purpose on the element.

feedback from professionals

On its own, this is an appeal to authority.

current use

It's not clear that this is actually backing the one-main argument, as discussed earlier.

validation rules

Not sure how this is an argument either way.

the W3C specification

I think you'll find that appeal to the W3C is not an effective tool here. Given how often the W3C has lied to us, betrayed our agreements, violated the spirit of cooperation, copied our work against our will, made changes to the spec that are laughably incompetently executed, and generally acted as a highly offensive and incompetent entity, I, at least, have to actively work to avoid having a bias that comes from an emotional reaction to the W3C.

educational materials

Not sure what you mean here. Can you elaborate? Would writing tutorials that encourage multiple-main be an argument in favour of multiple-main?

and anecdotal feedback.

I believe all the anecdotal feedback has been discussed above. Is there more?

You find consensus from the original spec author, users, and professionals on this bug report insufficient.

Consensus in general is not taken into account in decisions that affect the spec, right.

You will not find any data-set demonstrating single instances of <main> to be sufficiently massive.

On the contrary, I think it's quite possible for us to have sufficiently large datasets. I admit though that I can't really think of a study that would help determine the answer here. (In either direction. Suppose we found that all pages on the Web had two <main> elements. Would that tell us that we should make <main> allowed multiple times? Or would that tell us that things are really dire and we really need a conformance rule against it?)

You do not accept anecdotal negative experiences from real users (even as a possible trend that can be averted).

I haven't been convinced by what I've heard so far (and certainly I don't think there's a trend -- the feedback has been more mixed than you imply). That does not mean that I couldn't be convinced otherwise. In the past we've had people demonstrate this kind of thing with videos showing their experience browsing the Web that have been quite helpful in coming to a decision, for example. I could definitely imagine someone showing their experience on a common (non-artificial) Web page, such as a page on CNN, modified several times to show a variety of ways that <main> could be used, and demonstrating why one or another model is obviously more usable than another. (I should hasten to add that in the past, such videos have sometimes convinced me of things that are quite different than what the person showing the video thought they would convince me of.)

You believe that the primary content of a page is not singular or can span multiple regions.

This isn't a belief taken on faith. It's demonstrably true. Many news providers, for example, intermix "related content" with their articles. Blogs have multiple blog posts mixed with advertising. Even the HTML spec has "in flow" content mixed with "aside" content like examples and notes.

You believe the ARIA role implicit in the element overrides the element's intent.

I think the ARIA role's definition is an interesting data-point. I don't think it's compelling enough one way or the other.

From an accessibility perspective (only), <main> and <div role=main> seem to be equivalent. As such, since we allow multiple <div role=main>s, why not allow multiple <main>s? I don't see a good answer to that, which is why this, to me, is a (weak) argument in favour of multiple-<main>. But this is mostly an appeal to authority, I'll grant you.

Given that, assuming you disagree with everything I've argued above, have we reached an impasse or is there some other scenario that you would find sufficiently compelling to re-examine the element?

I hope I've described some above. I could always be convinced of something. Even if we changed the spec to only allow one <main>, I could always be convinced to go back to multiple-main one day. As more data is added to the discussion, the weight of evidence one would need to change the decision grows, since you have to outweigh all the arguments in the other direction first. Currently, I see pretty much no reason to disallow multiple-main, and lots of weak reasons to allow it. Some strong reasons to disallow it would be convincing. A large number of weak reasons would be convincing.

@jpv66 Assuming you really mean that you've been working in accessibility for 80 years, I would like to welcome you to our community. I'm sure that makes you the oldest and most experienced contributor we have.

@metzessible

I usually try to avoid getting involved in arguments between WHATWG and W3C supporters, because there's typically too much baggage to sort through before getting to the meat of the disagreement. Indeed, even in an argument about whether or not there is value in supporting multiple <main> elements in a page, there seems to be existing issues dredged up from those in support of, and those in opposition of, the present decision.

Therefore, I'm not going to speak about:

  • Whether the W3C doc or the WHATWG doc is better than the other;
  • How AT or UA reacts to multiple instances of an element;
  • Anyone's perceived bias against PWD;
  • Web authors desire to style an element; or
  • Whether developers will end up marking up a page appropriately for once.

Instead, I'm going to suggest the notion that the way the specification is written, the second note for the Main element actually contradicts the normative statements previously mentioned. By example of comparison, the W3C documentation does have a more detailed explanation of the element itself, which I do believe supports the argument a bit more concretely that there should only be one instance of this element within the markup. The lack of explanation is what's causing some confusion surrounding how to handle multiple <main> elements within WHATWG's documentation.

Despite this lack of detail, the <main> element is described as "a container for the dominant contents of another element." Explicitly stated, it is an element that — once chosen to be implemented — it provides intrinsic meaning to it's children. However, this is element is distinct from sectioning content in that it provides no contribution to an outline. This is important because the <section> element is explicitly appropriate when generating an outline for "thematic grouping of content." Web authors wishing to style content are encouraged to use a <div> instead.

Therefore, in considering the usage of multiple <main>s on a page, one would need to assume the purpose of the element is either to style (incorrect usage), or to provide instances for other sections (incorrect markup). The specification written for <main> is not intended to provide styling or for sectioning, yet it could be construed as such given the second note's lack of clarification. Instead, <main> has the semantic purpose of providing the relevant content on a page. For purposes of single-page websites, templates, et al, there are already available elements to provide context for those separate sections where their purpose would be semantically appropriate because they provide an outline for which they are best served.

To parse @Hixie's visual representation of streets with my explanation:

Group of houses labeled with text describing their respective street as "W3C Street <main> Entrance

This is semantically appropriate because it details the location of grouping elements (houses) that exist within the page. In a real-world example, the <main>-street element is the location of where the mail gets sent to, but it requires a semantically defined outline of which group actually receives mail. In this case, the following markup for (my new web-based Utopia) Standardistan would look like the following:

  <article>
    <house>
      <section>
       <H1> House Number 1 </H1>
      <aside>
         <div> window 1 </div>
         <div> window 2 </div>
      </aside>
      </section>
  </article>
   <article>
    <house>
      <section>
       <H1> House Number 2 </H1>
      <aside>
         <div> window 1 </div>
         <div> window 2 </div>
      </aside>
      </section>
  </article>
  <article>
    <house>
      <section>
       <H1> House Number 3 </H1>
      <aside>
         <div> window 1 </div>
         <div> window 2 </div>
      </aside>
      </section>
  </article>
</main>

In this regard, your second image is incorrect, because the purpose of the document is not to differentiate between the separate dominant content existing on <main> street, but rather to explain where exactly mail gets delivered. In other words, the image could be described as, "This is the dominant location of Standardistan. Within its borders there exists a group of 3 houses. Each house has 2 windows and a door, of which there is an entrance. The entrance to the content of each house is represented by a Heading, easily conceptualized based on it's ranking within the dominant location." The doors might be considered to be main entrances (as opposed to their back patios perhaps), but accessing these doors is based upon how they have registered in the DOM (e.g., the map to our town) according to the outline that has been presented.

My explanation for why "a page with multiple article elements might need to indicate the dominant contents of each such element" (as written in the second note) is semantically inappropriate is that any element that needs to indicate another purpose should be able to be programmatically determined. So far, outlines seem to be the best way to achieve intrinsic meaning within HTML5, so providing context to those elements should trump the various arguments for using a different way to observe dominant content.

If I were to say, "Look at the second house," the method of performing this action wouldn't be to find the main entrance of a given home, yet rather to observe where in the overall scheme of a specific domicile location it resides and define it from the characteristic of it's logical reference of association to other elements within a given location. Given this example, the concept of outlines is how to distinguish the target home, yet the concept of <main> provides where to begin that observation in the first place.

I'm not arguing that you should use only one <main> on a page because it's better for the end user, or that there is sufficient data to back up how one perceives relevant information on a page; but rather because the supporting specifications according to either WHATWG and W3C both explain how there is already a preferred methodology for presenting information and relationships within properly semantic markup. The <main> element is used to describe the overall dominant information, yet the methods of programmatically determining similarly relevant, yet separate information is accomplished through a separate preferred technique consisting of sectioning and headings. Using <main> in such a manner is incorrect according to WHATWG and W3C supporting normative specifications.

@mpnkhan
mpnkhan commented Sep 22, 2015

As a developer we were using <div id="main"> as a container which wraps all the elements of the page. After <main> was introduced, conveniently replaced this main div with <main> . Never had the necessity to include multiple <div id='Main'> . When i came to know that it additionally helps Screen reader users, just go for single <main> . Single <main> = less confusion.

@foolip
Member
foolip commented Sep 22, 2015

@aardrian, is that true even of landmarks where there's usually more than one, like headings or menu items?

@aardrian

@foolip, yes.

@Hixie, this is my best effort to answer your direct questions and address some of your points. Apologies for the length but there is a lot to unpack.

I've always felt that's a risk (even without <main>). How would you avoid it with a single <main>?

Sadly, you cannot. Just as you cannot prevent authors from using multiple IDs of the same value, etc. Though validation errors can at least raise the issue.

But if you agree that's a risk, then let's clean up the language to reduce that risk.

I don't really see how a single <main> helps with this either. [...] How do you accidentally jump past the first one? Does the same problem exist with <h1>? Should we limit pages to only one heading for the same reason?

To answer each of the three questions: The issue isn't accidentally jumping past the first one, but missing subsequent <main>s because a user may jump to another landmark. The same problem does not exist with <h1> because it is not a landmark. There is no same reason, so the question doesn't even apply.

You say that "elements like <aside>, <section> and <article> already do that in a semantically better and more usable way", which is what I've been saying for a long time about <main> in general. This is an argument for removing <main> entirely, not for limiting it to only one instance per page.

Except those elements do not provide the same landmark navigation, its primary use case for inclusion and what makes it stand apart from the others.

You say we shouldn't codify analogues to what authors are doing (carousels, etc), but why not?

Because we have analysis that tells us that pattern is counter-intuitive and lowers engagement, confuses users, and generally doesn't work well.

There are many authors. They don't all agree on this point (for example, I'm an author, and I don't agree).

My point is that you have to understand that the very word is understood differently by people who are not you.

No, that's a false dilemma. The WHATWG process is documented on our FAQ, I urge you to read it.

I did read it. I saw no "values." I also disagree with your logical conclusion.

If you present me with a data mining exercise that I believe has the possibility to bring new and actionable data to the table, then I would be happy to spend Google's resources obtaining that data.

I would love for Google to provide a method to allow us to search its entire index for HTML patterns. While that's outside of the scope of this issue report, I think that would be a great feature.

The original decision, at the WHATWG, was that the element was not needed; once it was implemented, the decision was just to retrofit the most useful purpose on the element.

And that's what this issue is trying to adjust. Hence, the assertion supported by the original intent. The more practical decision would have been to just align with the spec from W3C as the element's purpose had already been determined.

You've dismissed the expertise and recommendations of those on the ground as an appeal to authority. This is problematic because they are in the best position to understand its impact, particularly after recommending it be added.

I, at least, have to actively work to avoid having a bias that comes from an emotional reaction to the W3C.

The paragraph I trimmed suggests that's not the case. If it were, you'd acknowledge that it is a standards body and that developers do listen to it. As such, this spec promotes confusion.

Can you elaborate? Would writing tutorials that encourage multiple-main be an argument in favour of multiple-main?

Low-hanging fruit (because I have no books, online courses, etc. handy to check): https://www.google.com/?gws_rd=ssl#q=html5+main+element Tutorials and explainers say to use no more than one. For your second question, sure, it could be a part of an argument, though it would be contending with existing material specifying the contrary.

Suppose we found that all pages on the Web had two <main> elements. Would that tell us that we should make <main> allowed multiple times?

It would tell us that we need to revisit the W3C spec to be more explicit, that we need better training materials, and also to work with ATs to better surface that information.

Or would that tell us that things are really dire and we really need a conformance rule against it?

Nope.

In the past we've had people demonstrate this kind of thing with videos showing their experience browsing the Web that have been quite helpful in coming to a decision, for example.

Would you be willing to bring Google's resources to bear on making a video testing lab available (for this and other questions)?

Even the HTML spec has "in flow" content mixed with "aside" content like examples and notes.

Which would live within a <main>. None of your examples warrant multiple <main>s. Doing so is an author preference (that I would discourage), not one guided by some clear rule.

As such, since we allow multiple <div role=main>s, why not allow multiple <main>s? I don't see a good answer to that, which is why this, to me, is a (weak) argument in favour of multiple-<main>.

I stated it already: "As such, its implementation can go beyond what ARIA defines, enabling authors to create a better experience by following just the HTML spec without needing to call the ARIA landmark roles."

@karlgroves

@Hixie says

If you present me with a data mining exercise that I believe has the possibility to bring new and actionable data to the table,

Actually @stevefaulkner already did this, very early in this conversation. He did so using data publicly available from WebDevData using a statistically significant data set with a very low margin of error. You can, if you so choose to, replicate his investigation using that same open data to verify or dispute his results.

Unless there's any dispute as to the accuracy or completeness of his claim, it would appear that he has provided you with "new and actionable data". That data says, pretty clearly, that authors understand that intent for the <main> element is that there should be one and only <main>.

In short, you have 22/24 participants in this conversation in agreement that there be one and only <main> and you have data demonstrating that there is "... >97% of usage of the <main> element is as per the W3C definition..."

Given the above, when can we expect the WHATWG spec to be brought in line with W3C spec WRT the <main> and <body> elements as suggested by Steve Faulkner?

@foolip
Member
foolip commented Sep 24, 2015

The httparchive data set is pretty big if anyone wants to do research. I looked in the 20150101 data for case-insensitive matches for <main and then counted the number of <main> elements using this script:

#!/usr/bin/env python3

import html5lib
import sys

f = open(sys.argv[1])
tree = html5lib.parse(f)
mains = [e for e in tree.iter() if e.tag == '{http://www.w3.org/1999/xhtml}main']
print(len(mains))

Here are the ones with more than one <main>, if anyone wants to analyze why this might happen:

10 http://www.litmusbranding.com/
9 http://www.51offer.com/
8 http://www.tenditrendy.com/
8 http://www.homedit.com/
8 http://www.fingerprintexpert.in/
7 http://www.kgbr.co.kr/flash/menuList.php
5 http://www.watch-next.com/
5 http://www.studiocalico.com/
4 http://www.visitnewportbeach.com/
4 http://www.suckhoenhi.vn/
4 http://www.longtailpro.com/
4 http://www.hlf.org.uk/
4 http://hsmeducacaoexecutiva.com.br/
4 http://family.disney.com/
4 http://beta.captora.com/views/scoreCard/scoreCard.html
3 http://www.tubepornparty.com/
3 http://www.tryxxxtube.com/
3 http://www.tryporntube.com/
3 http://www.topporntubes.com/
3 http://www.thenewslens.com/
3 http://www.themosis.com/
3 http://www.maturevideos.xxx/
3 http://www.linkfinance.fr/
3 http://www.kgbr.co.kr/flash/quick_menu.php
3 http://www.gpwiki.org/
3 http://www.aish.com/
3 http://www.african-porno.com/
2 http://www.ultimate-bravery.com/
2 http://www.tribuna.ru/
2 http://www.timocom.de/
2 http://www.timocom.com/
2 http://www.themosis.com/en/
2 http://www.thejoysofboys.com/
2 http://www.rhein-neckar-loewen.de/
2 http://www.pnxsoft.com/
2 http://www.plumperporn.xxx/
2 http://www.pinoytravelblog.com/
2 http://www.payproglobal.com/
2 http://www.nou-pou.gr/
2 http://www.mtk.ru/
2 http://www.moneyguru.com.br/
2 http://www.matito.ru/
2 http://www.lifespa.com/
2 http://www.krisaquino.net/
2 http://www.isavea2z.com/
2 http://www.ioucentral.com/
2 http://www.india-topsites.com/
2 http://www.hmsa.com/
2 http://www.frugalfanatic.com/
2 http://www.french101.me/
2 http://www.freeanal.xxx/
2 http://www.f-e.tw/
2 http://www.dailysquib.co.uk/
2 http://www.couponsaregreat.net/
2 http://www.cosmopolitan.de/
2 http://www.christiankonline.com/
2 http://www.campusinsiders.com/
2 http://www.byui.edu/
2 http://www.blockstream.com/
2 http://www.bergbahn-kitzbuehel.at/
2 http://www.bbwfuck.xxx/
2 http://www.bankbii.co/whitecard/
2 http://www.affenblog.de/
2 https://www.sensus-capital.com/en/

Warning: Lots of porn. Also, some of these sites have changed since they were crawled.

I haven't gone through all of these sites, but many seem to be using <main> elements in crazy ways. However, http://tribuna.ru and http://www.thenewslens.com/ actually look quite sane, with what seems to be the main content marked up as such.

It would be quite the undertaking to analyze a random selection of <main>-using sites to figure out what conclusions to draw.

@stevefaulkner
Contributor

@foolip What was the total number of pages with main?

@foolip
Member
foolip commented Sep 25, 2015

There were 9019 resources (from 8770 pages) that I passed through the Python script, based on an initial grep and removing things that didn't have Content-Type text/html. There are 10139623 resources (don't know how many pages, but much fewer) in the 20150101 httparchive data I have.

Suffice to say, <main> itself is uncommon and multiple <main> elements much less common still.

@stevefaulkner
Contributor

Suffice to say, <main> itself is uncommon and multiple <main> elements much less common still.

@foolip, thanks. I did a full grep of latest http://webdevdata.org and found 1732 pages with <main> of those 1720 = 1 <main> = 98.7%, and from what you have reported the results for the httparchive data is very similar.

I don't think it should suprise anybody that the usage of <main> is low as it has only been around for a few years.

@foolip
Member
foolip commented Sep 25, 2015

@stevefaulkner, I don't think this number can really inform the decision, other than to tell us that almost nobody will be affected by a change. A more worthwhile exercise, IMHO, would be to analyze the tiny subset where people are using multiple <main> elements, to see if there are reasonable cases among them.

@stevefaulkner
Contributor

@foolip I would think that how developers use a feature reveals a cowpath, there must be some reason why 99% of developers who use it, use 1 main per page and it would be an important consideration in defining the feature, but I am obviously missing some understanding of feature design.

@metzessible

I don¹t know if it¹s important, but it might be worth noting that [at least
for] the adult websites that are on the list from the httparchive data set
are actually mirrors of the same site. So for much of the data that¹s
listed, they¹re going to be relatively low quality in terms of a source. Not
sure if that¹s helpful to this conversation.

@foolip
Member
foolip commented Sep 25, 2015

@stevefaulkner, maybe a single <main> is enough in 99% of cases but multiple <main> elements is a great idea in the remaining 1%. Or maybe the remaining 1% is all incorrect and confused. Maybe the same kinds of mistakes are made regardless of the number of <main> elements in use. All of these possibilities are consistent with the data, so I'm not sure what to make of it.

A full analysis of the URLs listed would be very tedious, but I would be interested to know if e.g. http://tribuna.ru and http://www.thenewslens.com/ look reasonable.

@stevefaulkner
Contributor

@foolip I had a look at the majority of the pages in the list you provided. It appears that usage falls into a few buckets.

  1. nested main without content between: this appears to serve no purpose http://www.thejoysofboys.com/ and http://www.isavea2z.com/
    `
` 1. multiple mains acting as macro containers for content ` ` is a conformance error in w3c, but due to the limited instances (usually 2) is not an egregious issue, also given the example you provided where this is the case (http://www.thenewslens.com/) has almost every other piece of text content marked up as a heading, it is probably inconsequential and 'looks _reasonable_' compared to the rest of the markup.: ![capture](https://cloud.githubusercontent.com/assets/835859/10131654/c09af08e-65c9-11e5-83d9-df87020fbb47.PNG)

or http://www.themosis.com/ this one uses it like article or section

  1. Then there examples such a the following where main is used being used wrong under anybodies definition (although it would lead to a conformance checker flagging an error only under w3c definition):
    multiple <main>'s http://www.litmusbranding.com
    cprlpcow8aajv9a

The main sticking point in this discussion is that there are fundemental differences between the semantics of main between whatwg (can be used to markup both macro and micro content pieces) and w3c (can be used to markup a macro content piece) and from the comments above (dominant message being - main serves no useful purpose except as styling hook and is only in whatwg spec because it has been implemented) it appears to be no way to reconcile this.

whatwg

The main element can be used as a container for the dominant contents of another element. It represents its children.

w3c

The main element represents the main content of the body of a document or application.

@foolip
Member
foolip commented Sep 28, 2015

Thanks @stevefaulkner, that's very helpful.

The usage on http://www.litmusbranding.com/ is bad indeed, it's apparently only used for styling, and doesn't correspond to the "dominant content" even locally. It would be bad even with just a single <main> somewhere in the that footer.

It seems to me that "nested main without content between" (example?) would indeed be better off merged, that "multiple mains acting as macro containers for content" is reasonable if the main content really is discontiguous, and that cases like litmusbranding.com would be better off with no <main> element at all, or one <main> element elsewhere in the page.

Do you have any hunch about how much content falls into each bucket? If you made lists of URLs that would be nice, but I know it's a lot to ask.

@domenic
Member
domenic commented Sep 28, 2015

I think "just as a styling hook" is not good, and maybe the current definition skews too much that way (although I think the W3C version doesn't understand how "represents" is supposed to work). But I still see no argument for restricting to one per page.

Also, to address something from earlier: I think cowpaths are a useful guide when designing new features. They are not useful however in designing restrictions. Saying "most people do it this way, so we should disallow anyone from using the feature in a different way" is not a good way of designing standards. Cowpaths arguments should be instead "most people are doing this, so we should design a feature to support them." It's OK if the feature ends up being more general and supporting more use cases at the conclusion of the resulting design process.

Instead, restrictions should be imposed based on arguments demonstrating concrete harm, which still haven't been presented.

@stevefaulkner
Contributor

@domenic

although I think the W3C version doesn't understand how "represents" is supposed to work

can you explain?

@stevefaulkner
Contributor

Instead, restrictions should be imposed based on arguments demonstrating concrete harm, which still haven't been presented.

It is difficult (which is why I am no longer arguing for change in this fora) when users (actual users who get this stuff as UI) provide their input explaining why main as currently used , is a) useful to them and b) fits their mental model of what the semantics of main means. (i.e macro vs micro) as part of the landmark structure, but their input is dismissed.

@stevefaulkner
Contributor

@foolip, here is my notes on the majority of the URLS you provided,

On 24 September 2015 at 13:48, Philip Jägenstedt notifications@github.com
wrote:

The httparchive data set is pretty big if anyone wants to do research. I
looked in the 20150101 data for case-insensitive matches for <main and
then counted the number of

elements using this script:

#!/usr/bin/env python3
import html5libimport sys

f = open(sys.argv[1])
tree = html5lib.parse(f)
mains = [e for e in tree.iter() if e.tag == '{http://www.w3.org/1999/xhtml}main']print(len(mains))

Here are the ones with more than one

, if anyone wants to analyze
why this might happen:

10 http://www.litmusbranding.com/
9 http://www.51offer.com/

both appear to be misuse

8 http://www.tenditrendy.com/

no

8 http://www.homedit.com/

uses as both macro and micro container

8 http://www.fingerprintexpert.in/

no

7 http://www.kgbr.co.kr/flash/menuList.php

no visible page content, looking at code uses this:

<main_menu>
<main target="_self" link="./company.php" label="한국복음서원">
<main target="_self" link="./ebook.php" label="E-book 카페">
<main target="_self" link="./truth100.php" label="진리와 생명">
<main target="_self" link="./manna.php" label="만나">
<main target="_self" link="./mediazone.php" label="미디어존">
<main target="_self" link="./shareroom_my_one_message.php" label="내가누린한문장">
<main target="_blank" link="http://mall.kgbr.co.kr/" label="복음서원MALL"> </
main>
</main_menu>

5 http://www.watch-next.com/

uses one

only, uses it as container for main content for document..

5 http://www.studiocalico.com/

uses one

only, uses it as container for main content for document..

4 http://www.visitnewportbeach.com/

uses it to mark up part of content in a section

4 http://www.suckhoenhi.vn/

uses one

only, uses it as container for main content for document..

4 http://www.longtailpro.com/

no

4 http://www.hlf.org.uk/

uses it as child of

  • 's as container for a element

    4 http://hsmeducacaoexecutiva.com.br/

    no

    4 http://family.disney.com/

    with parent section ,

    used as a container for a child section
    element

    4 http://beta.captora.com/views/scoreCard/scoreCard.html

    used as header/main/footer

    3 http://www.tubepornparty.com/
    3 http://www.tryxxxtube.com/
    3 http://www.tryporntube.com/
    3 http://www.topporntubes.com/
    3 http://www.maturevideos.xxx/
    3 http://www.african-porno.com/
    2 http://www.plumperporn.xxx/
    2 http://www.freeanal.xxx/

    2 http://www.bbwfuck.xxx/

    used to mark up 2 discontinuous areas of main content and footer/nav
    content (all use same template)

    3 http://www.thenewslens.com/
    3 http://www.themosis.com/

    already mentioned

    http://www.maturevideos.xxx/
    3 http://www.linkfinance.fr/

    used to mark up 3 discontinuous areas of main content

    3 http://www.kgbr.co.kr/flash/quick_menu.php

    duplicate URL

    3 http://www.gpwiki.org/

    suggest gratuitous use:

    <main role="main" class="row gutters">
            <article class="col span_12">
                <p>Welcome to the Game Programming Wiki - A community driven
    resource for everything related to game programming.</p>
            </article>
        </main>

    3 http://www.aish.com/

    used to mark up 3 visibly continuous areas of main content

    http://www.african-porno.com
    2 http://www.ultimate-bravery.com/

    used to mark up 2 discontinuous areas of main content

    2 http://www.tribuna.ru/

    used to mark up 2 visibly continuous areas of main content

    2 http://www.timocom.de/
    2 http://www.timocom.de/http://www.timocom.com/

    marks up 1 main content area and 1 link list inside main content area

    <main>
                        <ul class="clearfix">
    
                                <li>
                                    <span class="nowrap"><i
    class="icon-chevron-right highlight"></i>&nbsp;<a title="Transport Europa"
    href="/?lexicon=1109070913400622|Transport
    Europa|Transportlexikon">Transport Europa</a></span>
                                </li>
    
                                <li>
                                    <span class="nowrap"><i
    class="icon-chevron-right highlight"></i>&nbsp;<a title="TC eBid®"
    href="/?lexicon=1008171048233546|TC eBid®|Transportlexikon">TC
    eBid&reg;</a></span>
                                </li>
    
                                <li>
                                    <span class="nowrap"><i
    class="icon-chevron-right highlight"></i>&nbsp;<a title="Hubwagen / Ameise"
    href="/?lexicon=1301281146359213|Hubwagen /
    Ameise|Transportlexikon">Hubwagen / Ameise</a></span>
                                </li>
    
                                <li>
                                    <span class="nowrap"><i
    class="icon-chevron-right highlight"></i>&nbsp;<a title="Autotransport"
    href="/?lexicon=1103141353499382|Autotransport|Transportlexikon">Autotransport</a></span>
                                </li>
    
                                <li>
                                    <span class="nowrap"><i
    class="icon-chevron-right highlight"></i>&nbsp;<a title="Laderaumbörse"
    href="/?lexicon=807020858411925|Laderaumbörse|Transportlexikon">Laderaumbörse</a></span>
                                </li>
    
                        </ul>
                    </main>

    2 http://www.themosis.com/en/
    2 http://www.thejoysofboys.com/

    already mentioned

    2 http://www.rhein-neckar-loewen.de/

    nested main:

    <main id="content" class="main">
    <div class="layout-wrapper">
    <div class="layout-grid">
    <div class="layout-content">
    <main id="content" class="main">

    2 http://www.pnxsoft.com/

    1 main for main content 1 main for footer nav list

    2 http://www.pinoytravelblog.com/

    used to mark up 2 visibly continuous areas of main content

    2 http://www.payproglobal.com/

    used to mark up 2 visibly continuous areas of main content

    2 http://www.nou-pou.gr/

    used to mark up 2 continuous areas of main content

    3 http://www.mtk.ru/

    used to mark up 3 discontinuous areas of content difficult to know if
    its 'main content' or not, as site is in russian.

    2 http://www.moneyguru.com.br/

    use 2 mains (1 for mobile, 1 for desktop view) mobile hidden in desktop
    view

    2 http://www.matito.ru/

    use 1 for main content another for google search form in header area at
    top of page.

    2 http://www.lifespa.com/

    uses 1 main only, for main content.

    2 http://www.krisaquino.net/

    site no longer available

    2 http://www.isavea2z.com/

    already mentioned

    2 http://www.ioucentral.com/

    no

    2 http://www.india-topsites.com/

    2 areas of visiby continuous main content

    2 http://www.hmsa.com/

    2 areas of visiby discontinuous main content

    2 http://www.frugalfanatic.com/
    nested main, no content between

    2 http://www.french101.me/ http://www.freeanal.xxx/
    2 http://www.f-e.tw/

    1 main only (marks up main content)

    2 http://www.dailysquib.co.uk/

    used to mark up 2 continuous areas of main content

    2 http://www.couponsaregreat.net/

    nested mains no content between

    2 http://www.cosmopolitan.de/

    1 for main content 1 for contact info in footer

    2 http://www.christiankonline.com/

    used to mark up 2 continuous areas of main content

    haven't gone through the following:

    2 http://www.campusinsiders.com/
    2 http://www.byui.edu/
    2 http://www.blockstream.com/
    2 http://www.bergbahn-kitzbuehel.at/
    2 http://www.bankbii.co/whitecard/
    2 http://www.affenblog.de/
    2 https://www.sensus-capital.com/en/

    Warning: Lots of porn. Also, some of these sites have changed since they
    were crawled.

    I haven't gone through all of these sites, but many seem to be using

    elements in crazy ways. However, http://tribuna.ru and http://www.thenewslens.com/ actually look quite sane, with what seems to be the main content marked up as such.

    It would be quite the undertaking to analyze a random selection of

    -using
    sites to figure out what conclusions to draw.


    Reply to this email directly or view it on GitHub
    #100 (comment).

  • @foolip
    Member
    foolip commented Sep 28, 2015

    For completeness, here are the few remaining that you didn't look at:

    2 http://www.campusinsiders.com/

    4 <main> used somewhere in navigation, can't find it visually, but doesn't seem sensible at all.

    2 http://www.byui.edu/

    One <main> nested inside another, single <main> would make more sense.

    2 http://www.blockstream.com/

    Two visually discontinuous bits marked up with <main>, looks kind of intentional, but including the part in between them seems like it would be an improvement.

    2 http://www.bergbahn-kitzbuehel.at/

    One <main> for desktop and one for mobile, with CSS used to hide one of them. Seems fine as long as AT will ignore the bits with display:none, which I think is the case.

    2 http://www.bankbii.co/whitecard/

    Both the navigation and main content are marked up with <main>, using something else for the navigation seems better.

    2 http://www.affenblog.de/

    Now just a single <main>, used appropriately.

    2 https://www.sensus-capital.com/en/

    A single <main>, but excluding what in my eyes is the "most main" content, namely "Sensus Capital is a fully regulated European online-broker ..."

    @foolip
    Member
    foolip commented Sep 28, 2015

    http://www.kgbr.co.kr/flash/menuList.php actually does have 7 <main> elements when checked in devtools, but it doesn't look sensible.

    @stevefaulkner
    Contributor

    7 http://www.kgbr.co.kr/flash/menuList.php

    no visible page content, looking at code uses this:
    <main_menu>

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    On 28 September 2015 at 15:34, Philip Jägenstedt notifications@github.com
    wrote:

    http://www.kgbr.co.kr/flash/menuList.php actually does have 7


    elements when checked in devtools, but it doesn't look sensible.


    Reply to this email directly or view it on GitHub
    #100 (comment).

    @foolip
    Member
    foolip commented Sep 28, 2015

    Sorry, I thought I saw main_menu and main_target, but it was actually main elements, as you said.

    @stevefaulkner
    Contributor

    On 28 September 2015 at 15:31, Philip Jägenstedt notifications@github.com
    wrote:

    bits with display:none, which I think is the case.

    yes

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    @foolip
    Member
    foolip commented Sep 29, 2015

    OK, so it's hard to divide the cases into unambiguous groups, but it does look like there are a number of sites where multiple main elements come to good use, and here I include every case where discontinuous areas of main content are marked up. Also in some cases where there's just blank space between the two mains, like india-topsites.com, the common parent includes too much. One could add a level of nesting, but it would be nice to not require it if multiple mains are needed for other cases anyway.

    If multiple main elements were made non-conforming, what advice should one offer to a site like http://www.thenewslens.com/?

    There are a number of cases where usage is just weird that would be nice if validators could warn about, but using what rules that wouldn't also complain about the reasonable cases?

    @frex65
    frex65 commented Sep 29, 2015

    OK, here's why a single <main> element is important from this screenreader user's perspective:

    The block of content that's perceived to be the main or unique content on a page is almost always apparent visually. It's usually slap bang in the middle of the page, coloured, styled and/or positioned in a way that makes its status as main content impossible to miss.

    AT doesn't have any algorithm for determining which is main and which supplementary content (navigation, search, etc). So each new website was a learning/guessing game.

    Then came the <main> element, which promised great things. With a single AT shortcut key I'd be able to confidently move to the beginning of the most relevant content on the page and start reading, and my AT would let me know when the main content finished. Or if I knew there was some information of interest near the end of the main content, I could use another AT shortcut key to move to the close of the <main> element and work my way up. Everything would be encapsulated into beautifully discrete and navigable chunks. Where there's only one <main> element on a page, and it's wrapping the correct content, this strategy works beautifully. I love the <main> element! It's so much more AT-friendly than relying on an H1 to flag up the start of main content and having no foolproof way to know when it's ended.

    Then some authors began splitting the unique content out across multiple <main> elements, and I began to lose confidence that my new foolproof navigation strategy would work. So after my AT told me I'd reached the end of the main content, I'd listen to my screenreader babbling on with social networking links and ads and other stuff that was probably in the footer, because I was afraid there might be another <main> or <div> or some other random element coming up that would contain important or interesting content.

    If not a <main> element, what can we wrap around the page's unique content to flag up its start and end to AT? To be efficient, I need a navigation strategy that's quick and clean. Multiple use of the <main> element doesn't provide that for me.

    @stevefaulkner
    Contributor

    On 29 September 2015 at 12:57, Philip Jägenstedt notifications@github.com
    wrote:

    If multiple main elements were made non-conforming, what advice should one
    offer to a site like http://www.thenewslens.com/?

    hi @foolip, i really don't think that the issue is multiple vs single (we
    know that in vast majority of cases main is used in singular and this works
    well, from what users tell us). The issue between the 2 definitions is one
    defines it as a macro container, the other opens door for marking up much
    smaller bits of content in many places witthin the document. (and yes I
    have said all this before, so won't go into again). Until we can come to
    some agreement that the definition of what main represents can be aligned
    more closely and thus how it is meant to be used, discussing the minutiae
    of the conformance requirements appears moot.

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    @Alohci
    Alohci commented Sep 29, 2015

    @stevefaulkner If that's the case, would changing the W3C definition to allow

    
    [boilerplate text]
    main content
    [advertisement]
    main content
    [sidebar]
    main content
    [footer]
    

    to be marked up, by defining the main element to indicate the start or resumption of the dominant content of the page help to move towards a compromise definition?

    @stevefaulkner
    Contributor

    @lohci

    On 30 September 2015 at 00:34, Alohci notifications@github.com wrote:

    @stevefaulkner https://github.com/stevefaulkner If that's the case,
    would changing the W3C definition to allow

    [boilerplate text]
    main content
    [advertisement]
    main content
    [sidebar]
    main content
    [footer]

    to be marked up, by defining the main element to indicate the start or
    resumption
    of the dominant content of the page help to move towards a
    compromise definition?

    From data provided publicly, so far; the pattern you describe is an edge
    case, From all reports from users that have been given, suggest that the
    following would be preferred,

    [boilerplate text] main content [advertisement] main content [sidebar] main content [footer]

    If users report that the proliferation of instances of elements, in a document, with landmark semantics is of benefit to them (up until now the contrary has been the case), we may need to rethink the current w3c definition.
    Note there is no prohibition on nesting other landmarks within the main content.

    I think the real world data reviewed, the more interesting cases are those like:

    2 http://www.moneyguru.com.br/

    use 2 mains (1 for mobile, 1 for desktop view) mobile hidden in desktop
    view

    From reviewing the data there may be edge cases for allowing multiple
    's, but this should be limited, not encouraged.
    i.e. instead of 'must not' be more than one main, could be 'should not'
    W3C main is not about identifying discrete pieces of main content it is not
    about 'dominant content', its about identifying the large content area
    that contains the main content as this definition is what fitted best with
    the data on id values, targets for skip links, and usage of role=main found
    in data at the time and what users report is of most benefit to them, no
    public data or user feedback has been presented here that undermines these
    reasons.

    @foolip
    Member
    foolip commented Sep 30, 2015

    @stevefaulkner do you have a proposed wording that would allow mutliple <main> elements in some of the more reasonable cases we have found but that would discourage some/most of the misuse? Is it something that a validator could check automatically?

    As for using <aside> inside a single <main> instead of multiple <main> elements, what should ATs do when the first element in <main> is an <aside>? If you take existing cases of multiple <main> elements and find their first common parent that would be transformed into a <main> element, I suspect you'll find this situation.

    @foolip
    Member
    foolip commented Sep 30, 2015

    @frex65, can you describe how the experience would be if there was just a single <main> element and the bits of it that aren't actually main content are marked up with <aside>? Does the screen reader offer to skip over those sections, and if so could the screen reader be made to skip to the next <main> element in the same way?

    Also, do you have some examples of sites that have begun using multiple <main> elements in a way that has caused trouble for you?

    @stevefaulkner
    Contributor

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    On 30 September 2015 at 14:38, Philip Jägenstedt notifications@github.com
    wrote:

    @stevefaulkner https://github.com/stevefaulkner do you have a proposed
    wording that would allow mutliple

    elements in some of the more
    reasonable cases we have found but that would discourage some/most of the
    misuse? Is it something that a validator could check automatically?

    my proposed wording would involve redefining whatwg main represnt the main
    content of a document acting as a macro rather than micro container, i
    don't get the sense that the whatwg editors are open to that.

    As for using

    inside a single instead of multiple
    elements, what should ATs do when the first element in is an

    ? If you take existing cases of multiple elements and find their first common parent that would be transformed into a element, I suspect you'll find this situation.

    From a quick look at what could be considered reasonable uses of multiple
    main from the data we have I didn't find this to be the case, but if your
    analysis differs I would be interested.


    Reply to this email directly or view it on GitHub
    #100 (comment).

    @foolip
    Member
    foolip commented Oct 2, 2015

    @stevefaulkner

    My proposed wording would involve redefining whatwg main represnt the main content of a document acting as a macro rather than micro container, i don't get the sense that the whatwg editors are open to that.

    I am interested in validator warnings that would plausibly help prevent much of the mistaken usage of multiple <main> elements but does not complain about the reasonable cases.

    To disallow the micro container usage woud, I presume, amount to disallowing nested <main> elements. However, does that actually catch many of the mistakes we've found? Also, couldn't an AT simply ignore nested <main> elements if that kind of structure isn't helpful to their users?

    From a quick look at what could be considered reasonable uses of multiple main from the data we have I didn't find this to be the case, but if your analysis differs I would be interested.

    I was thinking about http://www.india-topsites.com/, but upon closer inspecting the common parent of the two <main> elements doesn't contain anything else, I thought that "India Top Sites" text was inside it but it is not.

    I am still curious to know why there's any difference, in principle, between multiple <main> elements and using <aside>. It seems to me like AT could turn both into exactly the same user experience, as the both mark interleaved parts of the documents as main or non-main content.

    @stevefaulkner
    Contributor

    On 2 October 2015 at 09:25, Philip Jägenstedt notifications@github.com
    wrote:

    @stevefaulkner https://github.com/stevefaulkner

    My proposed wording would involve redefining whatwg main represnt the main
    content of a document acting as a macro rather than micro container, i
    don't get the sense that the whatwg editors are open to that.

    I am interested in validator warnings that would plausibly help prevent
    much of the mistaken usage of multiple

    elements but does not
    complain about the reasonable cases.

    From the examples of multiple use can you identify/list what you consider
    reasonable cases?

    The example i consider as possible reasonable use cases:

    1. used to mark up discontinuous areas of main content
    2. use 2 mains (1 for mobile, 1 for desktop view) mobile hidden in desktop
      view
    3. should be discouraged, but not forbidden i.e. SHOULD NOT,
    4. should be allowed.

    Current implemented HTML conformance checker requirements for main flag
    error results based on:

    Contexts in which this element can be used:

    Where flow content is expected, but with no article, aside, footer, header
    or nav element ancestors.

    and

    Authors must not include more than one main
    http://www.w3.org/TR/html5/grouping-content.html#the-main-element
    element in a document.

    this could be modified to:

    Contexts in which this element can be used:

    Where flow content is expected, but with no article, aside, footer, header,
    main or nav element ancestors.

    and

    Authors should not include more than one main

    http://www.w3.org/TR/html5/grouping-content.html#the-main-element
    element in a document.

    which would cover all error cases while allowing edge cases, but not
    encouraging proliferation of instances of main in a document.

    To disallow the micro container usage woud, I presume, amount to
    disallowing nested

    elements. However, does that actually catch
    many of the mistakes we've found? Also, couldn't an AT simply ignore nested

    elements if that kind of structure isn't helpful to their users?

    If it is the case that the use of multiple nested mains becomes an issue
    for users then browsers could implement similar rules to the ones in place
    for header/footer, what we don't want to do is encourage the use of


    as both a micro and macro container as its use becomes ambiguous and
    likelyhood of misuse is increased.

    From a quick look at what could be considered reasonable uses of
    multiple main from the data we have I didn't find this to be the case, but
    if your analysis differs I would be interested.

    I was thinking about http://www.india-topsites.com/, but upon closer
    inspecting the common parent of the two

    elements doesn't contain
    anything else, I thought that "India Top Sites" text was inside it but it
    is not.

    I am still curious to know why there's any difference, in principle,
    between multiple

    elements and using . It seems to me like
    AT could turn both into exactly the same user experience, as the both mark
    interleaved parts of the documents as main or non-main content.


    Reply to this email directly or view it on GitHub
    #100 (comment).

    @foolip
    Member
    foolip commented Oct 2, 2015

    From the examples of multiple use can you identify/list what you consider
    reasonable cases?

    We agree on marking up discontinuous bits of content and the desktop/mobile case. I think some cases where the two bits are visually adjacent may also be justifiable where using a single higher-level main would require the use of aside to exclude some preceeding or following non-main siblings.

    I really don't know what to think about the macro/micro issue as exemplified by http://www.homedit.com/ and http://www.homedit.com/fall-welcome-wreath/

    It seems pretty clear that they've attempted to mark up both the main part of the page and the main part of each article, although they excluded the title of each article which seems pretty bad. If this were executed correctly, it's hard to see how having this extra information would be a net negative in this case. It's rather that there might be other crazy uses that cannot be disallowed without also disallowing this usage pattern.

    Authors should not include more than one main

    If the requirement is "downgraded" (from the W3C PoV) like this, would you still expect validators to emit a warning for multiple main elements, or just for nested elements?

    The restrictions under consideration are disallowing main inside article, aside, footer, header, or main itself. The current WHATWG spec makes no such restrictions. I actually can't see why one would have main in aside, footer or header. @Hixie, do you see any plausible use case for that?

    As for main inside article, that seems pretty reasonable, and several such articles in a top-level main also seems sound. What doesn't make sense is one main element as descendent of another with no article or similar in between, that ought to be an authoring mistake we could complain about.

    @stevefaulkner
    Contributor

    On 2 October 2015 at 11:59, Philip Jägenstedt notifications@github.com
    wrote:

    it's hard to see how having this extra information would be a net negative in
    this case
    .

    Users report verbosity issues with landmarks, whenever a landmark start/end
    is encountered all AT that support landmarks announce them and some
    indicate start/end, the more there are, the noisier and less useful they
    become.
    This happened with header/footer inside section/article and with section
    use (misuse) generally. With the former it was mitigated by modifying the
    mapping depending on context. with the latter it was miitigated by
    encouraging the AT that reported sections (only JAWS did) only to report
    them when they have an explicit accessible name.

    From the webaim 2014 survey it is indicated that users prefer less than
    more landmarks: http://webaim.org/projects/screenreadersurvey5/#numlandmarks
    4-6 being the sweetest spot.

    It seems pretty clear that they've attempted to mark up both the main part
    of the page and the main part of each article, although they excluded the
    title of each article which seems pretty bad.

    yes and that's what the current whatwg definition allows. marking up in
    this way, by all reports, is not helpful to users.

    If the requirement is "downgraded" like this, would you still expect
    validators to emit a warning for multiple main elements, or just for nested
    elements?

    I would expect the checker to emit a warning with a link to advice.

    As for main inside article, that seems pretty reasonable

    Given that

    can be used to mark up a single sentence to a 1000
    words or more, it is difficult to say what is reasonable.

    I have written an article about use of html 'landmark' elements which may be
    of interest
    https://www.paciellogroup.com/blog/2015/09/easy-content-organisation-with-html5/

    @foolip
    Member
    foolip commented Oct 2, 2015

    This happened with header/footer inside section/article and with section use (misuse) generally. With the former it was mitigated by modifying the mapping depending on context. with the latter it was miitigated by encouraging the AT that reported sections (only JAWS did) only to report them when they have an explicit accessible name.

    Would it be an option to change the mapping of nested main elements so that they are not treated as landmarks? If

    <header>latest news articles</header>
    <main>
     <article>
      <main>words of importance</main>
      <footer>share on friendface</footer>
     </article>
     <!-- more articles -->
    </main>
    <footer>contact us</footer>

    makes semantic sense and is useful for styling, but it's just empirically true that even well-structured cases make for a worse user experience because of excessive landmarks, simply ignoring some of semantics seems pretty doable.

    I would expect the checker to emit a warning with a link to advice.

    I think that's reasonable in certain cases, at least when multiple non-nested main elements are used an info or warning message recommending fewer landmarks where possible. I also think some cases like main as a direct child of another main are nonsensical and could be outright errors. @sideshowbarker, are you doing any work on the validator, and what's the general thinking on emitting messages when something may be wrong but isn't necessarily so?

    @zcorpan
    Member
    zcorpan commented Oct 2, 2015
    1. use 2 mains (1 for mobile, 1 for desktop view) mobile hidden in desktop view

    The hidden attribute could be used in the conformance requirement to handle this use case.

    e.g. (assuming nested mains are allowed):

    Ignoring main elements that have a main element ancestor, there must [or should] be at most one main element that does not have the hidden attribute set and that has no ancestors with the hidden attribute set."

    @stevefaulkner
    Contributor

    On 2 October 2015 at 12:57, Philip Jägenstedt notifications@github.com
    wrote:

    This happened with header/footer inside section/article and with section
    use (misuse) generally. With the former it was mitigated by modifying the
    mapping depending on context. with the latter it was miitigated by
    encouraging the AT that reported sections (only JAWS did) only to report
    them when they have an explicit accessible name.

    Would it be an option to change the mapping of nested main elements so
    that they are not treated as landmarks? If

    latest news articles words of importance share on friendface contact us

    makes semantic sense and is useful for styling, but it's just empirically
    true that even well-structured cases make for a worse user experience
    because of excessive landmarks, simply ignoring some of semantics seems
    pretty doable.

    Of course, its a possible option, anybody can file a bug on the acc mapping
    spec
    https://www.w3.org/Bugs/Public/enter_bug.cgi?product=ARIA&component=HTML%20AAM

    makes semantic sense and is useful for styling

    it would only be useful for styling AFAICT and I think would unecessarily
    change the meaning/usage of

    as understood by the vast majority of
    developers. So as I said previously it would not be a pattern that I would
    want to encourage or needs encouragement.

    I would expect the checker to emit a warning with a link to advice.

    I think that's reasonable in certain cases, at least when multiple
    non-nested main elements are used an info or warning message recommending
    fewer landmarks where possible. I also think some cases like main as a
    direct child of another main are nonsensical and could be outright errors.
    @sideshowbarker https://github.com/sideshowbarker, are you doing any
    work on the validator, and what's the general thinking on emitting messages
    when something may be wrong but isn't necessarily so?

    I know Mike has implemented a few warnings like this
    capture

    Warning: Section lacks heading. Consider using h2-h6 elements to add identifying headings to all sections.

    @jameswillweb

    The thing that bothers me the most about this discussion is that <main> seems to be moving more towards sectioning content like article and section and away from its intended purpose. Indeed I'd argue that the WHATWG's current definition and understanding of the element place it squarely in that arena. From its outset <main> was intended to address a glaring weakness in HTML that the new semantic elements failed to correct; that there was no way for authors to identify the main area of content and provide a landmark for AT and other devices. @hixie has always argued that the main area of content could be inferred by its lack of markup, that by eliminating content marked up in <aside>, <footer>,<header> and the like the main content would reveal itself. I've always found that reasoning to be fairly absurd, as it places a huge burden of assumption on identifying content and provides no mapping for an existing ARIA role. So it's no secret that he doesn't like the <main> element or agree that it is even necessary. The lazy definition and implementation in the WHATWG specification reflects that.

    So far in this discussion data was provided that shows the <main> element being used in conformance with the W3C definition in about 99% of sampled sites. Instead of seeing this as confirmation that the W3C definition is being adopted by authors, you've chosen to focus on the remaining 1% as edge cases. Likewise users of screen readers have commented in this thread on the utility of main as a unique element and their preference that it stays that way. They have been, for the most part, ignored.

    The edge cases that have been brought forward are, in my opinion, not that strong. Given the markup of

    main
    ad
    main
    ad
    main
    

    the ads would be clearly be better served as asides within an article. The content would be clearer as:

    main
    article
      content
    aside
       content
    aside
      content
    /article
    /main
    

    In almost all cases mentioned with multiple main elements the discussion hinges on content being broken up by interrupting content. In those instances a single main is sufficient to mark the start of the content, and proper semantics and sectioning should be enough to allow the user to navigate through the interruptions. If not, then we should be discussing the development of roles or attributes that support threaded content, as they would be more suited to this task than multiple mains.

    If, in fact there are multiple blocks of discreet content that share equal importance than the main element is not required. So in a case of

    main
    aside
    main
    aside
    main
    

    Where the three main elements represent separate content, either one of them is the main content or none of them are. In that case they would be better represented by:

    article
    aside
    article
    aside
    article
    

    The DOM would handle which article was encountered first and control reading order, no main required.

    Another use case gives a situation where one main is marked up for desktop use and another for mobile. I'm assuming that CSS or JS would be used to show or hide the content based on context. This is a terrible authoring practice and should not be encouraged. Even if the author wishes to limit the viewable content for mobile (a dubious practice) there are simple ways to mark up the contents of a single main and change how it displays based on context.

    By moving main towards an element that allows multiple instances of it per page as well as nested instances of it, you dilute the meaning of it and further confuse authors as to the utility of it compared to article and section. Currently when I query other authors about main the biggest confusion comes from its usage compared to article and section. By broadening its definition to allow it to be used fairly interchangeably with those two sectioning elements you will add to the confusion surrounding the proper use of HTML semantics and negate the usefulness of it's primary purpose, as a clear landmark to AT users.

    @sideshowbarker
    Member

    @sideshowbarker, are you doing any work on the validator, and what's the general thinking on emitting messages when something may be wrong but isn't necessarily so?

    Short answer: The thinking is that it’s doable and has precedent. In this specific case, I could imagine the checker could emit a message something like this:

    Warning: Document contains more than one main element. Documents must not use the main element to mark up content that is not the main content of the document. Ensure that this document is using the main element correctly.

    But if we were to do that, I think we should add some language in the spec to tie that back to; so, something added the spec section on the main element like this:

    Documents must not use the main element to mark up content that is not the main content of the document.


    Longer answer

    As @stevefaulkner mentions, there are a limited number of cases where I’ve experimentally added warnings to the HTML checker that aren’t strictly required by any spec. I consider the question of what particular warnings (as opposed to errors) the checker should emit to be an area where I and other checker implementors have some discretion; that is, I think we can add them when we believe they’re useful, even if we can’t tie them to some specific requirement/language in the spec.

    That said, I’d prefer to always have something in the spec to which a particular warning could be tied.

    So in the case, for example, we could add a statement to the spec something like this:

    Documents must not use the main element to mark up content that is not the main content of the document.

    It could reasonably argued that would be restating the following statement from the spec:

    Authors must not use elements, attributes, or attribute values for purposes other than their appropriate intended semantic purpose, as doing so prevents software from correctly processing the page.

    But I think there are cases with particular elements and attributes where it’s useful to more explicitly state what the particular intended semantic purpose of a given element or attribute is, and this seems to me like one of those cases.

    Anyway, as far as the checker behavior goes, the “Documents must not use the main element to mark up content that is not the main content of the document.” is not machine-testable, so I couldn’t have the checker emit an error for it. But I could have it emit a warning along these lines:

    Warning: Document contains more than one main element. Documents must not use the main element to mark up content that is not the main content of the document. Ensure that this document is using the main element correctly.

    @frex65
    frex65 commented Oct 4, 2015

    I'm losing faith that this argument is about what's best for users.

    The <main> element would be most useful to me, a screenreader user, as a single wrapper around the unique content on the page, usually found between the header/navigation and the footer. If I need to trawl through the document in search of <main> elements, then I'm losing my alternative to your visual clue that we're moving from navigation down to main content, then off main content and down into the footer. It's forcing me to spend more time understanding how the page is organised. My head hurts just thinking about it.

    If the <main> element was created to make AT users' lives easier, then surely the most sensible thing to do here would be to read AT users' comments and act on them. I don't understand what the problem is. If there's an aside or a section or an article within the main content, then use the appropriate element to mark it up. But please don't rehash the old HTML4 confusion by taking away or watering down the only structural cue to flag up the start and end of main content that HTML has to offer.

    I hope someone from WHATWG is really listening, and that this hasn't just become a battle of wills or personalities or semantics.

    @sinabahram

    I must say that I’m also both concerned and saddened at the nature of this conversation. You have almost two dozen users and experts in accessibility from a variety of backgrounds all saying the same thing. to put this in perspective, we accessibility folks rarely all agree this much on a single subject, and yet every single one of those voices has been essentially summarily ignored.

    If that’s the point, and the argument is that the WHATWG does not care about users, I wish someone would simply say so, not so as to put WHATWG in a negative light, but just to save those of us who work tirelessly to make the web more usable by, and inclusive to, all some time.

    This isn’t meant as an attack on any member of WHATWG, but the fact remains that the recommendation harms persons with disabilities, and in no convincing way helps authors create artifacts for persons without.

    To that end, I ask if there is a reason we are bothering to continue, at this point?

    It seems that the responsible thing to do by the user is to start educating authors about the dangers of following WHATWG rather strongly and rather prolifically, since we obviously cannot reach an agreement on such a simple element that was put in place to help users of AT.

    @foolip
    Member
    foolip commented Oct 5, 2015

    Let me try to summarize some points that I don't think are contested:

    • The main element is rarely used.
    • When it is used, a single main element is roughly 100 times as common as multiple main elements.
    • The tiny fraction of multiple main elements is all that we are discussing, as pages with zero or one main element are not affected by any of the suggested changes.
    • Currently, all main elements map to the main landmark.
    • Screenreader users report that too many landmarks is a problem, and that a single main landmark is preferable.
    • When looking at pages using multiple main elements, the following were found:
      • Cases which make no semantic sense by any definition.
      • Cases that could quite easily be merged into a single main element.
      • Cases where merging them would require marking up other parts of the page as aside or similar.
      • One case of two main elements (desktop/mobile) where it was intended that one would always be hidden.
      • Some use of nested main elements inside article that makes semantic sense, but doesn't seem useful landmark-wise.
    • There is precedent for validator warnings for things that aren't strictly disallowed but easy to get wrong.

    (Summary only, no conclusion for now.)

    @stevefaulkner
    Contributor

    On 5 October 2015 at 11:55, Philip Jägenstedt notifications@github.com
    wrote:

    Let me try to summarize some points that I don't think are contested:

    • The main element is rarely used.

    The

    element is not widely used yet, it has not been around that
    long. It's use may appear more prevalent to screen reader users as
    and are exposed the same in the accessibility tree and
    are expressed in the aural UI the same.

    Perceptions of usage can also be skewed by the use on sites that are
    visited regularly, for example

    google.com
    https://www.google.com/webhp?ie=utf-8&oe=utf-8#q=main+definition
    https://www.facebook.com/ web UI
    twitter web UI
    yahoo.com
    linkedin

    All use

    (along with other divs with roles to markup other
    landmark regions).

    (Edited by @foolip to fix broken quoting/markup.)

    @stevefaulkner
    Contributor

    On 5 October 2015 at 11:55, Philip Jägenstedt notifications@github.com
    wrote:

    • The main element is rarely used.

    Not meaning to belabour the point, but the element was introduced
    around the same time as

    , doing a grep of the usual data, I could
    only find 5 pages out of 20,000 where it was used. I would have no issue
    with characterzing as 'rarely used'...yet

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    @foolip
    Member
    foolip commented Oct 5, 2015

    Its use may appear more prevalent to screen reader users as <div role="main"> and <main> are exposed the same in the accessibility tree and are expressed in the aural UI the same.

    Yeah, that seems plausible. If multiple main elements were the whole problem, very few people ought to have noticed it at all in their day-to-day browsing.

    @stevefaulkner
    Contributor

    On 5 October 2015 at 16:04, Philip Jägenstedt notifications@github.com
    wrote:

    Yeah, that seems plausible. If multiple main elements were the whole
    problem, very few people ought to have noticed it at all in their
    day-to-day browsing.

    I looked at use of role="main" as well, single vs multiple is around 97.5%
    single 2.5% multiple. I don't get the feeling that mutliple mains are
    currently a big problem, but we don't want them to become one.

    We currently have a native HTML element that serves its function well and
    is used appropriately in the vast majority of cases. It's generally agreed
    meaning is well understood by users and developers alike. Why are we here
    trying to complicate it for edge case uses that are just as well served by
    class="main"?

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    @aardrian
    aardrian commented Oct 5, 2015

    @foolip, I'd like to put on record that I disagree with two assertions you have made:

    • One case of two main elements (desktop/mobile) where it was intended that one would always be hidden.

    Regardless of the intent, this would be better (and IMO more correctly served) as two elements nested within a <main>. I understand you are simply re-stating an example from the data, but it's an example of incorrect use and I don't think it warrants its own bullet in your list.

    • Some use of nested main elements inside article that makes semantic sense, but doesn't seem useful landmark-wise.

    I also disagree that this makes semantic sense. While, again, this is from an example in the data, it's an example of incorrect and confusing use that we should be working to document as such.

    In my experience, when one allows incorrect statements to stand unchallenged, they get referenced as truth later. I couldn't let them go unchallenged.

    @foolip
    Member
    foolip commented Oct 5, 2015

    @aardrian, you're right that the desktop/mobile case could be rewritten, but I list it separately because unlike the other cases it wouldn't actually result in multiple main landmarks presented to the user. As for the nested case, an article really can have a header, main part and footer, semantically and visually. It doesn't follow that we must allow nested main elements for this, however.

    @foolip
    Member
    foolip commented Oct 5, 2015

    @stevefaulkner, is http://w3c.github.io/aria/html-aam/html-aam.html the only document one needs to read to understand existing mappings? I see that Blink has some special rules for header and footer (they are given no special role when inside article or section) but I can't see this in the spec.

    @stevefaulkner
    Contributor

    @foolip

    is http://w3c.github.io/aria/html-aam/html-aam.html the only document one needs to read to understand existing mappings?

    these are expressed in terms of the API mappings
    http://w3c.github.io/aria/html-aam/html-aam.html#el-header
    http://w3c.github.io/aria/html-aam/html-aam.html#el-footer

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    On 5 October 2015 at 17:34, Philip Jägenstedt notifications@github.com
    wrote:

    @stevefaulkner https://github.com/stevefaulkner, is
    http://w3c.github.io/aria/html-aam/html-aam.html the only document one
    needs to read to understand existing mappings? I see that Blink has some
    special rules for header and footer (they are given no special role when
    inside article or section) but I can't see this in the spec.


    Reply to this email directly or view it on GitHub
    #100 (comment).

    @foolip
    Member
    foolip commented Oct 5, 2015

    Ah, thanks. Is the philosophy with these mappings to assume that the document is conforming and to only have extra rules to change the roles where the conforming markup still isn't useful?

    @domenic
    Member
    domenic commented Oct 5, 2015

    @frex65 thanks for your user experience report. I got confused at the end though:

    Then some authors began splitting the unique content out across multiple

    elements, and I began to lose confidence that my new foolproof navigation strategy would work. So after my AT told me I'd reached the end of the main content, I'd listen to my screenreader babbling on with social networking links and ads and other stuff that was probably in the footer, because I was afraid there might be another or
    or some other random element coming up that would contain important or interesting content.

    What is wrong with the strategy of going to the next

    element once you reach the end of the first one? That seems to be exactly what you're looking for, since it allows you to avoid listening to the social networking and ads and footer and stuff, and skip straight to the next block of main content.

    @stevefaulkner
    Contributor

    On 5 October 2015 at 20:15, Philip Jägenstedt <notifications@github.com
    javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

    Is the philosophy with these mappings to assume that the document is
    conforming and to only have extra rules to change the roles where the
    conforming markup still isn't useful?

    The philosophy of the spec is to document what is implemented, get
    agreement on interoperable implementations where there is differences and
    work with implementers to reach agreement on sane acc mappings for new
    HTML features and to modify existing implementation, where practical if
    usage of the feature dictates that the current mappings do not produce the
    best outcomes for users.

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    @foolip
    Member
    foolip commented Oct 5, 2015

    OK, very well. I note that the HTML spec disallows main inside header and footer, and the mapping spec doesn't make any corresponding adjustment of the role, so I suspected there was an "assume validity" design principle here.

    @stevefaulkner
    Contributor

    On 5 October 2015 at 20:49, Philip Jägenstedt notifications@github.com
    wrote:

    OK, very well. I note that the HTML spec disallows main inside header and
    footer, and the mapping spec doesn't make any corresponding adjustment of
    the role, so I suspected there was an "assume validity" design principle
    here.

    right, we try to keep the browser mapping implementation requirements
    simple unless there is a demonstrated reason to complicate them.

    Regards

    SteveF
    Current Standards Work @W3C
    http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

    @frex65
    frex65 commented Oct 15, 2015

    @domenic:
    You can glance at a page and straight away know which block contains the main content. That's usually down to positioning. It doesn't matter whether that block contains asides (adverts or whatever) - it's still a single container of main content.
    I don't have that luxury. Positioning doesn't work for me because I can't see where things are on the screen.
    A single <main> container, imo, is as close as we will get to an alternative. It says to me in big block capitals: "OK, stay inside this container and you'll find all of the main page content. Don't worry, if there's something that falls outside main content, like an ad, it'll be marked up as an aside so you can skip past it".
    If more than one <main> element is allowed, it immediately loses its usefulness.
    With all due respect, if the <main> element was created to make the lives of AT users easier, and not a single AT user who's commented on this thread feels that multiple <main> elements would work for them, why isn't this enough to convince you? Why do WHATWG proponents feel the need to continue to argue the case for multiple <main>'s?
    To me, the styling argument has no legs, since any element can be used as a styling hook. So it would be good to put that argument to bed.

    @domenic
    Member
    domenic commented Oct 15, 2015

    @frex65

    You can glance at a page and straight away....

    These two paragraphs don't seem to have anything to do with my question. Am I misunderstanding? I will repeat it here just in case:

    What is wrong with the strategy of going to the next

    element once you reach the end of the first one? That seems to be exactly what you're looking for, since it allows you to avoid listening to the social networking and ads and footer and stuff, and skip straight to the next block of main content.


    If more than one

    element is allowed, it immediately loses its usefulness.

    You have made this claim several times, but not explained to us why. There are a lot of pages that have more than one area of main content. Are you asking us to advise against those pages existing, and say that pages authored that way are never conformant with HTML? That doesn't really seem feasible. It seems better to acknowledge how pages are laid out in the real world and create tools, like multiple-

    , that allow accessible access to all the main parts of a page.

    With all due respect, if the

    element was created to make the lives of AT users easier, and not a single AT user who's commented on this thread feels that multiple elements would work for them, why isn't this enough to convince you?

    Arguments from authority don't hold weight in the WHATWG. You cannot say "since I belong to group X, my opinion is correct." We're trying instead to get arguments of the form "I belong to group X, and when pages are marked up in this way, it causes concrete harm Y to me and others in group X, for reason Z." But you have so far refused to tell us what the concrete harm is, instead simply stating flat-out "it loses its usefulness." Why? Can you explain why all usefulness is lost, when the second portion of the main content is marked up with

    ? Would it be better to have that portion be marked up with a
    ?

    Why do WHATWG proponents feel the need to continue to argue the case for multiple

    's?

    I am equally baffled by the insistence on a single

    . It seems very narrow-minded to say that a page can only have one main area. @Hixie has already pointed out how that fails to match pages as popular as CNN.com.

    I understand your preferred markup pattern might be to move the

    to the top level, encompassing all the main content sections, and put non-main content in an or or . But we already have a tag for that: . Should we just say that authors must always use <body><main></main></body> now, instead of just <body></body>? That seems unproductive.

    @nschonni

    I'm not actually seeing any <main> tags on CNN.com. Checked the following:

    @johnfoliot

    @domenic asks:

    "You have made this claim several times, but not explained to us why."

    I think this thread, and the comments made by screen reader users in particular, have explained why; you seem instead to be arguing somehow that they are wrong, that Hixie better understands the needs of persons with disabilities than those actual users. It's not an uncommon problem, and he's been quite wrong on that topic in the past, so there is no surprise here either. Perhaps an analogy will help: There is a problem in your house, and you've been told to shut off the main power switch. If you have 5 main switches, which one do you shut off? Which one is the main one?

    Screen readers use this element to navigate to the main content, which is the central reason or purpose of the document. The definition of main, as a noun, is: "the chief or principal part or point". (http://dictionary.reference.com/browse/main) The implied understanding, relevant here, is that the principle or chief part is a singular instance, and clearly, based on feedback from the user-community, this is what is wanted and expected. Arguing that technically you can have more than 1 <main> element is missing the point - it's a question of usability, as explained and experienced by users who are directly affected by the use of this element. Anything else is debating-gymnastics.

    In the end, if you really feel compelled to use multiple <main> elements, nobody can stop you, and you can go ahead and do so - there is no law against crappy code. But ask yourself why are you using that element, and if you answer "to help non-sighted users navigate the document structure" then those users have been pretty unanimous on what they want and expect. Feel free to ignore that feedback as you choose (clearly Hixie has), but don't then be surprised if those same users find your document less user-friendly.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment