Bug 103172 - implement the HTML <main> element
: implement the HTML <main> element
Status: RESOLVED FIXED
: WebKit
HTML DOM
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
: http://dvcs.w3.org/hg/html-extensions...
: WebExposed
:
:
  Show dependency treegraph
 
Reported: 2012-11-24 02:36 PST by
Modified: 2013-01-21 17:27 PST (History)


Attachments
patch to add <main> (2.58 KB, patch)
2012-11-25 02:27 PST, Steve Faulkner
faulkner.steve: review+
Review Patch | Details | Formatted Diff | Diff
patch to add <main> v1 (2.61 KB, patch)
2012-11-25 03:35 PST, Steve Faulkner
abarth: review-
Review Patch | Details | Formatted Diff | Diff
v2 of patch for main - no tests yet (2.99 KB, patch)
2012-11-26 03:48 PST, Steve Faulkner
no flags Review Patch | Details | Formatted Diff | Diff
complete patch with tests and ChangeLog files (24.85 KB, patch)
2012-11-28 00:39 PST, Michael[tm] Smith
no flags Review Patch | Details | Formatted Diff | Diff
Patch (27.84 KB, patch)
2012-12-11 15:49 PST, Michael[tm] Smith
no flags Review Patch | Details | Formatted Diff | Diff
Patch (27.86 KB, patch)
2013-01-14 16:02 PST, Michael[tm] Smith
no flags Review Patch | Details | Formatted Diff | Diff
Patch (30.23 KB, patch)
2013-01-14 21:29 PST, Michael[tm] Smith
no flags Review Patch | Details | Formatted Diff | Diff
Patch (32.43 KB, patch)
2013-01-18 07:32 PST, Michael[tm] Smith
no flags Review Patch | Details | Formatted Diff | Diff
Patch (32.70 KB, patch)
2013-01-19 00:26 PST, Michael[tm] Smith
no flags Review Patch | Details | Formatted Diff | Diff
Patch (32.63 KB, patch)
2013-01-19 01:28 PST, Michael[tm] Smith
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-11-24 02:36:14 PST
<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
------- Comment #1 From 2012-11-24 02:54:12 PST -------
once implemented also need to map <main> to main acc role
------- Comment #2 From 2012-11-25 02:27:27 PST -------
Created an attachment (id=175877) [details]
patch to add <main> 

changes made to add main support

mapped LandamrkMainRole to mainTag
[WebCore\accessibility\AccessibilityRenderObject.cpp]
Line 2485 :     if (node && node->hasTagName(mainTag))
Line 2486 :     return LandmarkMainRole;

added mainTag as a blockTag
[WebCore\WebKit\editing\FormatBlockCommand.cpp]
Line 139 :         blockTags.add(mainTag);
added mainTag as a stackItem
[WebCore\WebKit\html\parser\HTMLStackItem.h]
Line 171 :             || tagName == HTMLNames::mainTag

added mainTag in tree builder
[WebCore\WebKit\html\parser\HTMLTreeBuilder.cpp]
Line 714 :         || token->name() == mainTag
Line 1726 :         || token->name() == mainTag

