On Fri, 16 Jan 2015 20:08:30 +0100, Domenic Denicola d...@domenic.me wrote:
From: Anne van Kesteren [mailto:ann...@annevk.nl]
How can that work if the custom element constructor needs to look in
the registry to find its name? Pick a name at random?
Nah, it just automatically starts acting
On Mon, Jan 19, 2015 at 11:01 AM, Simon Pieters sim...@opera.com wrote:
If so, it seems it removes some flexibility with how HTML uses interfaces.
In particular many elements use HTMLElement and it should be possible to
change them to use a more specific interface. How do you envision to solve
From: Anne van Kesteren [mailto:ann...@annevk.nl]
How can that work if the custom element constructor needs to look in the
registry to find its name? Pick a name at random?
Nah, it just automatically starts acting like HTMLQuoteElement: the localName
option becomes required. See
I've updated my element constructors sketch at
https://github.com/domenic/element-constructors/blob/master/element-constructors.js
with a design that means no subclasses of HTMLElement (including the built-in
elements) need to override their constructor or [Symbol.species](). It also
uses an
On Wed, Jan 14, 2015 at 5:26 AM, Domenic Denicola d...@domenic.me wrote:
How do you propose having a private constructor API?
Same as how we explain Window, Navigator, and friends, no? By
requiring that UAs pass in a magic token web developers cannot get a
hold of.
This is one of those only
* Domenic Denicola wrote:
From: Bjoern Hoehrmann [mailto:derhoe...@gmx.net]
I know that this a major concern to you, but my impression is that few
if any other people regard that as anything more than nice to have,
especially if you equate explaining with having a public API for it.
How do
From: Bjoern Hoehrmann [mailto:derhoe...@gmx.net]
I know that this a major concern to you, but my impression is that few if any
other people regard that as anything more than nice to have, especially if
you equate explaining with having a public API for it.
How do you propose having a
* Domenic Denicola wrote:
That kind of breaks the design goal that we be able to explain how
everything you see in the DOM was constructed. How did the parser (or
document.createElement(NS)) create a HTMLUnknownElement, if the
constructor for HTMLUnknownElement doesn't work?
I know that this a
On Jan 13, 2015, at 10:22 AM, Boris Zbarsky bzbar...@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
On 1/13/15 12:05 PM, Domenic Denicola wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
var x = new Element(a, http://www.w3.org/1999/xhtml;)
The idea is that your above example throws, preserving the invariant.
That sounds annoying
Presumably this means that
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
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Terminology: In what follows I use 'own-instances of X' to mean objects
where obj.constructor === X,
That doesn't make much sense to me as a useful test, since it's pretty simple
to produce, say, an HTMLParagraphElement instance on the web
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
But it also means that user-space code that has to create an HTML element
generically now has to go through document.createElement instead of being
able to do |new HTMLElement(a)|, right?
That seems totally fine to me though. The idea of a
On Jan 13, 2015, at 9:25 AM, Domenic Denicola d...@domenic.me wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
But it also means that user-space code that has to create an HTML element
generically now has to go through document.createElement instead of being
able to do |new
On Jan 13, 2015, at 8:26 PM, Domenic Denicola d...@domenic.me wrote:
From: Bjoern Hoehrmann [mailto:derhoe...@gmx.net]
I know that this a major concern to you, but my impression is that few if
any other people regard that as anything more than nice to have,
especially if you equate
From: Ryosuke Niwa [mailto:rn...@apple.com]
Shouldn't we throw in this case because the concert type of somename is
HTMLUnknownElement?
Yes, that's exactly the current design. Hidden a bit:
https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L4
This still
On Jan 13, 2015, at 11:31 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/13/15 1:33 PM, Ryosuke Niwa wrote:
Shouldn't we throw in this case because the concert type of somename is
HTMLUnknownElement?
Oh, hmm.
Yes, I guess so. That's very non-obvious to an author.
Even less obvious
On 1/13/15 1:33 PM, Ryosuke Niwa wrote:
Shouldn't we throw in this case because the concert type of somename is
HTMLUnknownElement?
Oh, hmm.
Yes, I guess so. That's very non-obvious to an author.
Even less obvious because for some tag names using the HTMLElement
constructor is in fact
On Jan 13, 2015, at 10:45 AM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Shouldn't we throw in this case because the concert type of somename is
HTMLUnknownElement?
Yes, that's exactly the current design. Hidden a bit:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Or, we could always throw an exception in the constructor of
HTMLUnknownElement so that nobody could do it. It would mean that libraries
and frameworks that do support custom elements without - would have to use
document.createElement but that
On Jan 13, 2015, at 10:53 AM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Or, we could always throw an exception in the constructor of
HTMLUnknownElement so that nobody could do it. It would mean that libraries
and frameworks that do support
On 1/11/15 2:33 PM, Domenic Denicola wrote:
Terminology: In what follows I use 'own-instances of X' to mean objects where
obj.constructor === X,
That doesn't make much sense to me as a useful test, since it's pretty
simple to produce, say, an HTMLParagraphElement instance on the web that
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
That said, I do have one question already: what does the term own-instances
mean in that document?
Explained at the top:
Terminology: In what follows I use 'own-instances of X' to mean objects where
obj.constructor === X, as distance from
On 1/9/15 8:01 PM, Domenic Denicola wrote:
I was writing up my ideas in an email but it kind of snowballed into something
bigger so now it's a repo: https://github.com/domenic/element-constructors
Domenic, thanks for putting this together.
Caveat: I won't get a chance to read through this
OK, so I've thought about this a lot, and there was some discussion on an
unfortunately-TC39-private thread that I want to put out in the open. In [1] I
outlined some initial thoughts, but that was actually a thread on a different
topic, and my thinking has evolved.
[1]:
On 1/7/15 6:17 AM, Anne van Kesteren wrote:
The main tricky thing here I think is whether it is acceptable to have
an element whose name is a, namespace is the HTML namespace, and
interface is Element.
That depends on what you mean by interface is Element.
If you mean that it has all the
On Wed, Jan 7, 2015 at 2:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If you mean not having the internal slots HTMLAnchorElement has, then that
would involve a good bit of both specification and implementation work.
That is what I meant. Otherwise in order to support new Element()
you'd have
On 1/7/15 9:51 AM, Anne van Kesteren wrote:
That is what I meant. Otherwise in order to support new Element()
you'd have to support an ever growing set of more specific objects as
well and layering is out of the window.
Do you mean layering of implementations or specifications? For
28 matches
Mail list logo
