nuke HTMLBaseFontElement interface

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: annevk, Assigned: sicking)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Opera recently removed rendering support for the <basefont> element to be in line with Gecko/WebKit, but the interface is still there because it is still in Gecko/WebKit. Would it be possible to clean this up or are we forever stuck with it? (I realize we're forever stuck with the quirk in the parser.)
(Reporter)

Comment 1

8 years ago
WebKit: https://bugs.webkit.org/show_bug.cgi?id=29641
Created attachment 437807 [details] [diff] [review]
Patch to fix

This patch does a few things

* Remove the nsIDOMHTMLBaseFontElement interface and tests for it.
* Remove (or rather make non-scriptable in order to preserve binary compat)
  nsIDOMHTMLHeadElement.profile. This is largely useless and I think it can
  be removed from the HTML5 spec.
* Kill nsHTMLHeadElement and nsHTMLHtmlElement. Instead use nsHTMLSharedElement
  for these element types.
* Remove apparently bogus comment about keeping classinfo ids stable
Assignee: nobody → jonas
Attachment #437807 - Flags: review?(jst)
Comment on attachment 437807 [details] [diff] [review]
Patch to fix

r=jst!
Attachment #437807 - Flags: review?(jst) → review+
Checked in

http://hg.mozilla.org/mozilla-central/rev/3a2552c83446
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.