642616 - Consider building in future-proofing for block-level HTML5 elements

Status: RESOLVED FIXED

(Camino Graveyard :: General, enhancement)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

[6:43pm] smorgan: It looks right in a Real Browser
[6:44pm] smorgan: I bet he forgot to do a block on HTML5 elements
[6:44pm] smorgan: So browsers that don't understand <section> have the wrong style
[6:44pm] smorgan: s/block/display:block/
[6:45pm] smorgan: Yep, that's it
[6:45pm] smorgan: You know what... we should put those in our style sheet
[6:45pm] smorgan: There's no reason we couldn't
[6:46pm] smorgan: We have our own fork of it, right?
[6:46pm] ardissone: ?
[6:46pm] smorgan: Sorry, I'll try to explain for the not-in-my-head audience :)
[6:47pm] smorgan: The blog uses new HTML5 elements (specifically here, <section>)
[6:47pm] smorgan: article, aside, footer, header, hgroup, nav, and section all should be display:block, like div
[6:47pm] smorgan: But older, sadden browsers don't know this
[6:48pm] smorgan: And the default is inline for unknown elements
[6:48pm] smorgan: The solution that most people use when using these elements is to just put a display:block rule for those in their site's style sheet
[6:48pm] smorgan: Because then it Just Works everywhere (modulo some IE hackery in JS that's needed there)
[6:49pm] smorgan: But if we have a CSS file for Camino that we control, we could just put that block in there
[6:49pm] smorgan: So Camino would natively understand how to style the new elements even though it's not buzzword-compliant
[6:49pm] ardissone: ah
[6:50pm] ardissone: we don't have one that's no pref-based
[6:50pm] ardissone: *not
[6:50pm] smorgan: Oh. Bummer :(
[6:50pm] ardissone: but that doesn't mean we couldn't add one
[6:50pm] smorgan: It's probably not worth that much effort
[6:51pm] ardissone: though
[6:51pm] ardissone: aquaSelect is in theory always on
[6:51pm] smorgan: Haha
[6:51pm] cl: Did the form widget styling finally go away entirely?
[6:51pm] ardissone: and this would be similar hackery
[6:51pm] smorgan: aquaSelectAndABitOfHTML5
[6:51pm] ardissone: right
[6:51pm] smorgan: Really the answer is for him to be older-brower friendly on his blog
[6:52pm] ardissone: considering no released Gecko yet knows about that, apparently 
[6:52pm] smorgan: But as FF4 and IE9 become widely used it might become more common to do the wrong thing
[6:52pm] smorgan: So a squidge of future-proofing might not hurt ;)
[6:54pm] ardissone: ah, that's lovely

Comment 1

[philippe (part-time)]

I was considering appending something like that to my usercontent.css last night…
I don't think many mainstream sites would be affected - considering IE < 9, but who knows, Mac specific sites could possibly fall for this.

As long as it is not set to !important, this should do in a aquaSelectAndABitOfHTML5.css:

article, aside, figure, figcaption, footer, header, hgroup, section {
  display: block;
}

based on:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#display-types
http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#118


(::grmbl:: ranchero.com and inessential.com should fix that damn stylesheet)

Comment 2

[Stuart Morgan]

Turns out we already need to refactor that code, so I'm just going to do that and then add a new file, rather than do something hacking with the aqua style sheet.

Comment 3

[Stuart Morgan]

(In reply to comment #1)
> article, aside, figure, figcaption, footer, header, hgroup, section {

Also nav

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #2)
> Turns out we already need to refactor that code, so I'm just going to do that
> and then add a new file, rather than do something hacking with the aqua style
> sheet.

One other thing I noticed about that code when I looked at it for this bug before is that we always hard-wire sheets to be USER_SHEET; are there any circumstances in which we might ever want to have UA sheet(s)? https://developer.mozilla.org/en/Using_the_Stylesheet_Service

Comment 5

[Stuart Morgan]

Technically this should be an AGENT_SHEET. I don't think it would matter in practice since we aren't using !important and a user sheet is wildly unlikely to have a conflicting declaration, but we may as well do it right.

Comment 6

[Stuart Morgan]

Attachment: pre-change cleanup

This is just some pre-change cleanup:
1) Refactor bundled CSS loading to eliminate duplication
2) Rename the function to load/unload style sheets, and remove the "refresh" behavior that we didn't use.

Explanation of 2: The way to either load or refresh a stylesheet was to call [refreshStyleSheet:foo load:YES]. The way to unload a style sheet is was to call [refreshStyleSheet:foo load:NO]. The name is weird for loading, and horrible for unloading--and, as it turns out, those are our only two uses. We never call it with the intent of reloading an already loaded sheet.

Comment 7

[Stuart Morgan]

Attachment: fix

I also added the default margins Gecko and WebKit have for 'figure'

Comment 8

[Stuart Morgan]

Landed as:
http://hg.mozilla.org/camino/rev/1368b881a35c
http://hg.mozilla.org/camino/rev/89aedffac2cf