Closed Bug 820508 Opened 11 years ago Closed 11 years ago

Add support for <main> element

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla21
Tracking Status
relnote-firefox --- 21+

People

(Reporter: hsivonen, Assigned: hsivonen)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-complete)

Attachments

(4 files, 2 obsolete files)

A new HTML element called <main> has been proposed:
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

I think we should implement it because:

 * It’s the last ARIA landmark that doesn’t have a native element (though it appears Gecko fails to map <header> to role=banner, but that’s a Gecko shotcoming) and it would be nice if Web authors who aren’t retrofitting a11y to legacy code or recreating GUI widgets in JS didn’t need to deal with ARIA (which was sold to us as temporary stop gap) (once we get over the transition to browsers that support <main>). It’s weird that role=main is the last landmark without an HTML-native element when it’s the most popular landmark (according to http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/ ).

 * <main> maps to cowpaths more nicely than “first <article>” or the like. <main> is both recognizable as something that paves a cowpath (“first <article>” isn’t really). It’s also easier to style with CSS than “first <article>”. (Turns out I failed to get the “first <article>” selector right when posting to the WHATWG list…)

 * <main> makes more sense than “first <article>” to people who read the English meaning of element names. (You aren’t supposed to do that—you are supposed to treat the names as runes whose meaning is given by the spec, but people still read stuff into the names.)

 * I expect <main> to be more teachable than “first <article>”, because <main> paves an existing cowpath. If there is a teachability conflict, I think we should rather de-emphasize <article> than not have <main>.

I’m attaching a patch that probably needs to be split for review, but it’s probably nicer to import a single patch for testing. Steve tested a try server build with this patch and reported expected behavior with JAWS and NVDA.

The patch does not have unit tests. I’m expecting Someone Else to write the non-parser unit tests. (I can write the parser unit tests.)

I realize that this feature is still controversial, but I’m filing a bug at this stage anyway, since, to my knowledge, Mozilla lacks a process other than “a patch landed and made it to release” for deciding to take a feature.
Note that the reason why the parser parts seem like they have many changes is that I renamed a constant.
Comment on attachment 690985 [details] [diff] [review]
Add support for <main> to parser, UA stylesheet and a11y code

Review of attachment 690985 [details] [diff] [review]:
-----------------------------------------------------------------

f=me

::: accessible/src/generic/HyperTextAccessible.cpp
@@ +1182,5 @@
>      nsAccUtils::SetAccAttr(attributes, nsGkAtoms::xmlroles,
>                             NS_LITERAL_STRING("article"));
> +  else if (mContent->Tag() == nsGkAtoms::main)
> +    nsAccUtils::SetAccAttr(attributes, nsGkAtoms::xmlroles,
> +                           NS_LITERAL_STRING("main"));

Looks right. We should probably ask at a test like below to attributes/test_xml-roles.html

testAttrs("main_element", {"xml-roles" : "main"}, true);

<main id="main_element">foo</main>
FWIW, "first article" isn't equivalent to role=main. IMHO the "main" landmark role is misguided; the browser should just determine from excluding non-main content what the right place is to jump to when the user requests to jump to the next bit of main content. Otherwise, you fail to handle cases like:

   <section>
    <h1>Heading</h1>
    <aside> ... </aside>
    <nav> ... </nav>
    text...
    <aside> ... </aside>
    <aside> ... </aside>
    text...
   </section>
> I think we should implement it because:
> 
>  * It’s the last ARIA landmark that doesn’t have a native element (though it
> appears Gecko fails to map <header> to role=banner, but that’s a Gecko

btw I tend to think mapping heading to banner instead of the heading role would be incorrect, and if aria suggests it then  it should b changed, but I'm willing to be convinced I'm wrong.

> shotcoming) and it would be nice if Web authors who aren’t retrofitting a11y
> to legacy code or recreating GUI widgets in JS didn’t need to deal with ARIA
> (which was sold to us as temporary stop gap) (once we get over the
> transition to browsers that support <main>). It’s weird that role=main is

