897815 - [meta] Merge HTMLDocument into Document

Status: NEW

(Core :: DOM: Core & HTML, task, P5)

Description

[Masatoshi Kimura [:emk]]

The spec has been merged both interfaces.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

I'm not sure if we agree that the spec is correct.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Indeed.  See the existing spec issues that have been raised on this.

Comment 3

[Masatoshi Kimura [:emk]]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22960#c1
> Ian 'Hixie' Hickson 2013-08-20 17:15:06 UTC
> 
> The solution here is for the browsers to align with the specs.
> 
> It doesn't make sense to have separate SVGDocument and HTMLDocument
> objects. You can have HTML in SVG and SVG in HTML.

How Gecko is dealing with the HTML in SVG issue?

Comment 5

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

What is the current status here?  Would a patch for this be accepted?

(In reply to Boris Zbarsky [:bz] from comment #2)
> Indeed.  See the existing spec issues that have been raised on this.

Which ones?

Comment 6

[Anne (:annevk)]

Bug against the DOM Standard: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22960.

Comment 7

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I don't actually see any reasons there?

Comment 8

[Anne (:annevk)]

Oh apologies, I missed that the bug was already mentioned. I'm likewise unsure what bugs bz is referring too then.

Comment 9

[Boris Zbarsky [:bzbarsky]]

The basic spec issue is that the spec is specifying something that's not compatible with any shipping implementation, last I checked, with no indication that it's web-compatible, and with behaviors that are known to be very likely non-web-compatible (e.g. the createElement behavior, though that's not directly related to this bug).  As a result of this last, I have low confidence in the parts of the spec I have _not_ carefully audited yet, because I have concreted evidence that the spec editor here has put theoretical purity ahead of compatibility in the past.  As a result, I have very low confidence that the spec can be implemented and shipped without breakage without doing some serious due diligence on every API involved, both in terms of web compat and in terms of whether the behavior the spec defines for non-HTML documents makes sense.

That means whoever wants to work on this bug needs at a minimum to sit down and write up an analysis of why every API moved from HTMLDocument to Document is defined in a sane way in the non-HTML document case.  Or the patch reviewer needs to do this.  Or both need to, and compare notes....

Whether a patch would be accepted depends on the results of that analysis and on what due diligence has been done in terms of web compat.  I can't speak to what form the second of these would take; a minimal requirement is identifying the set of places where the spec differs from currently shipping UAs (and where these differ from each other), such that we have some idea of where the compat risks lie.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Oh, and in terms of the web compat angle, it's worth talking to the IE team to figure out why, per the webkit bug, they used to do something more like the spec and then stopped doing it.

Comment 11

[Boris Zbarsky [:bzbarsky]]

And I expect the spec issues were raised via email, not as bugs in bugzilla (which was an explicitly supported method of raising issues in the past for this spec), and certainly predate the use of github as an issue tracker for the spec.  That may be why you're having trouble finding them, if you didn't actually search the mailing list archives...

Comment 12

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

https://github.com/whatwg/dom/issues/221

Comment 13

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

It seems we agree that it's fine to try moving HTMLDocument members to Document in cases where it makes sense.  If we manage to successfully move all of them, we can try making the HTMLDocument interface object an alias.

Comment 15

[ExE Boss]

All that’s left now is HTMLDocument.name (for which I can’t find documentation anywhere) and three [ChromeOnly] features:
https://hg.mozilla.org/mozilla-central/file/872c3c79f9060ac27b6b79435e4be869bb040e91/dom/webidl/HTMLDocument.webidl

Comment 16

[Boris Zbarsky [:bzbarsky]]

All that’s left now is HTMLDocument.name (for which I can’t find documentation anywhere)

Do you mean getter object(DOMString name)? That's defined at https://html.spec.whatwg.org/multipage/dom.html#the-document-object, no?

Comment 17

[Boris Zbarsky [:bzbarsky]]

That said, it's not clear to me that what other UAs implement matches the spec here, any more than what Gecko does (though in somewhat different ways), so we should think very carefully before changing behavior for the named getter.

Comment 18

[ExE Boss]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #16)

(In reply to ExE Boss from comment #15)
All that’s left now is HTMLDocument.name (for which I can’t find documentation anywhere)

Do you mean getter object(DOMString name)? That's defined at https://html.spec.whatwg.org/multipage/dom.html#the-document-object, no?

Yes, that’s exactly what I mean.

---

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #17)

That said, it's not clear to me that what other UAs implement matches the spec here, any more than what Gecko does (though in somewhat different ways), so we should think very carefully before changing behavior for the named getter.

Let’s discuss that in bug 1567755.