The current check in nsHTMLFontElement was added in <https://hg.mozilla.org/mozilla-central/rev/88d8bfd7ef64>; AIUI, to preserve behaviour in bug 403524.
data:text/html;charset=utf-8,<!doctype html><u>a<font color=red>foo</font>b</u>
Chrome underlines foo in red in all modes; we and Opera only do it in quirks mode, and IE never does it. Opera would be happy to make it apply in all modes as well.
IE does it in its compat-view quirks mode and compat-view standards mode.
Created attachment 631665 [details] [diff] [review]
If we're going to do this, shouldn't it go in a specification somewhere? (Perhaps the Rendering section of HTML5?)
It's currently specified here: http://simon.html5.org/specs/quirks-mode#the-font-element-text-decoration-color-quirk
I'm actually somewhat inclined to keep this quirks mode only, though I don't feel especially strongly.
I think the rationale for reducing the number of quirks is that it reduces the number of strange exceptions that authors have to learn and that browsers have to implement. In this case, however, we're already dealing with a strange exception to a very general rule (a single-element exception to an all-elements rule), and the question is whether that exception applies in a more restricted or less restricted set of cases. I'd rather keep it more restricted so that at least standards mode has fewer strange exceptions, even though the decision doesn't affect (either way) the number of strange exceptions in the Web platform as a whole.
The font element is non-conforming so authors using valid HTML don't need to learn about this exception.
That doesn't mean it isn't out there in existing content that authors have to maintain.
My inclination is to keep this as-is, though I'd also be open to consider removing the quirk entirely (particularly if there were evidence from someone other than IE non-compat-mode).