W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Defining a constructor for Element and friends

From: Ryosuke Niwa <rniwa@apple.com>
Date: Tue, 13 Jan 2015 10:33:17 -0800
Cc: Domenic Denicola <d@domenic.me>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
Message-id: <8C952EAB-7083-429A-B103-5A5A321820C1@apple.com>
To: Boris Zbarsky <bzbarsky@mit.edu>

> On Jan 13, 2015, at 10:22 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 
>> On 1/13/15 1:18 PM, Ryosuke Niwa wrote:
>> I agree. It's unusual for a constructor of a super class to automatically instantiate an arbitrary subclass based on its arguments. And we usually solve that convenience problem by introducing a factory class/function.
> 
> While true, I do think there's a problem here.  Consider this:
> 
>  var element = new HTMLElement("somename");
> 
> OK, so the web author is not being very forward-compatible in that they're not using a tag name with a "-" in it.  But then they put it in the DOM and it acts just like a span, and they're happy with that.

Shouldn't we throw in this case because the concert type of "somename" is HTMLUnknownElement?

> Then we want to add a "somename" tag in the spec, and suddenly this JS throws.  This is a different order of breakage than what you get from just having new semantics for the "somename" tag.
...
> In any case, it's a bit of a niggling worry for me because it can increase the chance that adding things to HTML breaks websites.

I think if we threw an exception on every attempt to create an element with a name without "-" (as they're HTMLUnknownElement anyway), then we can probably mitigate this forward compatibility issue.

Hopefully, authors won't be creating HTMLUnknownElement all that often...

- R. Niwa
Received on Tuesday, 13 January 2015 18:34:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC