Consider aligning WHATWG main element definition with W3C definition

[stevefaulkner]

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:

• main element
• body element

[foolip]

@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]

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]

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]

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]

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]

From a quick partial grep of the latest webdevdata files (jan 2015) 20,000 pages 218 with <main> 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]

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]

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]

@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]

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]

(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]

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]

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]

@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]

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]

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]

@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]

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

[stevefaulkner]

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

[domenic]

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]

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]

@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]

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

https://github.com/whatwg/html/issues/100#issuecomment-137782076

[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]

@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]

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]

<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]

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]

@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]

@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]

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.

[ZoeBijl]

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

[DavidMacDonald]

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]

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]

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]

@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?