I basically agree with this, but I think if we can solve problems aria solves in a better way than aria did  then we should certainly take the oportunity to do that instead of blindly copying aria into native markup.

> the last landmark without an HTML-native element when it’s the most popular
> landmark (according to
> http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-
> world-aria-landmark-use/ ).
> 
>  * <main> maps to cowpaths more nicely than “first <article>” or the like.
> <main> is both recognizable as something that paves a cowpath (“first
> <article>” isn’t really). It’s also easier to style with CSS than “first
> <article>”. (Turns out I failed to get the “first <article>” selector right
> when posting to the WHATWG list…)

So, first article would be more similar to what role=main / <main> do, butI'm pretty sure it doesn't solve the problem people actually want to solve in the UI.

<main> type solutions solve the problem "I would like to start reading everything after where the main content of the page starts including following non main content".  Of course you can then add methods to skip that stuff with landmarks huristics or whatever.

The sort of problem I think is better to solve is "I would like to read only the main content on the page and *none* of the menus / adds / similar things".  Which isn't a problem <main> solves very well so far as I can see.
(In reply to Hixie (not reading bugmail) from comment #3)
> FWIW, "first article" isn't equivalent to role=main. IMHO the "main"
> landmark role is misguided; the browser should just determine from excluding
> non-main content what the right place is to jump to when the user requests
> to jump to the next bit of main content. Otherwise, you fail to handle cases
> like:
> 
>    <section>
>     <h1>Heading</h1>
>     <aside> ... </aside>
>     <nav> ... </nav>
>     text...
>     <aside> ... </aside>
>     <aside> ... </aside>
>     text...
>    </section>

This makes sense from the point of view of building a browser that’s robust with whatever content you throw at it. It doesn’t make as much sense from the Web author perspective: Even if all browsers implemented Scooby Doo (do any?), for an author who wants to support the “skip to main content” use case, it is easier to believe that an explicit annotation does the right thing than running an algorithm in their head and structuring the page so that it gives the right outcome with the algorithm.

(In reply to Trevor Saunders (:tbsaunde) from comment #4)
> The sort of problem I think is better to solve is "I would like to read only
> the main content on the page and *none* of the menus / adds / similar
> things".  Which isn't a problem <main> solves very well so far as I can see.

Why not if it is baked into the Reader Mode heuristics? The current Reader Mode code already looks for the cowpaths that <main> tries to pave: http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/Readability.js#69
(In reply to Trevor Saunders (:tbsaunde) from comment #4)

 
> btw I tend to think mapping heading to banner instead of the heading role
> would be incorrect, and if aria suggests it then  it should b changed, but
> I'm willing to be convinced I'm wrong.

If you review how authors use <header> it mostly equates to the banner role definition:
278 HTML5 pages using Header and Footer elements
http://www.html5accessibility.com/HTML5data/header-footer/index-all.html

It rarely equates to a heading semantic.
(In reply to Henri Sivonen (:hsivonen) from comment #5)
> (In reply to Hixie (not reading bugmail) from comment #3)
> > FWIW, "first article" isn't equivalent to role=main. IMHO the "main"
> > landmark role is misguided; the browser should just determine from excluding
> > non-main content what the right place is to jump to when the user requests
> > to jump to the next bit of main content. Otherwise, you fail to handle cases
> > like:
> > 
> >    <section>
> >     <h1>Heading</h1>
> >     <aside> ... </aside>
> >     <nav> ... </nav>
> >     text...
> >     <aside> ... </aside>
> >     <aside> ... </aside>
> >     text...
> >    </section>
> 
> This makes sense from the point of view of building a browser that’s robust
> with whatever content you throw at it. It doesn’t make as much sense from
> the Web author perspective: Even if all browsers implemented Scooby Doo (do
> any?), for an author who wants to support the “skip to main content” use
> case, it is easier to believe that an explicit annotation does the right
> thing than running an algorithm in their head and structuring the page so
> that it gives the right outcome with the algorithm.

The algorithm should be such that if the page is sane then it will always do the right thing and the web author doesn't need to worry about the supporting these use cases.

> (In reply to Trevor Saunders (:tbsaunde) from comment #4)
> > The sort of problem I think is better to solve is "I would like to read only
> > the main content on the page and *none* of the menus / adds / similar
> > things".  Which isn't a problem <main> solves very well so far as I can see.
> 
> Why not if it is baked into the Reader Mode heuristics? The current Reader
> Mode code already looks for the cowpaths that <main> tries to pave:
> http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/
> Readability.js#69

I'm not sure I understand what your arguing here.

Without really looking how it works I get the impression what that does is to filter stuff out of the page if it suspects its not main content which seems more like what I'm suggesting than <main>.

Do we  agree that <main> isn't enough to handle the use case "I would like to read only main content"? since there is plenty of things like

<article>
my first great article.
</article>
some add nobody wants to read
<article>
Another great article
</article>

and  AIUI with <main> that should be
<main>
<article>first article</article>
some add
<article>another article</article>
</main>

So just taking everything from <main> to </main> isn't enough.
I don't understand why you think authors need to even think about this. The whole point of the HTML elements we have is that if you use them right, this all just works. (If you assume that authors are going to use them wrong, then <main> doesn't help either.) I agree with most of what Trevor has said above, and the use cases he mentions are already handled by the spec.

Anyway I'm not trying to stand in the way of this; if multiple vendors implement this then my life is made easier since I can just spec it and don't have to keep explaining why it's not good over and over again. :-) I would say that time will show that <main> doesn't help accessibility and that this was just a mistake, but since people still to this day argue that longdesc="" is good for accessibility, I hold no hope that <main>'s failure, if any, will be recognised as such by those whose advocacy has pushed it so far.
From the data set I have been using I looked at a random sample of pages that include <element id=main|content> I checked if the main content container included main menus, header, or footer content. Fesults for 43 pages i analysed so for are here: https://docs.google.com/spreadsheet/ccc?key=0AlVP5_A996c5dHozOW14RkF4NEdEUFRvemxCZ2I4Z3c

Note the majority DID NOT identify main content for accessibility purposes...
(In reply to Trevor Saunders (:tbsaunde) from comment #4)
> <main> type solutions solve the problem "I would like to start reading
> everything after where the main content of the page starts including
> following non main content".  Of course you can then add methods to skip
> that stuff with landmarks huristics or whatever.
> 
> The sort of problem I think is better to solve is "I would like to read only
> the main content on the page and *none* of the menus / adds / similar
> things".  Which isn't a problem <main> solves very well so far as I can see.

As someone who hates adds, *I* am also more interested in the second problem. But isn't AdBlock Plus the most successful story for that problem. Is there evidence that <aside> and such help?

I'd say we shouldn't conflate these two problems. In particular, the latter one might not be a problem Web authors really want to solve, so there could be a chance that Web athors just *don't* want to write correct markup for identifying ads.

(In reply to Hixie (not reading bugmail) from comment #8)
> I don't understand why you think authors need to even think about this. The
> whole point of the HTML elements we have is that if you use them right, this
> all just works. (If you assume that authors are going to use them wrong,
> then <main> doesn't help either.) 

And so I disagree here. Not using <aside> right might be intentional. I see fewer reasons why authors want to use <main> wrong.
(In reply to steve faulkner from comment #9)
> From the data set I have been using I looked at a random sample of pages
> that include <element id=main|content> I checked if the main content
> container included main menus, header, or footer content. Fesults for 43
> pages i analysed so for are here:
> https://docs.google.com/spreadsheet/
> ccc?key=0AlVP5_A996c5dHozOW14RkF4NEdEUFRvemxCZ2I4Z3c

So, I can't actually read anything useful there, but I'm fairly confident the result is one of two things.

a. a lot of sites have main content and other stuff interspersed.

b. I disagree with your algorithm on what is not main content, which is sort of reasonable since there's a lot of grey area.  For example I'd argue that g+ / facebook / etc like buttons are not main content, and about every blog and news site know to man has them around articles, so given the way <main> works  they'd have to be inside it.





(In reply to Kang-Hao (Kenny) Lu [:kennyluck] from comment #10)
> (In reply to Trevor Saunders (:tbsaunde) from comment #4)
> > <main> type solutions solve the problem "I would like to start reading
> > everything after where the main content of the page starts including
> > following non main content".  Of course you can then add methods to skip
> > that stuff with landmarks huristics or whatever.
> > 
> > The sort of problem I think is better to solve is "I would like to read only
> > the main content on the page and *none* of the menus / adds / similar
> > things".  Which isn't a problem <main> solves very well so far as I can see.
> 
> As someone who hates adds, *I* am also more interested in the second
> problem. But isn't AdBlock Plus the most successful story for that problem.
> Is there evidence that <aside> and such help?

I wouldn't think they do, but I don't see how that's related.

> I'd say we shouldn't conflate these two problems. In particular, the latter

why? the first problem is just a subset of the second, and as far as I can see there's no use case for the first that doesn't really want the second.

> one might not be a problem Web authors really want to solve, so there could
> be a chance that Web athors just *don't* want to write correct markup for
> identifying ads.

that's only relevent to solutions that require authors to do things, if the solution is all implemented in the browser UI then it doesn't really matter what web devs want.

also web devs may not want to mark adds as non main content, but I suspect they'd be willing to say like buttons aren't main content.
> (In reply to Kang-Hao (Kenny) Lu [:kennyluck] from comment #10)
> > As someone who hates adds, *I* am also more interested in the second
> > problem. But isn't AdBlock Plus the most successful story for that problem.
> > Is there evidence that <aside> and such help?
> 
> I wouldn't think they do, but I don't see how that's related.

Why not? If the Scooby Doo algorithm could really be useful, why not implmenting it experimentally in an add-on that has the goal of addressing your broader problem.

> > I'd say we shouldn't conflate these two problems. In particular, the latter
> 
> why? the first problem is just a subset of the second, and as far as I can
> see there's no use case for the first that doesn't really want the second.

There are plenty of "Skip to Content" links here and there but I haven't seen a "Skip to Next Content". I can't really explain why but I don't think what you say is true. 
 
> > one might not be a problem Web authors really want to solve, so there could
> > be a chance that Web athors just *don't* want to write correct markup for
> > identifying ads.
> 
> that's only relevent to solutions that require authors to do things, if the
> solution is all implemented in the browser UI then it doesn't really matter
> what web devs want.

Implementing an algorithm that wouldn't be useful has all sorts of downsides that I don't need to mention. But anyway, there is just no such effort, isn't there?
(In reply to Trevor Saunders (:tbsaunde) from comment #11)
> (In reply to steve faulkner from comment #9)
> > From the data set I have been using I looked at a random sample of pages
> > that include <element id=main|content> I checked if the main content
> > container included main menus, header, or footer content. Fesults for 43
> > pages i analysed so for are here:
> > https://docs.google.com/spreadsheet/
> > ccc?key=0AlVP5_A996c5dHozOW14RkF4NEdEUFRvemxCZ2I4Z3c
> 
> So, I can't actually read anything useful there, but I'm fairly confident
> the result is one of two things.
> 
> a. a lot of sites have main content and other stuff interspersed.
> 
> b. I disagree with your algorithm on what is not main content, which is sort
> of reasonable since there's a lot of grey area.  For example I'd argue that
> g+ / facebook / etc like buttons are not main content, and about every blog
> and news site know to man has them around articles, so given the way <main>
> works  they'd have to be inside it.

It's not my algorithm it's based on what is defined as the main part of the content in HTML5 [http://www.w3.org/html/wg/drafts/html/master/common-idioms.html#the-main-part-of-the-content] As per the definition there is no grey area.

As I suggested to you previously, authors can mark up content inside <main> that signifies it is not part of the main content using <aside>.

If they do this it is helpful, if they don't it does not invalidate the usefulness of <main>
There is an issue with webkit implementation related to validation of required fields in details element https://twitter.com/getsetbro/status/280348413827104768

there is an example: http://jsfiddle.net/getsetbro/wtK4s/
(In reply to steve faulkner from comment #14)
> There is an issue with webkit implementation related to validation of
> required fields in details element
> https://twitter.com/getsetbro/status/280348413827104768
> 
> there is an example: http://jsfiddle.net/getsetbro/wtK4s/

oops sorry wrong widnow
(In reply to Kang-Hao (Kenny) Lu [:kennyluck] from comment #12)
> > (In reply to Kang-Hao (Kenny) Lu [:kennyluck] from comment #10)
> > > As someone who hates adds, *I* am also more interested in the second
> > > problem. But isn't AdBlock Plus the most successful story for that problem.
> > > Is there evidence that <aside> and such help?
> > 
> > I wouldn't think they do, but I don't see how that's related.
> 
> Why not? If the Scooby Doo algorithm could really be useful, why not
> implmenting it experimentally in an add-on that has the goal of addressing
> your broader problem.

I think it'd be cool if some browser decided to have some sort of main content only mode or something.

> > > I'd say we shouldn't conflate these two problems. In particular, the latter
> > 
> > why? the first problem is just a subset of the second, and as far as I can
> > see there's no use case for the first that doesn't really want the second.
> 
> There are plenty of "Skip to Content" links here and there but I haven't
> seen a "Skip to Next Content". I can't really explain why but I don't think
> what you say is true. 

I think its pretty obvious why webdevs don't put skip past junk links all over the place.  Even if they were to I would think it would be a better user experience to not have to click a link each time you want to skip something (and of course the skip stuff notion doesn't really make sense in the case of visually looking at a web page, but the only showing main content does make sense).

> > > one might not be a problem Web authors really want to solve, so there could
> > > be a chance that Web athors just *don't* want to write correct markup for
> > > identifying ads.
> > 
> > that's only relevent to solutions that require authors to do things, if the
> > solution is all implemented in the browser UI then it doesn't really matter
> > what web devs want.
> 
> Implementing an algorithm that wouldn't be useful has all sorts of downsides

I don't think anyone is suggesting doing something pointless, so I don't understand what your saying.

> that I don't need to mention. But anyway, there is just no such effort,
> isn't there?

effort to do what?  If you mean some sort of main content only view the only thing I know of is Readability.js but who knows what addons exist.

Even if nobody was doing it yet why should you push <main> when you could write such a thing?  (I'd certainly support patches that tried assuming they don't have a terrible effect on perf or something).

(In reply to steve faulkner from comment #13)
> (In reply to Trevor Saunders (:tbsaunde) from comment #11)
> > (In reply to steve faulkner from comment #9)
> > > From the data set I have been using I looked at a random sample of pages
> > > that include <element id=main|content> I checked if the main content
> > > container included main menus, header, or footer content. Fesults for 43
> > > pages i analysed so for are here:
> > > https://docs.google.com/spreadsheet/
> > > ccc?key=0AlVP5_A996c5dHozOW14RkF4NEdEUFRvemxCZ2I4Z3c
> > 
> > So, I can't actually read anything useful there, but I'm fairly confident
> > the result is one of two things.
> > 
> > a. a lot of sites have main content and other stuff interspersed.
> > 
> > b. I disagree with your algorithm on what is not main content, which is sort
> > of reasonable since there's a lot of grey area.  For example I'd argue that
> > g+ / facebook / etc like buttons are not main content, and about every blog
> > and news site know to man has them around articles, so given the way <main>
> > works  they'd have to be inside it.
> 
> It's not my algorithm it's based on what is defined as the main part of the
> content in HTML5
> [http://www.w3.org/html/wg/drafts/html/master/common-idioms.html#the-main-
> part-of-the-content] As per the definition there is no grey area.

ok, fine, to be technical I should say I believe the spec's definition isn't the right one to be using for this purpose, and the one that should be used about is what a user wants to be considered main content, which certainly does have grey area since I doubt all users agree in all cases.

> As I suggested to you previously, authors can mark up content inside <main>
> that signifies it is not part of the main content using <aside>.
> 
> If they do this it is helpful, if they don't it does not invalidate the
> usefulness of <main>

I believe that 1 its odd to put non main stuff in a subtree starting with <main> and 2 not marking such stuff up does remove a significant amount of usefulness.
(In reply to Trevor Saunders (:tbsaunde) from comment #16)

> > 
> > It's not my algorithm it's based on what is defined as the main part of the
> > content in HTML5
> > [http://www.w3.org/html/wg/drafts/html/master/common-idioms.html#the-main-
> > part-of-the-content] As per the definition there is no grey area.
> 
> ok, fine, to be technical I should say I believe the spec's definition isn't
> the right one to be using for this purpose, and the one that should be used
> about is what a user wants to be considered main content, which certainly
> does have grey area since I doubt all users agree in all cases.

I don't believe it is being 'technical', one of the arguments against main has been that the spec already provides a method to ascertain the main content area. If you disagree with what the HTML5 spec defines as main content, the place to comment on that is on the spec.


> > As I suggested to you previously, authors can mark up content inside <main>
> > that signifies it is not part of the main content using <aside>.
> > 
> > If they do this it is helpful, if they don't it does not invalidate the
> > usefulness of <main>
> 
> I believe that 1 its odd to put non main stuff in a subtree starting with
> <main> and 2 not marking such stuff up does remove a significant amount of
> usefulness.

Your arguments are equally valid for article:

<article>
<aside/>
</article>

or indeed the <body> element as currently specified:
"The body element represents the main content of the document."

http://www.w3.org/html/wg/drafts/html/master/sections.html#the-body-element
> > > As I suggested to you previously, authors can mark up content inside <main>
> > > that signifies it is not part of the main content using <aside>.
> > > 
> > > If they do this it is helpful, if they don't it does not invalidate the
> > > usefulness of <main>
> > 
> > I believe that 1 its odd to put non main stuff in a subtree starting with
> > <main> and 2 not marking such stuff up does remove a significant amount of
> > usefulness.
> 
> Your arguments are equally valid for article:
> 
> <article>
> <aside/>
> </article>

I think its a lot more theoretical concern with <article> mostly because you can have multiple of them, but I don't think concerns about article are related to the issue at hand.

> or indeed the <body> element as currently specified:
> "The body element represents the main content of the document."
> 
> http://www.w3.org/html/wg/drafts/html/master/sections.html#the-body-element


its certainly less unreasonable to have asside or something under <body> than article or main if your just looking atthe names.

but again I don't see how this is relevent.
(In reply to Trevor Saunders (:tbsaunde) from comment #18)
> > > > As I suggested to you previously, authors can mark up content inside <main>
> > > > that signifies it is not part of the main content using <aside>.
> > > > 
> > > > If they do this it is helpful, if they don't it does not invalidate the
> > > > usefulness of <main>
> > > 
> > > I believe that 1 its odd to put non main stuff in a subtree starting with
> > > <main> and 2 not marking such stuff up does remove a significant amount of
> > > usefulness.
> > 
> > Your arguments are equally valid for article:
> > 
> > <article>
> > <aside/>
> > </article>
> 
> I think its a lot more theoretical concern with <article> mostly because you
> can have multiple of them, but I don't think concerns about article are
> related to the issue at hand.

There is nothing theoretical about it, <article> can include <aside> and does so in the wild. Whether you can have multiple instances of an <article> element is neither here nor there.

article has been repeateddly cited as a signifier for the main content area so it is very much related to he tissue at hand. 


> > or indeed the <body> element as currently specified:
> > "The body element represents the main content of the document."
> > 
> > http://www.w3.org/html/wg/drafts/html/master/sections.html#the-body-element
> 
> 
> its certainly less unreasonable to have asside or something under <body>
> than article or main if your just looking atthe names.
> 
> but again I don't see how this is relevent.

It was previously stated:

> I believe that 1 its odd to put non main stuff in a subtree starting with
> <main>

<main> and <body> are specced to signify the main content, in both cases <aside> is non main stuff in the subtree.
Blocks: html
Sorry about not following up on this in a timely manner. Another thing has been consuming my attention. I ended up writing test cases (parser, CSS and accessibility) for this, but the parser test made Firefox hang (not in the parser itself it seems; gdb suggested JS engine). I will need to take a better look in January.
Attached patch Part 1: HTML parser (obsolete) — Splinter Review
Assignee: nobody → hsivonen
Attachment #690985 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attached patch Part 3: a11ySplinter Review
Anything blocking going ahead with reviews?
(In reply to David Bolter [:davidb] from comment #24)
> Anything blocking going ahead with reviews?

I need to take a look at the test case problem from comment 20 still.
(In reply to Henri Sivonen (:hsivonen) from comment #25)
> (In reply to David Bolter [:davidb] from comment #24)
> > Anything blocking going ahead with reviews?
> 
> I need to take a look at the test case problem from comment 20 still.

Oops. Simple makefile error. We need a better failure mode for that. The symptoms were totally unobvious.
Attachment #694805 - Attachment is obsolete: true
Attachment #704850 - Flags: review?(bugs)
Attachment #694808 - Flags: review?(dbolter)
Attachment #694807 - Flags: review?(bzbarsky)
(In reply to Trevor Saunders (:tbsaunde) from comment #7)
> Do we  agree that <main> isn't enough to handle the use case "I would like
> to read only main content"? since there is plenty of things like
> 
> <article>
> my first great article.
> </article>
> some add nobody wants to read
> <article>
> Another great article
> </article>

I think we shouldn't reject main for failing to address that case perfectly when solutions <main> is trying to replace don't address that case perfectly and when it isn't realistic to expect ad removals to be standardizable, since the sites don't want to facilitate the ad removal case and could intentionally do something that doesn't fit a standard.
Comment on attachment 694807 [details] [diff] [review]
Part 2: UA stylesheet

r=me, though a test for that first rule might be nice.
Attachment #694807 - Flags: review?(bzbarsky) → review+
> I think we shouldn't reject main for failing to address that case perfectly
> when solutions <main> is trying to replace don't address that case perfectly

sure, but the reason I think we should have rejected it is that imo it hasn't really been shown we can't do better.  However I don't think we have much choice but to implement it now, and its not really bad  just not good.

> and when it isn't realistic to expect ad removals to be standardizable,
> since the sites don't want to facilitate the ad removal case and could
> intentionally do something that doesn't fit a standard.

That assumes the way to solve the problem is with a spec and having web page authors do things.  It hardly matters now so I'm not putting much thought into it, but I would propose that another solution would be some sort of addblock like thing that also tries to filter out navigational parts of pages and whatever.
Comment on attachment 704850 [details] [diff] [review]
Part 1: HTML parser, with proper makefile changes

I assume there will some other patch for the DOM part.
(we need tests for createElement and need to check that the element gets the
right interface etc.)

This is a bit like rs, since I certainly didn't verify for example that the change to ELEMENT_HASHES is correct. (rather odd to have such numbers)
Attachment #704850 - Flags: review?(bugs) → review+
Comment on attachment 694808 [details] [diff] [review]
Part 3: a11y

Review of attachment 694808 [details] [diff] [review]:
-----------------------------------------------------------------

r=me thanks!
Attachment #694808 - Flags: review?(dbolter) → review+
(In reply to Olli Pettay [:smaug] from comment #30)
> I assume there will some other patch for the DOM part.
> (we need tests for createElement and need to check that the element gets the
> right interface etc.)

Good point! Thanks.
Attachment #707082 - Flags: review?(bugs)
Comment on attachment 707082 [details] [diff] [review]
Part 4: Give <main> the HTMLElement DOM interface

And some tests are still coming, I assume.
Attachment #707082 - Flags: review?(bugs) → review+
(In reply to Olli Pettay [:smaug] from comment #33)
> And some tests are still coming, I assume.

I meant the change to content/html/content/test/test_bug389797.html as the sufficient test for the element having the right interface. Is that not sufficient?
Ah, right. That should be enough.
You need to log in before you can comment on or make changes to this bug.