Re: [whatwg] relationship between Document and HTMLDocument
Partial interface [1] was added for the 12 July 2011 – LCWD. It was designed to replace Supplemental [2]. I think the beginning of it was in a thread on public-script-coord [3]. [1] http://www.w3.org/TR/WebIDL/#dfn-partial-interface [2] http://www.w3.org/TR/2010/WD-WebIDL-20101021/#es-extended-attributes [3] http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0084.html On 8/9/11, David Flanagan dflana...@mozilla.com wrote: On 8/9/11 1:58 PM, Ian Hickson wrote: On Tue, 9 Aug 2011, David Flanagan wrote: Possibly. I think an alternative is to make the HTML spec just add all the members to Document, and then define window.HTMLDocument as returning the Document interface object. This would make instanceof and monkeypatching work as today. So you'd declare HTMLDocument with the [NoInterfaceObject] extended attribute and then add attribute HTMLDocument to the Window interface? That would have the same effect, but what I had in mind was actually to change the HTML spec to not define an HTMLDocument interface, instead renaming it to Document and adding the 'partial' WebIDL modifier. We'd also have to do this for SVGDocument and other document objects; before doing this it would be good to see if it's something that is generally agreeable to everyone. Is the partial keyword a brand-new feature of WebIDL? I didn't see them discussed on public-script-coord at all... A partial interface sounds like it would work to me. That changes HTMLDocument from non-enumerable to enumerable, but that seems unlikely to be a compatibility issue. That works for me, I think. Could you elaborate on this? I'm not sure what you mean exactly. The HTMLDocument interface object is current (at least in FF, and per the WebIDL spec) non-enumerable. It doesn't show up in for/in loops on the window. If the HTML spec were to add an attribute to the Window object to define the HTMLDocument property, WebIDL would make that property enumerable. It would also change from a data property to an accessor property. I'm not arguing that these changes would be a problem, just noting them. The much bigger change, of course, is that HTMLDocument would be === Document. -- Sent from my mobile device
[whatwg] relationship between Document and HTMLDocument
§3.1.1 includes the following:
interface HTMLDocument { ... };
Document implements HTMLDocument;
If I'm reading WebIDL correctly, this means that this expression must be
false:
document instanceof HTMLDocument
And also that this code will have no visible effect on the document object:
HTMLDocument.prototype.foo = function() { ... }
Furthermore, if I want to monkeypatch a method like getElementsByName()
that is defined by HTML, the correct place to do that is on
Document.prototype, not HTMLDocument.prototype
Currently, of course (tested in FF, Chrome and Safari), browsers treat
HTMLDocument as if it were declared like this:
interface HTMLDocument : Document { ... };
This means that in the current generation of browsers:
document instanceof HTMLDocument// = true
HTMLDocument.prototype.foo = function() {...} // affects document
Document.prototype.getElementsByName // undefined; can't monkeypatch it
I would guess (but have no data) that web compatibility will make these
behaviors difficult to change.
I assume that the use of an implements declaration rather than direct
inheritance is done to create a clean boundary between the DOM spec and
the HTML spec. But it seems to me that this clean boundary does not
reflect messy reality.
Ian: any chance you'd change HTML to specify that HTMLDocument is a
regular subclass of Document?
Anne: that would probably mean that you'd have to change the DOM spec to
say that DOMImplementation.create*Document() creates an HTMLDocument
even though your spec does not define that interface...
David
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 11:18 AM, David Flanagan wrote: I assume that the use of an implements declaration rather than direct inheritance is done to create a clean boundary between the DOM spec and the HTML spec. Or just to reflect Ian's belief that all documents should implement all document intefaces. In particular, the current spec text (which indeed does not match either older DOM specs or current implementations) requires all Document objects to implement the HTMLDocument interface. I don't believe that's the case in current UAs, fwiw... -Boris
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 8:53 AM, Boris Zbarsky wrote: On 8/9/11 11:18 AM, David Flanagan wrote: I assume that the use of an implements declaration rather than direct inheritance is done to create a clean boundary between the DOM spec and the HTML spec. Or just to reflect Ian's belief that all documents should implement all document intefaces. In particular, the current spec text (which indeed does not match either older DOM specs or current implementations) requires all Document objects to implement the HTMLDocument interface. I don't believe that's the case in current UAs, fwiw... -Boris Yes, that is the case in FF and Chrome, at least. I didn't bring that up because my intuition is that browsers could make that change (adding HTMLDocument members to non-HTML documents) without as much web compatibility impact. David
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 1:59 PM, David Flanagan wrote: Yes, that is the case in FF and Chrome, at least. I didn't bring that up because my intuition is that browsers could make that change (adding HTMLDocument members to non-HTML documents) without as much web compatibility impact. Maybe. Adding them to SVG documents, for example, might have nontrivial compat impact... -Boris
Re: [whatwg] relationship between Document and HTMLDocument
On Tue, 9 Aug 2011, David Flanagan wrote:
�3.1.1 includes the following:
interface HTMLDocument { ... };
Document implements HTMLDocument;
If I'm reading WebIDL correctly, this means that this expression must be
false:
document instanceof HTMLDocument
And also that this code will have no visible effect on the document object:
HTMLDocument.prototype.foo = function() { ... }
Furthermore, if I want to monkeypatch a method like getElementsByName() that
is defined by HTML, the correct place to do that is on Document.prototype, not
HTMLDocument.prototype
Currently, of course (tested in FF, Chrome and Safari), browsers treat
HTMLDocument as if it were declared like this:
interface HTMLDocument : Document { ... };
This means that in the current generation of browsers:
document instanceof HTMLDocument// = true
HTMLDocument.prototype.foo = function() {...} // affects document
Document.prototype.getElementsByName // undefined; can't monkeypatch it
I would guess (but have no data) that web compatibility will make these
behaviors difficult to change.
Possibly. I think an alternative is to make the HTML spec just add all the
members to Document, and then define window.HTMLDocument as returning the
Document interface object. This would make instanceof and monkeypatching
work as today.
I assume that the use of an implements declaration rather than direct
inheritance is done to create a clean boundary between the DOM spec and
the HTML spec.
No, it was done because inheritance here makes no sense. A Document is a
Document, you can take it and replace its root html element with a root
svg element, or mix html and svg, or any number of other similar
things, and it seems to me that it should all work. Why have different
Document objects? What if an html file has some svg in it, should it
not be able to get to the SVG API? etc.
But it seems to me that this clean boundary does not reflect messy
reality.
Indeed, this is an example of a new feature that browsers haven't
implemented yet.
Ian: any chance you'd change HTML to specify that HTMLDocument is a
regular subclass of Document?
Not unless we find no other way to fix the bugs in the current API in a
backwards-compatible way. :-)
On Tue, 9 Aug 2011, Boris Zbarsky wrote:
In particular, the current spec text (which indeed does not match either
older DOM specs or current implementations) requires all Document
objects to implement the HTMLDocument interface. I don't believe that's
the case in current UAs, fwiw...
Correct. This is an instance of the spec attempting to show the way
forward.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 12:53 PM, Ian Hickson wrote:
On Tue, 9 Aug 2011, David Flanagan wrote:
�3.1.1 includes the following:
interface HTMLDocument { ... };
Document implements HTMLDocument;
If I'm reading WebIDL correctly, this means that this expression must be
false:
document instanceof HTMLDocument
And also that this code will have no visible effect on the document object:
HTMLDocument.prototype.foo = function() { ... }
Furthermore, if I want to monkeypatch a method like getElementsByName() that
is defined by HTML, the correct place to do that is on Document.prototype, not
HTMLDocument.prototype
Currently, of course (tested in FF, Chrome and Safari), browsers treat
HTMLDocument as if it were declared like this:
interface HTMLDocument : Document { ... };
This means that in the current generation of browsers:
document instanceof HTMLDocument// = true
HTMLDocument.prototype.foo = function() {...} // affects document
Document.prototype.getElementsByName // undefined; can't monkeypatch it
I would guess (but have no data) that web compatibility will make these
behaviors difficult to change.
Possibly. I think an alternative is to make the HTML spec just add all the
members to Document, and then define window.HTMLDocument as returning the
Document interface object. This would make instanceof and monkeypatching
work as today.
So you'd declare HTMLDocument with the [NoInterfaceObject] extended
attribute and then add attribute HTMLDocument to the Window interface?
That changes HTMLDocument from non-enumerable to enumerable, but that
seems unlikely to be a compatibility issue. That works for me, I think.
David
Re: [whatwg] relationship between Document and HTMLDocument
On Tue, 9 Aug 2011, David Flanagan wrote: Possibly. I think an alternative is to make the HTML spec just add all the members to Document, and then define window.HTMLDocument as returning the Document interface object. This would make instanceof and monkeypatching work as today. So you'd declare HTMLDocument with the [NoInterfaceObject] extended attribute and then add attribute HTMLDocument to the Window interface? That would have the same effect, but what I had in mind was actually to change the HTML spec to not define an HTMLDocument interface, instead renaming it to Document and adding the 'partial' WebIDL modifier. We'd also have to do this for SVGDocument and other document objects; before doing this it would be good to see if it's something that is generally agreeable to everyone. That changes HTMLDocument from non-enumerable to enumerable, but that seems unlikely to be a compatibility issue. That works for me, I think. Could you elaborate on this? I'm not sure what you mean exactly. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 1:58 PM, Ian Hickson wrote: On Tue, 9 Aug 2011, David Flanagan wrote: Possibly. I think an alternative is to make the HTML spec just add all the members to Document, and then define window.HTMLDocument as returning the Document interface object. This would make instanceof and monkeypatching work as today. So you'd declare HTMLDocument with the [NoInterfaceObject] extended attribute and then add attribute HTMLDocument to the Window interface? That would have the same effect, but what I had in mind was actually to change the HTML spec to not define an HTMLDocument interface, instead renaming it to Document and adding the 'partial' WebIDL modifier. We'd also have to do this for SVGDocument and other document objects; before doing this it would be good to see if it's something that is generally agreeable to everyone. Is the partial keyword a brand-new feature of WebIDL? I didn't see them discussed on public-script-coord at all... A partial interface sounds like it would work to me. That changes HTMLDocument from non-enumerable to enumerable, but that seems unlikely to be a compatibility issue. That works for me, I think. Could you elaborate on this? I'm not sure what you mean exactly. The HTMLDocument interface object is current (at least in FF, and per the WebIDL spec) non-enumerable. It doesn't show up in for/in loops on the window. If the HTML spec were to add an attribute to the Window object to define the HTMLDocument property, WebIDL would make that property enumerable. It would also change from a data property to an accessor property. I'm not arguing that these changes would be a problem, just noting them. The much bigger change, of course, is that HTMLDocument would be === Document.
Re: [whatwg] relationship between Document and HTMLDocument
On Tue, 9 Aug 2011, David Flanagan wrote: The HTMLDocument interface object is current (at least in FF, and per the WebIDL spec) non-enumerable. It doesn't show up in for/in loops on the window. If the HTML spec were to add an attribute to the Window object to define the HTMLDocument property, WebIDL would make that property enumerable. It would also change from a data property to an accessor property. Ah, ok. Well in any case the goal is to be backwards-compatible with legacy content, while moving us to a world where HTML and SVG can coexist in the same document and access their respective Document-level APIs. Whatever it takes to do that is whatever we'll have to do. Might well involve WebIDL changes, or HTML spec changes, or whatnot. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
