The default bug view has changed. See this FAQ.

Support for HTML5 sectioning elements (article, aside, footer, header, hgroup, nav, section): style as display:block

RESOLVED FIXED

Status

()

Core
CSS Parsing and Computation
--
enhancement
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: Florens Verschelde, Assigned: bz)

Tracking

(Blocks: 1 bug, {html5})

Trunk
html5
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.3) 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: http://html5test.com/
Details: http://github.com/NielsLeenheer/html5test/issues#issue/17

Reproducible: Always
(Reporter)

Comment 1

7 years ago
Created attachment 438962 [details]
Misc information on CSS default styles for section elements

Comment 2

7 years ago
see bug 311366 for what's done so far

Comment 3

7 years ago
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 { 
  display:block;
}"

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 Firefox.next 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

7 years ago
Would be nice if someone figured out how we should test this, i.e. either create an automated test (e.g. a reftest):
https://developer.mozilla.org/en/Mozilla_automated_testing
...or pointed to automated tests that could be included in our automated testing.

Links to the specs:
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-section-element
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-css-user-agent-style-sheet-and-presentational-hints

Probably best to split the DOM part in a separate bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: html5
Summary: Support for HTML5 sectioning elements (section, header...) → Support for HTML5 sectioning elements (article, aside, footer, header, hgroup, nav, section): style as display:block and present as HTMLElement, not HTMLUnknownElement in the DOM
Version: unspecified → Trunk

Comment 5

7 years ago
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.
> 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....
So yes, someone needs to file another bug on the DOM thing.
Summary: Support for HTML5 sectioning elements (article, aside, footer, header, hgroup, nav, section): style as display:block and present as HTMLElement, not HTMLUnknownElement in the DOM → Support for HTML5 sectioning elements (article, aside, footer, header, hgroup, nav, section): style as display:block
Created attachment 441568 [details] [diff] [review]
Just the style changes, plus tests
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #441568 - Flags: review?(dbaron)
Created attachment 441569 [details] [diff] [review]
With reftest.list change too
Attachment #441569 - Flags: review?(dbaron)
Attachment #441568 - Attachment is obsolete: true
Attachment #441568 - Flags: review?(dbaron)
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
Attachment #441569 - Flags: review?(dbaron) → review+
I did in fact consider that.  Will do.
Pushed http://hg.mozilla.org/mozilla-central/rev/0ac6c9f25269 with that change
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED

Comment 13

7 years ago
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
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 http://github.com/NielsLeenheer/html5test/issues/issue/17#issue/17/comment/186875

Comment 15

7 years ago
http://beta.html5test.com is the version that checks for both, and will improve our score (hopefully).
It won't; that test requires both the block display and the DOM thing to pass.

Comment 17

7 years ago
(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

7 years ago
(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

7 years ago
No, wait, I just installed the latest hourly. We got a seven-point improvement :-) (that's the number of added elements)
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 http://www.whatwg.org/specs/web-apps/current-work/complete.html#margins-and-padding 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 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/463
Lachy: Open that in Minefield to see the intended result
Oh, that's because the test was also changed to just use instanceof instead of toString.
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.
I filed bug 562835 on making the header styles reflect these sectioning elements.
Oh, and I didn't even see the three comments preceding until after I wrote the patch and filed it. :-)
Blocks: 802882
You need to log in before you can comment on or make changes to this bug.