This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27743 - It would be clearer if Documents had mode and type explicitly included in their list of "internal slots"
Summary: It would be clearer if Documents had mode and type explicitly included in the...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-05 00:18 UTC by Domenic Denicola
Modified: 2015-08-03 10:08 UTC (History)
2 users (show)

See Also:

Attachments

Description Domenic Denicola 2015-01-05 00:18:35 UTC 
https://dom.spec.whatwg.org/#interface-document

[[
A document is assumed to be an XML document unless it is flagged as being an HTML document. Whether a document is an HTML document or an XML document affects the behavior of certain APIs. 

A document is always set to one of three modes: no-quirks mode, the default; quirks mode, used typically for legacy documents; and limited-quirks mode. Unless stated otherwise, a document must be in no-quirks mode. 
]]

It would be good to include these "type" and "mode" variables in the list of things associated to a document, viz. "Each document has an associated encoding, content type, and URL."

They are later referenced in https://dom.spec.whatwg.org/#concept-node-clone in a way that encourages them to be thought of the same way.

From an ES perspective, I'd say that mode/type are internal slots, just as encoding, content type, and URL are. I am working to bring jsdom up to spec in this regard and I found myself assigning doc._mode and doc._type properties alongside doc._encoding, doc._contentType, and doc._url. (I'm not suggesting switching to internal slot notation, but just using it as a point of view that might be helpful.)
Comment 1 Anne 2015-01-05 07:43:43 UTC 
Can you convince Ian this is a good idea? This would mainly impact the HTML specification at this point (from which these concepts originate).
Comment 2 Domenic Denicola 2015-01-05 16:37:06 UTC 
I am mainly just suggesting a minor editorial tweak. Namely, replace the current text with:

[[

Each document has an associated encoding, content type, URL, type, and mode.

Unless stated otherwise, a document's encoding is the utf-8 encoding, its content type is "application/xml", and its URL is "about:blank".

A document's type is either XML or HTML; we say it is an "XML document" or "HTML document" respectively. A document is assumed to be an XML document unless it is flagged as being an HTML document. Whether a document is an HTML document or an XML document affects the behavior of certain APIs.

A document's mode is one of: no-quirks mode, the default; quirks mode, used typically for legacy documents; and limited-quirks mode. Unless stated otherwise, a document must be in no-quirks mode.
]]

Then you could amend the concept-node-clone to say

> Its encoding, content type, URL, its mode, and its type

instead of the current

> Its encoding, content type, URL, its mode (quirks mode, limited quirks mode, or no-quirks mode), and its type (XML document or HTML document).

The main benefit here is that saying "Each document has an associated encoding, content type, URL, type, and mode" instead of "Each document has an associated encoding, content type, and URL" seems more honest.
Comment 3 Anne 2015-01-05 16:43:27 UTC 
Mkay, I guess we could add slots and keep the existing phrases for compatibility...
Comment 4 Anne 2015-08-03 10:08:22 UTC 
https://github.com/whatwg/dom/commit/8f812e6b16ba31270ba60568fb0bdbb78949348e

Thank you for this suggestion.