<main> should behave essentially the same as <div> for parsing etc.
the changes will be the same as for the implementaion of the <nav> element
https://bugs.webkit.org/attachment.cgi?id=35098&action=prettypatch
implement the HTML <main> element by making the appropriate changes to:
WebCore/css/html.css
WebCore/editing/htmlediting.cpp
WebCore/html/HTMLElement.cpp
WebCore/html/HTMLParser.cpp
WebCore/html/HTMLTagNames.in

(In reply to comment #0)
> <main> should behave essentially the same as <div> for parsing etc.
>
> the changes will be the same as for the implementaion of the <nav> element
> https://bugs.webkit.org/attachment.cgi?id=35098&action=prettypatch
>
> implement the HTML <main> element by making the appropriate changes to:
> WebCore/css/html.css
> WebCore/editing/htmlediting.cpp
> WebCore/html/HTMLElement.cpp
> WebCore/html/HTMLParser.cpp
> WebCore/html/HTMLTagNames.in
seems that changes to some of above no longer elevant

Comment on attachment 175879[details]
patch to add <main> v1
This patch is missing a ChangeLog and tests. Please see http://www.webkit.org/coding/contributing.html for instructions on how to contribute to WebKit. Also, please don't set the review flag to +. That means that a WebKit reviewer has approved your patch. Instead, you should set the review flag to ?, which indicates that you would like a reviewer to look at your patch.

(In reply to comment #7)
> (From update of attachment 175879[details])
> This patch is missing a ChangeLog and tests. Please see http://www.webkit.org/coding/contributing.html for instructions on how to contribute to WebKit. Also, please don't set the review flag to +. That means that a WebKit reviewer has approved your patch. Instead, you should set the review flag to ?, which indicates that you would like a reviewer to look at your patch.
ok thanks for the info, first time so unsure of what to do

Personally I don't care one way or the other; the reason it's not in the WHATWG spec isn't about my opinion, it's about the lack of compelling use cases. Adding a feature to the platform is expensive. Adding a feature which is likely to be misused (as determined by looking at how people use class=main now, compared to the proposed definition of the element) just pollutes the Web for no good reason.
In the case of this patch the danger is even worse; it is likely to actually make accessibility worse. The patch makes <main> act like role=main, but this will cause the many pages that will misuse it to report less useful results to AT users than if the element wasn't there. There are other mechanisms that have been suggested for similar results, which are less likely to be misused.

(In reply to comment #12)
> Personally I don't care one way or the other; the reason it's not in the WHATWG spec isn't about my opinion, it's about the lack of compelling use cases. Adding a feature to the platform is expensive. Adding a feature which is likely to be misused (as determined by looking at how people use class=main now, compared to the proposed definition of the element) just pollutes the Web for no good reason.
>
> In the case of this patch the danger is even worse; it is likely to actually make accessibility worse. The patch makes <main> act like role=main, but this will cause the many pages that will misuse it to report less useful results to AT users than if the element wasn't there. There are other mechanisms that have been suggested for similar results, which are less likely to be misused.
Making unsubstantiated statements such as much of the above does little to promote your view.
What you say are your opinions and not facts, and have not been accepted by others, who have reviewed and commented on the the data, the rationale, uses cases and the spec I wrote and have found them to have merit.

Nobody said your data and so forth didn't have merit, just that on the balance you reached the wrong conclusion.
(Incidentally, since people on the WHATWG list are encouraged to not post comments along the line of "+1" and since people have seen that I take a relatively reasonable view, people will often just assume that I'm going to reject bad suggestions and not comment. So saying that I'm the only one who has said anything negative on the thread isn't evidence that I'm the only person who reached that conclusion — it's my job to be the one who's negative. You can draw more conclusions from the fact that nobody else is implementing this feature, IMHO. It's not like people don't implement stuff I don't spec — it happens all the time, even without a spec at all. This feature has a spec, even, and still doesn't have implementors. It's not generally a sign of support that the same person who's writing the spec also has to write the code to put it in browsers. Don't confuse indifference for support. But none of this is relevant — what matters isn't how much support something has, it's how much justification it has.)

(In reply to comment #14)
> Nobody said your data and so forth didn't have merit, just that on the balance you reached the wrong conclusion.
>
> (Incidentally, since people on the WHATWG list are encouraged to not post comments along the line of "+1" and since people have seen that I take a relatively reasonable view, people will often just assume that I'm going to reject bad suggestions and not comment. So saying that I'm the only one who has said anything negative on the thread isn't evidence that I'm the only person who reached that conclusion — it's my job to be the one who's negative. You can draw more conclusions from the fact that nobody else is implementing this feature, IMHO. It's not like people don't implement stuff I don't spec — it happens all the time, even without a spec at all. This feature has a spec, even, and still doesn't have implementors. It's not generally a sign of support that the same person who's writing the spec also has to write the code to put it in browsers. Don't confuse indifference for support. But none of this is relevant — what matters isn't how much support something has, it's how much justification it has.)
The spec has been around a short time, a few months at most, so now you have moved from being in disagreement to being disingenuous , which is unfortunate.
The thread started by Simon Pieters on whatwg [1]
started with an observation:
"My impression from TPAC is that implementors are on board with the idea of
adding <main> to HTML, and we're left with Hixie objecting to it."
and ended with a specific questions:
"If there is anyone besides from Hixie who objects to adding <main>, it
would be useful to hear it."
While there were many responses there were no other objections.
When I tweeted today that I had submitted a patch, the response from Marco Zehe one of the mozilla accessibility engineers:
"Want to create a Firefox patch, too?" [2]
[1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0055.html
[2] https://twitter.com/MarcoInEnglish/status/272648449483218944

In addition to what Adam said about tests and a ChangeLog entry, this is a new feature, so it should be discussed on webkit-dev to determine if the WebKit community agrees with adding it. The details for that are described here: <http://www.webkit.org/coding/adding-features.html>.
If there's a need for discussion about whether the <main> feature is a good idea, then please let's have it on the webkit-dev thread, not here in the bug.

(In reply to comment #15)
>
> The spec has been around a short time, a few months at most, so now you have moved from being in disagreement to being disingenuous , which is unfortunate.
>
The WebKit community has high standards for courteous communication, whether in email or in the bug tracker. Please let's avoid attacks on others' integrity and indeed personal attacks of any kind.

(In reply to comment #17)
> (In reply to comment #15)
> >
> > The spec has been around a short time, a few months at most, so now you have moved from being in disagreement to being disingenuous , which is unfortunate.
> >
>
> The WebKit community has high standards for courteous communication, whether in email or in the bug tracker. Please let's avoid attacks on others' integrity and indeed personal attacks of any kind.
My apologies for using the word disingenuous in the bug report

(In reply to comment #16)
> In addition to what Adam said about tests and a ChangeLog entry, this is a new feature, so it should be discussed on webkit-dev to determine if the WebKit community agrees with adding it. The details for that are described here: <http://www.webkit.org/coding/adding-features.html>.
>
> If there's a need for discussion about whether the <main> feature is a good idea, then please let's have it on the webkit-dev thread, not here in the bug.
I have signed up for the mailing list once. I have access will send the appropriate email.

With help, got a chromium/Mac build with patch running. Adhoc testing of layout tests https://dl.dropbox.com/u/377471/main2.html all pass and <main> is exposed as
AXRole:"AXGroup"
AXSubRole:"AXLandmarkMain"
AXRoleDescription:"Group"
note: role description should be "Main", but Chromium does not appear to expose specific AXRoleDescription for majority of new HTML5 structural elements: <nav> <header> etc, although the AXSubRole values are correct.

(In reply to comment #23)
> The consensus from the webkit-dev discussion on this topic was that this needs further spec-work from the whatwg.
>
> Please feel free to file a new bug if this is later if needed.
>
> Thanks!
>
> http://lists.webkit.org/pipermail/webkit-dev/2012-November/022991.html
Seems not unlikely that will be the outcome, but maybe we should give it a few more days, since folks have spoken up on both sides of the issue?

(In reply to comment #25)
> (In reply to comment #23)
> > The consensus from the webkit-dev discussion on this topic was that this needs further spec-work from the whatwg.
> >
> > Please feel free to file a new bug if this is later if needed.
> >
> > Thanks!
> >
> > http://lists.webkit.org/pipermail/webkit-dev/2012-November/022991.html
>
> Seems not unlikely that will be the outcome, but maybe we should give it a >few more days, since folks have spoken up on both sides of the issue?>The consensus from the webkit-dev discussion on this topic was that this >needs further spec-work from the whatwg.
Hi Maciej, some advice here would be useful:
Besides the fact that the spec work is not being carried out at the WHATWG.
What further spec work needs to go on a the WHATWG?
The discussion has been effectively shut down at the WHATWG by hixie i.e. unless new data is provided that convinces him to change his mind.
There has been no new data offered or technical argument on the spec on the webkit-dev, only hixies re-assertions that were not backed up with anything new by him and were not convincing when discussed on the WHATWG list. Have I have missed any substantive feedback posted to any lists?
So what would you suggest are the next steps?

This extension specification was approved "with no objections and ample support" by the main HTML Working Group. http://lists.w3.org/Archives/Public/public-html/2012Nov/0232.html
Which means inclusion of the patch should be accepted once it gets reviewer approval.
As the standards discussion continues within W3C and WHATWG, additional bugs and patches may need to be added to support future changes to the specification.

(In reply to comment #41)
> It looks like your expectation is that the AXRole will be AXLandmarkMain, which will actually be the AXSubrole. You should still get a generic AXGroup for the role.
Thanks James. So I'm wondering if that failure is due to differences in what's exposed by the chromium port vs the mac port. In my chromium build environment, that test passes with the expected result of AXLandmarkMain for AXRole.

(In reply to comment #42)
> (In reply to comment #41)
> > It looks like your expectation is that the AXRole will be AXLandmarkMain, which will actually be the AXSubrole. You should still get a generic AXGroup for the role.
>
> Thanks James. So I'm wondering if that failure is due to differences in what's exposed by the chromium port vs the mac port. In my chromium build environment, that test passes with the expected result of AXLandmarkMain for AXRole.
Chromium and Mac can have different roles like this. Your test could check the platform name property. You can also look at some of the other landmark tests and see if they do something else

Comment on attachment 183453[details]
Patch
Unofficial review, accessibility looks okay with a couple of minor nits. Tests pass so this should be pretty close.
View in context: https://bugs.webkit.org/attachment.cgi?id=183453&action=review> LayoutTests/platform/chromium/accessibility/main-element.html:21
> + shouldBe("body.childAtIndex(0).role", "'AXRole: AXLandmarkMain'");
This is okay, but check out accessibilityController.accessibleElementById for a way to do this without needing to assume that the element you want is the first child of the body. (Most of the more recent tests use this pattern instead, it's more robust.)
> LayoutTests/platform/mac/accessibility/main-element.html:21
> + shouldBe("body.childAtIndex(0).subrole", "'AXSubrole: AXLandmarkMain'");
This is good, but I would test the role too.

Comment on attachment 183611[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=183611&action=review> LayoutTests/fast/dom/wrapper-classes-expected.txt:346
> +PASS tagJSWrapperClass('main') is 'HTMLElement'
> +PASS tagJSWrapperPrototypeClass('main') is 'HTMLElementPrototype'
> +PASS tagJSWrapperConstructorClass('main') is 'HTMLElementConstructor'
Is this correct? Is this specified? Does this match the behavior in the other browsers?