Last Comment Bug 559284 - Support for HTML5 sectioning elements (article, aside, footer, header, hgroup, nav, section): style as display:block
: Support for HTML5 sectioning elements (article, aside, footer, header, hgroup...
: html5
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- enhancement with 1 vote (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (TPAC)
Depends on:
Blocks: html5test
  Show dependency treegraph
Reported: 2010-04-14 02:03 PDT by Florens Verschelde
Modified: 2012-10-18 00:16 PDT (History)
7 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Misc information on CSS default styles for section elements (489 bytes, text/css)
2010-04-14 02:04 PDT, Florens Verschelde
no flags Details
Just the style changes, plus tests (6.15 KB, patch)
2010-04-26 12:47 PDT, Boris Zbarsky [:bz] (TPAC)
no flags Details | Diff | Splinter Review
With reftest.list change too (6.71 KB, patch)
2010-04-26 12:48 PDT, Boris Zbarsky [:bz] (TPAC)
dbaron: review+
Details | Diff | Splinter Review

Description Florens Verschelde 2010-04-14 02:03:00 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv: Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100413 Minefield/3.7a5pre

Firefox currently has no support for HTML5's sectioning elements, the specification for which is quite stable by now. Those elements are: article, aside, footer, header, hgroup, nav, section.

- These elements are returned as DOM objects of the type "HTMLUnknownElement".
- They have no styling in the browser's UA stylesheet.

This is true in current Firefox 3.6, and 3.7a5pre, with the default parser or the HTML5 parser enabled (html5.enable=true).

Some “HTML5”-oriented tests and benchmarks may flag Firefox as not supporting these elements at all. See for instance:

Reproducible: Always
Comment 1 Florens Verschelde 2010-04-14 02:04:14 PDT
Created attachment 438962 [details]
Misc information on CSS default styles for section elements
Comment 2 Jo Hermans 2010-04-14 03:16:28 PDT
see bug 311366 for what's done so far
Comment 3 d 2010-04-14 17:06:58 PDT
The fix for the CSS part should be as easy as adding:

"article, aside, canvas, details, figcaption, figure, footer, header, hgroup, menu, nav, section, summary { 

to html.css, I think, but an exact list of the elements that should be "blockified" would be good, to make sure that we aren't making the changes to elements that shouldn't be blocks, and not missing any either.

I suspect that DOM objects support is quite an easy change too, and I think that having this in would be quite nice, as people seem to expect lots of HTML5 support in the new browser versions.

Webkit has been making lots of very simple/cheap implementations, just to be first, it seems. I do not think we should do the same thing, but these changes seem to be ones that are proper implementations (although some of these elements probably have more to them that we could take in follow-up bugs).
Comment 4 Nickolay_Ponomarev 2010-04-19 00:30:20 PDT
Would be nice if someone figured out how we should test this, i.e. either create an automated test (e.g. a reftest):
...or pointed to automated tests that could be included in our automated testing.

Links to the specs:

Probably best to split the DOM part in a separate bug.
Comment 5 d 2010-04-19 08:33:29 PDT
Sounds good. I'd say we should get the CSS patch checked in as soon as possible, as that shouldn't be more than a few lines to add in a file. Despite sounding so easy, the ways to create patches here are way too complicated for me, so I hope someone else steps in and does this before the release of 1.9.3.
Comment 6 Boris Zbarsky [:bz] (TPAC) 2010-04-26 12:40:27 PDT
> I suspect that DOM objects support is quite an easy change too

I believe this needs parser changes, actually... nsElementTable and all that mess.  Unless I'm missing something?

Henri, what's needed to make this work with the HTML5 parser?

Blake, can the nsElementTable entries for these match <div>?

And even then, I'm not sure we have a sane way for things to report as HTMLElement as opposed to something whose proto is HTMLElement....
Comment 7 Boris Zbarsky [:bz] (TPAC) 2010-04-26 12:40:53 PDT
So yes, someone needs to file another bug on the DOM thing.
Comment 8 Boris Zbarsky [:bz] (TPAC) 2010-04-26 12:47:30 PDT
Created attachment 441568 [details] [diff] [review]
Just the style changes, plus tests
Comment 9 Boris Zbarsky [:bz] (TPAC) 2010-04-26 12:48:54 PDT
Created attachment 441569 [details] [diff] [review]
With reftest.list change too
Comment 10 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2010-04-26 13:02:47 PDT
Comment on attachment 441569 [details] [diff] [review]
With reftest.list change too

r=dbaron, though I'm tempted to suggest that those long selectors in html.css should have a line break after each comma; feel free to do that if you want
Comment 11 Boris Zbarsky [:bz] (TPAC) 2010-04-26 13:06:25 PDT
I did in fact consider that.  Will do.
Comment 12 Boris Zbarsky [:bz] (TPAC) 2010-04-26 13:39:59 PDT
Pushed with that change
Comment 13 Gary [:streetwolf] 2010-04-26 16:34:08 PDT
I still get all no's in the Section Elements part of the test given in the URL.  Using the latest hourly which I assume includes this fix.

Section elements 0/7
section element	No
nav element	No
article element	No
aside element	No
hgroup element	No
header element	No
footer element	No

Build ID: 20100426144344
changeset 41356	f6298f002f1c
Comment 14 Boris Zbarsky [:bz] (TPAC) 2010-04-26 17:03:45 PDT
I have no idea whether the hourly includes the fix, but what I landed won't help the test in the url in any case.  See comment 7 and
Comment 15 d 2010-04-26 22:33:15 PDT is the version that checks for both, and will improve our score (hopefully).
Comment 16 Boris Zbarsky [:bz] (TPAC) 2010-04-27 03:59:22 PDT
It won't; that test requires both the block display and the DOM thing to pass.
Comment 17 José Jeria 2010-04-27 06:07:01 PDT
(In reply to comment #7)
> So yes, someone needs to file another bug on the DOM thing.

Bug 562008 was filed for this
Comment 18 d 2010-04-27 08:13:39 PDT
(In reply to comment #16)
> It won't; that test requires both the block display and the DOM thing to pass.

I see. I got the impression that the CSS and DOM part gave separate scores, but I guess not.
Comment 19 d 2010-04-27 08:18:49 PDT
No, wait, I just installed the latest hourly. We got a seven-point improvement :-) (that's the number of added elements)
Comment 20 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-04-27 11:25:43 PDT
There was some discussion on #whatwg IRC...

Lachy: but as annevk just said above, Mozilla has just implemented some support for the new elements, without doing anything about these heading styles
Lachy: see for more info
Lachy: so, according to that, Mozilla should implement those styles using :-moz-any(article, aside, section, nav) in place of the selector "x" given in the spec

Lachy: JonathanNeal, here are all the heading styles as they could be implemented in Mozilla
Lachy: Open that in Minefield to see the intended result
Comment 21 Boris Zbarsky [:bz] (TPAC) 2010-04-27 11:27:56 PDT
Oh, that's because the test was also changed to just use instanceof instead of toString.
Comment 22 Boris Zbarsky [:bz] (TPAC) 2010-04-27 11:29:37 PDT
Oh, I didn't realize there were other styles involved.  The fact that the spec's stylesheet is broken up into umpteen bazillion pieces doesn't help....

We should get a separate bug on that too, since it might have performance implications.
Comment 23 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2010-04-29 18:42:06 PDT
I filed bug 562835 on making the header styles reflect these sectioning elements.
Comment 24 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2010-04-29 18:45:02 PDT
Oh, and I didn't even see the three comments preceding until after I wrote the patch and filed it. :-)

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