Re: [whatwg] Proposal for window.DocumentType.prototype.toString

On Wed, Oct 31, 2012 at 7:33 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 31 Oct 2012, Johan Sundström wrote:
> > On Wednesday, October 31, 2012 at 15:02 , Ian Hickson wrote:
> > > On Tue, 30 Oct 2012, Johan Sundström wrote:
> > > > That said, I would still much enjoy a future where
> > > > javascript:alert(document.doctype) would tell you something rich
> about
> > > > the page that we today need deep knowledge of document.compatMode
> and/or
> > > > combinations of XMLSerializer and parsers, or deep study of
> DocumentType
> > > > refdocs to tease out.
> > >
> > > Can you elaborate on that?
> >
> > Sure – rich as in not "[object DocumentType]", but
>
> Well the toString() isn't what matters, it's what you can get from the
> rest of the attributes on the object. Or are you just saying you wish
> .toString() would expose the concatenated string? That would just be a
> conveniece method. Is it worth the compat risk?
>

Yes, this is where our opinions differ. :-) To me, it is the (lack of)
language integration that is the heart of the matter and the source of my
itch – not that what I attempted to do proved impossible to cobble together
with a (perfectly functional!) solution using other documented DOM APIs
scattered about in other disjunct parts of the browser object model, or
pasting together object properties and programmer provided constant strings
to almost reproduce the value sought. My own hack unintentionally got it
wrong in several ways, for example, and I deem that unnecessary brittleness.

>From my own experience, the only guaranteed safe, reliable and cross
browser method for figuring out an object's class name is
Object.prototype.toString.call(object_of_interest), so I would sacrifice
consistency with DocumentType.prototype.toString behaviours of the past in
an instance for a more useful and intuitive one. If a novice programmer's
expectations on what happens when she uses the object in a string context
is met, I'd call that improvement here.

> …on apple.com: <!DOCTYPE html>
> >
> > …on roxen.com: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
> Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
>
> I don't understand how that is different than document.compatMode,
> really, other than the latter not exposing limited quirks mode. But in
> theory at least, this information is already exposed.
>

It tells me what the doctype is, instead of the name of a bucket the
browser sorts the doctype into for various semantic and standards
compliance (and/or political) reasons.

Both features are excellent, when they are the feature you seek, and they
already bear decent names helping with their findability and learnability.
I am essentially weary of the long knowledge gap and edit distance
between alert(document.doctype) and alert((new
XMLSerializer).serializeToString(document.doctype)) – that we can straddle
both in this group we already proved; I aspire to help the other 99%.

> …on the Firefox default homepage: <!DOCTYPE html [
> >   <!ENTITY % htmlDTD
> >     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> > [...]
>
> This is for XML, right? In HTML the bit in the square brackets would just
> be dropped. It's not clear that it's worth exposing just for XML...
>
> Anyway, this is the DOM Core spec, so I'll let Anne, Aryeh, and Ms2ger
> give you a proper answer. :-)


It probably is, and it's also where the change would be useful; were SVG
and other DOMs exempt from returning a string serialization, it would be a
substantially less useful change.

-- 
 / Johan Sundström, http://ecmanaut.blogspot.com/

Received on Thursday, 1 November 2012 10:17:37 UTC