On Mon, Jan 19, 2015 at 11:01 AM, Simon Pieters 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
> this? Should
On Fri, 16 Jan 2015 20:08:30 +0100, Domenic Denicola 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 like HTMLQuoteEl
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
https://
On Fri, Jan 16, 2015 at 12:34 AM, Domenic Denicola wrote:
> One interesting thing that falls out of the design is that it's trivial to
> allow a custom element class to be registered for multiple names; it requires
> no more work on the part of the class author than writing a class that
> corre
part of the class author than writing a class that
corresponds to a single name, and is painless to use for consumers.
-Original Message-
From: Domenic Denicola [mailto:d...@domenic.me]
Sent: Friday, January 9, 2015 20:01
To: Anne van Kesteren; WebApps WG; www-...@w3.org
Subject: RE: D
On Wed, Jan 14, 2015 at 5:26 AM, Domenic Denicola 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 makes sense to
> On Jan 13, 2015, at 8:26 PM, 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 "expla
* 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
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
* 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 thi
On Jan 13, 2015, at 11:31 AM, Boris Zbarsky 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 beca
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 co
On Jan 13, 2015, at 10:53 AM, Domenic Denicola 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 custom elemen
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
On Jan 13, 2015, at 10:45 AM, Domenic Denicola 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:
>
> https://github.com/domenic/
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 10:22 AM, Boris Zbarsky 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 introd
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 p
> On Jan 13, 2015, at 9:25 AM, Domenic Denicola 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 HTMLElement(
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 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 document.createEl
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
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
ha
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 car
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]: http://lists.w3.org/Ar
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
specificat
On Wed, Jan 7, 2015 at 2:32 PM, Boris Zbarsky 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 to support an ev
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 i
The important local slots for an element are its local name, prefix,
and namespace. I believe that for certain operations in HTML it is
also important to be able to instantiate an element along with several
attributes given by the parser so that when the first initialize
operations runs it has acce
30 matches
Mail list logo