added main to following style declaration:
[WebCore\css\html.css]
article, aside, footer, header, hgroup, main, nav, section {
    display: block
}
------- Comment #3 From 2012-11-25 02:46:27 PST -------
(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 #4 From 2012-11-25 02:47:27 PST -------
(In reply to comment #1)
> once implemented also need to map <main> to main acc role

added main mapping in patch
------- Comment #5 From 2012-11-25 03:35:06 PST -------
Created an attachment (id=175879) [details]
patch to add <main> v1

fixed formatting
------- Comment #6 From 2012-11-25 03:39:02 PST -------
(From update of attachment 175879 [details])
fixed mimetype
------- Comment #7 From 2012-11-25 08:47:28 PST -------
(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.
------- Comment #8 From 2012-11-25 08:48:00 PST -------
My understanding is that this feature is somewhat controversial in the WHATWG.
------- Comment #9 From 2012-11-25 08:55:56 PST -------
(In reply to comment #7)
> (From update of attachment 175879 [details] [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
------- Comment #10 From 2012-11-25 08:59:01 PST -------
(In reply to comment #8)
> My understanding is that this feature is somewhat controversial in the WHATWG.

It is only controversial in as much as Hixie does not agree with it. Otherwise it has no major objections and support form a a range of participants. I have provided a patch on the basis of Maciej's email: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0104.html
------- Comment #11 From 2012-11-25 09:02:27 PST -------
> ok thanks for the info, first time so unsure of what to do

We've all contributed for the first time, so we understand.  :)
------- Comment #12 From 2012-11-25 11:31:25 PST -------
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.
------- Comment #13 From 2012-11-25 11:48:12 PST -------
(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.
------- Comment #14 From 2012-11-25 12:28:25 PST -------
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.)
------- Comment #15 From 2012-11-25 12:48:26 PST -------
(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
------- Comment #16 From 2012-11-25 13:51:01 PST -------
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.
------- Comment #17 From 2012-11-25 13:55:05 PST -------
(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.
------- Comment #18 From 2012-11-25 14:34:07 PST -------
(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
------- Comment #19 From 2012-11-25 14:35:22 PST -------
(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.
------- Comment #20 From 2012-11-26 03:48:47 PST -------
Created an attachment (id=175960) [details]
v2 of patch for main - no tests yet

double checked previous changes and new addition to HTMLTagNames.in
------- Comment #21 From 2012-11-27 04:23:21 PST -------
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.
------- Comment #22 From 2012-11-27 10:45:30 PST -------
(From update of attachment 175960 [details])
looks ok.
are you having any trouble making a layout test for accessibility to test this?
------- Comment #23 From 2012-11-27 21:01:16 PST -------
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
------- Comment #24 From 2012-11-28 00:39:06 PST -------
Created an attachment (id=176418) [details]
complete patch with tests can ChangeLog files
------- Comment #25 From 2012-11-28 01:32:18 PST -------
(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?
------- Comment #26 From 2012-11-29 01:11:18 PST -------
(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?
------- Comment #27 From 2012-11-29 18:53:06 PST -------
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.
------- Comment #28 From 2012-11-30 11:33:00 PST -------
(From update of attachment 176418 [details])
we'll still want an accessibility test as well
------- Comment #29 From 2012-11-30 11:39:54 PST -------
(In reply to comment #28)
> (From update of attachment 176418 [details] [details])
> we'll still want an accessibility test as well

I'll contribute one to the patch tomorrow.
------- Comment #30 From 2012-12-11 15:49:41 PST -------
Reopening to attach new patch.
------- Comment #31 From 2012-12-11 15:49:55 PST -------
Created an attachment (id=178901) [details]
Patch
------- Comment #32 From 2012-12-11 15:51:49 PST -------
Updated patch adds an accessibility layout test.
------- Comment #33 From 2013-01-04 00:54:52 PST -------
(From update of attachment 178901 [details])
Cleared review? from attachment 178901 [details] so that this bug does not appear in http://webkit.org/pending-review.  If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).
------- Comment #34 From 2013-01-14 16:01:49 PST -------
Reopening to attach new patch.
------- Comment #35 From 2013-01-14 16:02:06 PST -------
Created an attachment (id=182645) [details]
Patch
------- Comment #36 From 2013-01-14 16:05:39 PST -------
Reset review? flag per discussion with Chris Fleizach; please hold off on clearing it until Chris has had the opportunity to follow up.
------- Comment #37 From 2013-01-14 18:18:14 PST -------
(From update of attachment 182645 [details])
Attachment 182645 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/15870737

New failing tests:
editing/execCommand/query-format-block.html
fast/dom/wrapper-classes.html
------- Comment #38 From 2013-01-14 19:06:34 PST -------
(In reply to comment #37)
> (From update of attachment 182645 [details] [details])
> Attachment 182645 [details] [details] did not pass chromium-ews (chromium-xvfb):
> Output: http://queues.webkit.org/results/15870737
> 
> New failing tests:
> editing/execCommand/query-format-block.html
> fast/dom/wrapper-classes.html

I'm fixing these now and when I have them passing will upload an updated patch.
------- Comment #39 From 2013-01-14 19:33:41 PST -------
(From update of attachment 182645 [details])
Attachment 182645 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/15860756

New failing tests:
editing/execCommand/query-format-block.html
accessibility/main-element.html
------- Comment #40 From 2013-01-14 21:29:14 PST -------
Created an attachment (id=182695) [details]
Patch

Fixed failing ests: fixed fast/dom/wrapper-classes.html test for chromium; fixed editing/execCommand/query-format-block.html test for chromium and mac; did not yet fix accessibility/main-element.html test failure on mac -- will follow up with Chris Fleizach to figure out why it's failing.
------- Comment #41 From 2013-01-14 22:19:25 PST -------
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.
------- Comment #42 From 2013-01-14 22:27:18 PST -------
(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.
------- Comment #43 From 2013-01-14 22:44:35 PST -------
That's interesting. I'm not sure about the answer then.

Check out the rest of that IDL interface in ./Tools/WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl

If you have a Mac, you can also verify the AX API using the Accessibility Inspector mentioned here:
http://developer.apple.com/library/mac/#documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTesting/OSXAXTestingApps.html
------- Comment #44 From 2013-01-14 23:16:20 PST -------
(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 #45 From 2013-01-15 04:10:46 PST -------
(From update of attachment 182695 [details])
Attachment 182695 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/15884533

New failing tests:
accessibility/main-element.html
------- Comment #46 From 2013-01-15 05:12:28 PST -------
(From update of attachment 182695 [details])
Attachment 182695 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/15871871

New failing tests:
accessibility/main-element.html
------- Comment #47 From 2013-01-16 03:13:12 PST -------
(From update of attachment 182695 [details])
Attachment 182695 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://queues.webkit.org/results/15903335

New failing tests:
accessibility/main-element.html
------- Comment #48 From 2013-01-17 16:25:00 PST -------
(From update of attachment 182695 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=182695&action=review

> Source/WebCore/ChangeLog:1
> +2013-01-14  Steve Faulkner  <faulkner.steve@gmail.com>

Please change the author to yourself and just mention that it's co-authored by Steve Faulkner in the change log below.
------- Comment #49 From 2013-01-17 17:07:36 PST -------
(From update of attachment 182695 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=182695&action=review

> LayoutTests/accessibility/main-element.html:19
> +          shouldBe("main.role", "'AXRole: AXLandmarkMain'");

what you want here for the mac platform is

shouldBe("main.role", "'AXRole: AXGroup'");
shouldBe("main.subrole", "'AXSubrole: AXLandmarkMain'");
------- Comment #50 From 2013-01-18 07:32:21 PST -------
Created an attachment (id=183453) [details]
Patch

Removed failing platform-unaware ax test and replaced it with separate platform-specific ax tests (for chromium and mac).
------- Comment #51 From 2013-01-18 09:24:41 PST -------
(From update of attachment 183453 [details])
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 #52 From 2013-01-18 14:53:34 PST -------
(From update of attachment 183453 [details])
please try to address Dominic's comments. otherwise it's looking good. thanks
------- Comment #53 From 2013-01-19 00:26:32 PST -------
Created an attachment (id=183608) [details]
Patch

Address Dominic's review feedback in comment #51 (use accessibilityController.accessibleElementById and test for both the role and subrole properties).
------- Comment #54 From 2013-01-19 01:00:22 PST -------
(From update of attachment 183608 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=183608&action=review

> LayoutTests/platform/mac/accessibility/main-element-expected.txt:8
> +PASS main.subrole is 'AXRole: AXLandmarkMain'

this line should be 'AXSubrole: AXLandmarkMain'

that's prob why its failing
------- Comment #55 From 2013-01-19 01:01:01 PST -------
(From update of attachment 183608 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=183608&action=review

> LayoutTests/platform/chromium/accessibility/main-element.html:23
> +          shouldBe("main.subrole", "undefined");

probably no need to include subrole on chromium since its undefined
------- Comment #56 From 2013-01-19 01:05:37 PST -------
(In reply to comment #54)
> > LayoutTests/platform/mac/accessibility/main-element-expected.txt:8
> > +PASS main.subrole is 'AXRole: AXLandmarkMain'
> 
> this line should be 'AXSubrole: AXLandmarkMain'

d'oh

> that's prob why its failing

yeah will fix it now

(In reply to comment #55)
> > LayoutTests/platform/chromium/accessibility/main-element.html:23
> > +          shouldBe("main.subrole", "undefined");
> 
> probably no need to include subrole on chromium since its undefined

OK, will drop it
------- Comment #57 From 2013-01-19 01:28:22 PST -------
Created an attachment (id=183611) [details]
Patch

Fixed test flub and dropped check for ax subrole on chromium per comment #55 from Chris.
------- Comment #58 From 2013-01-21 09:12:02 PST -------
(From update of attachment 183611 [details])
Clearing flags on attachment: 183611

Committed r140341: <http://trac.webkit.org/changeset/140341>
------- Comment #59 From 2013-01-21 09:12:10 PST -------
All reviewed patches have been landed.  Closing bug.
------- Comment #60 From 2013-01-21 17:04:02 PST -------
(From update of attachment 183611 [details])
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?
------- Comment #61 From 2013-01-21 17:27:05 PST -------
(In reply to comment #60)
> (From update of attachment 183611 [details] [details])
> 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?

The quoted results are correct per the HTML 5.1 editor's draft:
http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-main-element

It doesn't match other browsers because none have implemented this new feature yet, though Gecko engineers plan to implement it, so it will likely soon be in Firefox.