New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider aligning WHATWG main element definition with W3C definition #100

Closed
stevefaulkner opened this Issue Sep 4, 2015 · 181 comments

Comments

@stevefaulkner
Contributor

stevefaulkner commented Sep 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip Sep 4, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@Hixie

Hixie Sep 4, 2015

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Sep 4, 2015

Member

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?

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

This comment has been minimized.

Show comment
Hide comment
@Heydon

Heydon 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.

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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Sep 4, 2015

Member

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 :)

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

This comment has been minimized.

Show comment
Hide comment
@sinabahram

sinabahram Sep 4, 2015

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.

sinabahram commented Sep 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Sep 4, 2015

Contributor

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/

Contributor

stevefaulkner commented Sep 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Sep 4, 2015

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@bramd

bramd 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.

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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Sep 4, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@sinabahram

sinabahram Sep 4, 2015

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.

sinabahram commented Sep 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Sep 4, 2015

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Sep 5, 2015

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.

Contributor

stevefaulkner commented Sep 5, 2015

(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

This comment has been minimized.

Show comment
Hide comment
@CuriousNetEntity

CuriousNetEntity Sep 6, 2015

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.

CuriousNetEntity commented Sep 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson 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.

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Sep 8, 2015

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.

DavidMacDonald commented Sep 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Hixie

Hixie Sep 8, 2015

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Sep 9, 2015

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.

Contributor

stevefaulkner commented Sep 9, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@karlgroves

karlgroves Sep 9, 2015

@Hixie says "a street of hotels?"

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

karlgroves commented Sep 9, 2015

@Hixie says "a street of hotels?"

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

@MarcoZehe

This comment has been minimized.

Show comment
Hide comment
@MarcoZehe

MarcoZehe Sep 9, 2015

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

MarcoZehe commented Sep 9, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@BimEgan

BimEgan 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.

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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Sep 9, 2015

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Sep 9, 2015

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.

Contributor

stevefaulkner commented Sep 9, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Sep 9, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Sep 9, 2015

Contributor

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

Contributor

stevefaulkner commented Sep 9, 2015

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

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Sep 9, 2015

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Sep 9, 2015

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.

Contributor

stevefaulkner commented Sep 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@karlgroves

karlgroves Sep 9, 2015

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?

karlgroves commented Sep 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Sep 9, 2015

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.

Contributor

stevefaulkner commented Sep 9, 2015

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

@dstorey

This comment has been minimized.

Show comment
Hide comment
@dstorey

dstorey Jan 6, 2018

Member

For what it’s worth, I also support one main element per document.

We also use it that way on Edge sites, with article (or section depending on the content) for the blocks of content within.

Member

dstorey commented Jan 6, 2018

For what it’s worth, I also support one main element per document.

We also use it that way on Edge sites, with article (or section depending on the content) for the blocks of content within.

@shelleyp

This comment has been minimized.

Show comment
Hide comment
@shelleyp

shelleyp Jan 6, 2018

I give directions to a person entering a corporate campus. "See the receptionist in the Main building", I tell them.

WhatWG: The person is still walking around the campus, confused as to which Main building they should enter.

A plumber tells me I have a potential blockage in the main pipe, and sends a worker to fix it.

WhatWG: The worker is still mopping up, not able to differentiate which main pipe has the blockage.

I have many more. See the following page for relevant examples. It shouldn't be the intent of the HTML process to redefine the semantics of commonly occurring words. When used for directional purposes, there should be only one "main". When used to clarify selection, there should be only one "main".

If a document is the entity being described, it should have one main element. Especially when there are other elements that can accurately define other content. If you need more main elements, then most likely, you need more documents.

http://www.manythings.org/sentences/words/main/1.html

shelleyp commented Jan 6, 2018

I give directions to a person entering a corporate campus. "See the receptionist in the Main building", I tell them.

WhatWG: The person is still walking around the campus, confused as to which Main building they should enter.

A plumber tells me I have a potential blockage in the main pipe, and sends a worker to fix it.

WhatWG: The worker is still mopping up, not able to differentiate which main pipe has the blockage.

I have many more. See the following page for relevant examples. It shouldn't be the intent of the HTML process to redefine the semantics of commonly occurring words. When used for directional purposes, there should be only one "main". When used to clarify selection, there should be only one "main".

If a document is the entity being described, it should have one main element. Especially when there are other elements that can accurately define other content. If you need more main elements, then most likely, you need more documents.

http://www.manythings.org/sentences/words/main/1.html

@Heydon

This comment has been minimized.

Show comment
Hide comment
@Heydon

Heydon Jan 7, 2018

The issue is that there is no clear one main part of the document on a blog front page. There are multiple articles, each with a main part, which users may want to cycle between.

You are redefining what <main> is in order to make your case. It was not specced for the use case you describe, there is no evidence that it is a use case users want, and it is a use case covered by other HTML/AT behavior as I described elsewhere in the thread.

@domenic Given the intended purpose of <main> and the overwhelming support that this purpose is only fulfilled in its singular form, can you agree that the WHATWG spec' needs to reflect this?

Heydon commented Jan 7, 2018

The issue is that there is no clear one main part of the document on a blog front page. There are multiple articles, each with a main part, which users may want to cycle between.

You are redefining what <main> is in order to make your case. It was not specced for the use case you describe, there is no evidence that it is a use case users want, and it is a use case covered by other HTML/AT behavior as I described elsewhere in the thread.

@domenic Given the intended purpose of <main> and the overwhelming support that this purpose is only fulfilled in its singular form, can you agree that the WHATWG spec' needs to reflect this?

@frex65

This comment has been minimized.

Show comment
Hide comment
@frex65

frex65 Jan 7, 2018

frex65 commented Jan 7, 2018

@Heydon

This comment has been minimized.

Show comment
Hide comment
@Heydon

Heydon Jan 7, 2018

@frex65 I hear you, big time!

Heydon commented Jan 7, 2018

@frex65 I hear you, big time!

@MarcoZehe

This comment has been minimized.

Show comment
Hide comment
@MarcoZehe

MarcoZehe Jan 7, 2018

MarcoZehe commented Jan 7, 2018

@Heydon

This comment has been minimized.

Show comment
Hide comment
@Heydon

Heydon Jan 7, 2018

The WHATWG position now appears to be:

"You have to provide more data and evidence for the formulation of the element you specced, but we don't have to provide anything."

EDIT: At least in so far as what @domenic has written.

Even without the evidence of AT usage, a singular <main> paves the cowpath that authors use class="content" orid="maincontent"` etc. Essentially what's happening here is this:

"We are following what users and designer seems to — and have told us they — want and building a bus."
"That's okay, but have you considered a washing machine?"
"Wait... what, why would you want a washing machine for this?"
"Let me tell you how a washing machine would work..."

Heydon commented Jan 7, 2018

The WHATWG position now appears to be:

"You have to provide more data and evidence for the formulation of the element you specced, but we don't have to provide anything."

EDIT: At least in so far as what @domenic has written.

Even without the evidence of AT usage, a singular <main> paves the cowpath that authors use class="content" orid="maincontent"` etc. Essentially what's happening here is this:

"We are following what users and designer seems to — and have told us they — want and building a bus."
"That's okay, but have you considered a washing machine?"
"Wait... what, why would you want a washing machine for this?"
"Let me tell you how a washing machine would work..."

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 7, 2018

Member

I don't think there's a WHATWG position as I disagree with Domenic. I've pressed him on the same point, in private, and will continue to do so.

I should probably not have tuned out of this discussion back when it started as much as I did and pushed Ian too. I remember finding the revised definition of main weird as well as the continued insistence that browsers/AT could be made better despite not seeing any investment toward that (in terms of figuring out the hand-waved algorithms and working with folks to get them implemented).

I'm sorry it took so long, but I'm hopeful we can get this much closer to something satisfactory for everyone soonish.

Member

annevk commented Jan 7, 2018

I don't think there's a WHATWG position as I disagree with Domenic. I've pressed him on the same point, in private, and will continue to do so.

I should probably not have tuned out of this discussion back when it started as much as I did and pushed Ian too. I remember finding the revised definition of main weird as well as the continued insistence that browsers/AT could be made better despite not seeing any investment toward that (in terms of figuring out the hand-waved algorithms and working with folks to get them implemented).

I'm sorry it took so long, but I'm hopeful we can get this much closer to something satisfactory for everyone soonish.

@aardrian

This comment has been minimized.

Show comment
Hide comment
@aardrian

aardrian Jan 7, 2018

@frex65

Am I the only screenreader user on this thread? Can anyone hear me?

Your question may be rhetorical, but either way I think it is worth reminding everyone that lots of screen reader users have commented on this thread over two years and all both understand and prefer a single <main> on a page. The only people/person challenging it are those who do not use a screen reader and therefore cannot truly comprehend the benefit. That is the only reason this is still open.

aardrian commented Jan 7, 2018

@frex65

Am I the only screenreader user on this thread? Can anyone hear me?

Your question may be rhetorical, but either way I think it is worth reminding everyone that lots of screen reader users have commented on this thread over two years and all both understand and prefer a single <main> on a page. The only people/person challenging it are those who do not use a screen reader and therefore cannot truly comprehend the benefit. That is the only reason this is still open.

@foolip

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip Jan 7, 2018

Member

About @domenic's #100 (comment):

The issue is still, as pointed out, pages where there are legitimately multiple main sections. I agree just using it as a generic container for "main content of something" can be an issue. But e.g. a page broken up by advertisements, or a blog front page with multiple articles where you'd want to skip past the non-main parts, is a legitimate use of multiple mains.

If we were to make <main> inside <article> work well, it would be by making the role mapping of <main> different when nested inside certain other elements, as @stevefaulkner pointed out in #100 (comment) is already the case for <header> and <footer>.

I found the code for this in Chromium. The elements within which <header> and <footer> are just generic containers are <article>, <aside>, <nav>, <section>, <blockquote>, <details>, <fieldset>, <figure>, <td>, and <main>.

Doing this for <main> too would be straightforward code-wise, but it seems quite likely that some pages that use a single main happen to have it inside a top-level <section> or a <td> used for layout, which would then break. So research would be required, and it might be too late for a definition that's consistent with <header> and <footer>.

As for what advice to give to web developers on something like MDN or https://html.spec.whatwg.org/dev/, recommending a single <main> element and not focusing on other usages that may be allowed seems best, especially if in those other usages the <main> loses its semantics and accessibility role and is just a styling hook.

But we still have to decide what markup is valid, and per #100 (comment) it seems like a bad idea to simply make multiple <main> elements invalid. I think the hard cases are:

  • 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.

@annevk, do you already have some changes in mind here?

Member

foolip commented Jan 7, 2018

About @domenic's #100 (comment):

The issue is still, as pointed out, pages where there are legitimately multiple main sections. I agree just using it as a generic container for "main content of something" can be an issue. But e.g. a page broken up by advertisements, or a blog front page with multiple articles where you'd want to skip past the non-main parts, is a legitimate use of multiple mains.

If we were to make <main> inside <article> work well, it would be by making the role mapping of <main> different when nested inside certain other elements, as @stevefaulkner pointed out in #100 (comment) is already the case for <header> and <footer>.

I found the code for this in Chromium. The elements within which <header> and <footer> are just generic containers are <article>, <aside>, <nav>, <section>, <blockquote>, <details>, <fieldset>, <figure>, <td>, and <main>.

Doing this for <main> too would be straightforward code-wise, but it seems quite likely that some pages that use a single main happen to have it inside a top-level <section> or a <td> used for layout, which would then break. So research would be required, and it might be too late for a definition that's consistent with <header> and <footer>.

As for what advice to give to web developers on something like MDN or https://html.spec.whatwg.org/dev/, recommending a single <main> element and not focusing on other usages that may be allowed seems best, especially if in those other usages the <main> loses its semantics and accessibility role and is just a styling hook.

But we still have to decide what markup is valid, and per #100 (comment) it seems like a bad idea to simply make multiple <main> elements invalid. I think the hard cases are:

  • 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.

@annevk, do you already have some changes in mind here?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 8, 2018

Member

My thinking is as @stevefaulkner said elsewhere: that we make a single main element a "should". When <main> is used in conjunction with the hidden attribute, you can use multiple main elements as long as only one of the lacks the hidden attribute and this would not violate the "should". That way you allow for single-page applications and the desktop/mobile use case.

Having said that, I'd be comfortable with making that "should" a "must" and seeing if we get feedback that is prohibitive somehow. I'm rather doubtful we'd get any since I haven't really seen any advocacy for multiple main elements other than for single-page applications (where you can use hidden), but I'm not aware of everything that's going on on the web.

Member

annevk commented Jan 8, 2018

My thinking is as @stevefaulkner said elsewhere: that we make a single main element a "should". When <main> is used in conjunction with the hidden attribute, you can use multiple main elements as long as only one of the lacks the hidden attribute and this would not violate the "should". That way you allow for single-page applications and the desktop/mobile use case.

Having said that, I'd be comfortable with making that "should" a "must" and seeing if we get feedback that is prohibitive somehow. I'm rather doubtful we'd get any since I haven't really seen any advocacy for multiple main elements other than for single-page applications (where you can use hidden), but I'm not aware of everything that's going on on the web.

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Jan 8, 2018

Contributor

did a new HTML data crawl from top 100,000 sites - will be publicly available soon
back of packet results for <main> usage on 58,000 sites:
5.1% use where used
98.9% = 1 per page
1.1% = 2- 29 per page
Note: this does not include data on role=main
latest data set 2018-01-05 (1.3 Gb) 120,000 pages approx.

Contributor

stevefaulkner commented Jan 8, 2018

did a new HTML data crawl from top 100,000 sites - will be publicly available soon
back of packet results for <main> usage on 58,000 sites:
5.1% use where used
98.9% = 1 per page
1.1% = 2- 29 per page
Note: this does not include data on role=main
latest data set 2018-01-05 (1.3 Gb) 120,000 pages approx.

@foolip

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip Jan 8, 2018

Member

@annevk, @sideshowbarker, would "should" vs. "must" make a difference to what a validator says?

Member

foolip commented Jan 8, 2018

@annevk, @sideshowbarker, would "should" vs. "must" make a difference to what a validator says?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 8, 2018

Member

@foolip warning versus error, as I understand it.

Member

annevk commented Jan 8, 2018

@foolip warning versus error, as I understand it.

@foolip

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip Jan 8, 2018

Member

For people who, like me, were confused by where all the old discussion has gone, search for "items not shown" to expand ~60 comments. That's where @stevefaulkner and I look at a lot of pages in detail, and what I'm referring to in #100 (comment).

I expect that if we took a new look today, we'd still find "Cases where merging them would require marking up other parts of the page as aside or similar."

Member

foolip commented Jan 8, 2018

For people who, like me, were confused by where all the old discussion has gone, search for "items not shown" to expand ~60 comments. That's where @stevefaulkner and I look at a lot of pages in detail, and what I'm referring to in #100 (comment).

I expect that if we took a new look today, we'd still find "Cases where merging them would require marking up other parts of the page as aside or similar."

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Jan 8, 2018

Contributor

@foolip wrote:

I expect that if we took a new look today, we'd still find "Cases where merging them would require marking up other parts of the page as aside or similar."

As previous and current data indicates these cases are very few and far between, why would we want to encourage or accommodate such cases where there is no evidence that they improve user experience? It's not as if developers don't have other markup choices in these instances.

Contributor

stevefaulkner commented Jan 8, 2018

@foolip wrote:

I expect that if we took a new look today, we'd still find "Cases where merging them would require marking up other parts of the page as aside or similar."

As previous and current data indicates these cases are very few and far between, why would we want to encourage or accommodate such cases where there is no evidence that they improve user experience? It's not as if developers don't have other markup choices in these instances.

@shelleyp

This comment has been minimized.

Show comment
Hide comment
@shelleyp

shelleyp Jan 8, 2018

Taking a look at the source of the pages Steve displayed, it seems like the web developers are treating main as synonymous with article (thoughtcatalog.com and baltana.com), or just some kind of silly putty inserted for grins and giggles (worldofwarships.com and umr.com).

Point of fact, some of these look like they're based on the same template, or by the same developers (the ones that directly nest main elements in article).

We don't want to encourage this type of markup, do we? Forget the mess it would create for a screen reader—the use of the main element in these pages make no sense. There's no logic to the use.

Ugh.

shelleyp commented Jan 8, 2018

Taking a look at the source of the pages Steve displayed, it seems like the web developers are treating main as synonymous with article (thoughtcatalog.com and baltana.com), or just some kind of silly putty inserted for grins and giggles (worldofwarships.com and umr.com).

Point of fact, some of these look like they're based on the same template, or by the same developers (the ones that directly nest main elements in article).

We don't want to encourage this type of markup, do we? Forget the mess it would create for a screen reader—the use of the main element in these pages make no sense. There's no logic to the use.

Ugh.

@joe-watkins

This comment has been minimized.

Show comment
Hide comment
@joe-watkins

joe-watkins Jan 8, 2018

Here's a look at one of those pages using VoiceOver's landmarks menu. It's odd -- they use a single <main class="content">..</main> up the DOM a bit... but the landmark gets watered down with the repetition / misuse.

Screen capture showing VoiceOver landmarks menu consisting of over 20 main landmarks as options.

joe-watkins commented Jan 8, 2018

Here's a look at one of those pages using VoiceOver's landmarks menu. It's odd -- they use a single <main class="content">..</main> up the DOM a bit... but the landmark gets watered down with the repetition / misuse.

Screen capture showing VoiceOver landmarks menu consisting of over 20 main landmarks as options.

@foolip

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip Jan 9, 2018

Member

@stevefaulkner wrote:

As previous and current data indicates these cases are very few and far between, why would we want to encourage or accommodate such cases where there is no evidence that they improve user experience? It's not as if developers don't have other markup choices in these instances.

I don't think the spec (or MDN) should encourage multiple main elements, it's a rare case that need not be emphasized even if left conforming.

Seeing "98.9%", I am tempted to repeat #100 (comment) and onward, to look for the sensible cases instead of the worst, but let's not go another round. Apart from the <main hidden> case, I think the only possibilities are the the main content is contiguous or that it's not. If not, it will always be possible to make the closest common ancestor the <main> element and mark up any leading, in-between and trailing bits with <aside> or similar. A leading <aside> would be weird, but should be possible to avoid with further tweaking.

I'm in favor of the "should" option in #100 (comment), perhaps with <div hidden><main> also treated as hidden.

Member

foolip commented Jan 9, 2018

@stevefaulkner wrote:

As previous and current data indicates these cases are very few and far between, why would we want to encourage or accommodate such cases where there is no evidence that they improve user experience? It's not as if developers don't have other markup choices in these instances.

I don't think the spec (or MDN) should encourage multiple main elements, it's a rare case that need not be emphasized even if left conforming.

Seeing "98.9%", I am tempted to repeat #100 (comment) and onward, to look for the sensible cases instead of the worst, but let's not go another round. Apart from the <main hidden> case, I think the only possibilities are the the main content is contiguous or that it's not. If not, it will always be possible to make the closest common ancestor the <main> element and mark up any leading, in-between and trailing bits with <aside> or similar. A leading <aside> would be weird, but should be possible to avoid with further tweaking.

I'm in favor of the "should" option in #100 (comment), perhaps with <div hidden><main> also treated as hidden.

@AliceWonderMiscreations

This comment has been minimized.

Show comment
Hide comment
@AliceWonderMiscreations

AliceWonderMiscreations Jan 9, 2018

It's funny, when I asked for DANE validation of TLS certificates to be added to browsers, and I asked loud enough to actually get responses from Google and FireFox developers, the answer was always that the merits of DNSSEC and DANE didn't really matter because most sites were not using DNSSEC so there was no point in adding DANE validation to the browsers.

But with the main element, even though the vast majority of statistics show that the use of more than one main element is very rare, the WhatWG wants to hang on to it. A group made up of the same coalition of browsers that didn't want DANE because it wasn't being used.

More than one region landmark on a page is desirable and heavily used, but how many web pages legitimately have more than one main section? It doesn't seem logical to continue supporting what definitely causes confusion and is seldom used.

What problem is solved with more than one main that can't be solved by using appropriate region landmarks that aren't main?

AliceWonderMiscreations commented Jan 9, 2018

It's funny, when I asked for DANE validation of TLS certificates to be added to browsers, and I asked loud enough to actually get responses from Google and FireFox developers, the answer was always that the merits of DNSSEC and DANE didn't really matter because most sites were not using DNSSEC so there was no point in adding DANE validation to the browsers.

But with the main element, even though the vast majority of statistics show that the use of more than one main element is very rare, the WhatWG wants to hang on to it. A group made up of the same coalition of browsers that didn't want DANE because it wasn't being used.

More than one region landmark on a page is desirable and heavily used, but how many web pages legitimately have more than one main section? It doesn't seem logical to continue supporting what definitely causes confusion and is seldom used.

What problem is solved with more than one main that can't be solved by using appropriate region landmarks that aren't main?

annevk added a commit that referenced this issue Jan 15, 2018

Adjust the definition of the main element and various examples
This changes examples involving the main element as they do not lead to a good experience with assistive technology.

It also adjusts the definition of the main element a bit and suggests it's best to be used at most once.

See #100 for context.

annevk added a commit that referenced this issue Jan 15, 2018

Restrict the main element to be used once per document
Multiple main elements are still allowed if all but one have the hidden attribute set.

This also slightly alters the definition of the body element as it effectively encompasses all content of a document, except for some metadata.

Fixes #100.
@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 15, 2018

Member

#3354 contains what I believe is the correct fix for this issue. Review welcome.

I have one minor quibble though with the semantics argument. Context is important for semantics. I think it would have been fine if the main element were implemented in a more contextual manner, similar to the header and footer elements, to be able to use it in more places (again, just like those other elements). A document can have a header, and so can an article, and a section. Similarly, a document can have a main portion, and so can an article, and a section. Given that the main element is not implemented in such a manner however it makes sense to restrict it to just documents (as the PR does).

If the main element at some point in the future were to be implemented more contextually I think it would be fine to allow it to be used similar to header and footer elements.

Member

annevk commented Jan 15, 2018

#3354 contains what I believe is the correct fix for this issue. Review welcome.

I have one minor quibble though with the semantics argument. Context is important for semantics. I think it would have been fine if the main element were implemented in a more contextual manner, similar to the header and footer elements, to be able to use it in more places (again, just like those other elements). A document can have a header, and so can an article, and a section. Similarly, a document can have a main portion, and so can an article, and a section. Given that the main element is not implemented in such a manner however it makes sense to restrict it to just documents (as the PR does).

If the main element at some point in the future were to be implemented more contextually I think it would be fine to allow it to be used similar to header and footer elements.

@annevk annevk closed this in #3354 Jan 23, 2018

annevk added a commit that referenced this issue Jan 23, 2018

Restrict the main element to be used once per document
Multiple main elements are still allowed if all or all but one have the hidden attribute specified. The main element is also restricted in terms of where it can appear in a document. It can only have html, body, form without accessible name, div, and autonomous custom elements as ancestors.

This also slightly alters the definition of the body element as it effectively encompasses all content of a document, except for some metadata.

Fixes #100.

sideshowbarker added a commit to validator/validator that referenced this issue Jan 31, 2018

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