On Fri, Dec 13, 2013 at 5:59 PM, Maciej Stachowiak wrote:
>
> On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote:
>
>
>>
> Built-in HTML elements have lots of hooks to modify their behaviour (for
> example, HTMLVideoElement's autoplay attribute.) The analogy is extending a
> Java class which has p
On Dec 10, 2013, at 12:24 PM, Elliott Sprehn wrote:
>
> On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren wrote:
> On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky wrote:
> > On 12/10/13 10:34 AM, Anne van Kesteren wrote:
> >> E.g. the 's close() method won't work as defined
> >> right now on
On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote:
>
>
> Built-in HTML elements have lots of hooks to modify their behaviour (for
> example, HTMLVideoElement's autoplay attribute.) The analogy is extending a
> Java class which has private and public final members, but no protected or
> publi
On Dec 10, 2013, at 9:20 AM, Erik Arvidsson wrote:
> On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren wrote:
> On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola
> wrote:
> > Nevertheless, it would be unfortunate to use the in-progress nature of
> > making the web platform more JavaScript-fri
On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren wrote:
> On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky wrote:
> > On 12/10/13 10:34 AM, Anne van Kesteren wrote:
> >> E.g. the 's close() method won't work as defined
> >> right now on a subclass of HTMLDialogElement.
> >
> > Why not?
> >
> > I
On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren wrote:
> On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola
> wrote:
> > Nevertheless, it would be unfortunate to use the in-progress nature of
> making the web platform more JavaScript-friendly as an argument for making
> it more JavaScript host
On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola
wrote:
> Nevertheless, it would be unfortunate to use the in-progress nature of making
> the web platform more JavaScript-friendly as an argument for making it more
> JavaScript hostile (by prohibiting element subclassing).
Well, the question is
From: a...@google.com on behalf of Erik Arvidsson
> On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren wrote:
>
>> I think Ryosuke has a point here though. ES6 brings subclassing to the
>> platform, but are not even close to reimagining the platform in terms of
>> that.
>
> ES6 does not br
On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky wrote:
> On 12/10/13 10:34 AM, Anne van Kesteren wrote:
>> E.g. the 's close() method won't work as defined
>> right now on a subclass of HTMLDialogElement.
>
> Why not?
>
> I assumed that actual ES6 subclassing, complete with invoking the right
> sup
On Tue, Dec 10, 2013 at 3:53 PM, Erik Arvidsson wrote:
>> I think Ryosuke has a point here though. ES6 brings subclassing to the
>> platform, but are not even close to reimagining the platform in terms
>> of that.
>
> ES6 does not bring sub classing to the table. It has been there all along
> (sin
On 12/10/13 10:34 AM, Anne van Kesteren wrote:
E.g. the 's close() method won't work as defined
right now on a subclass of HTMLDialogElement.
Why not?
I assumed that actual ES6 subclassing, complete with invoking the right
superclass @@create, would in fact produce an object for which this
w
On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren wrote:
> I think Ryosuke has a point here though. ES6 brings subclassing to the
> platform, but are not even close to reimagining the platform in terms
> of that.
ES6 does not bring sub classing to the table. It has been there all along
(since
On Mon, Dec 9, 2013 at 12:42 AM, Dominic Cooney wrote:
> You assert that inheriting from built-in elements does not make any sense.
> You seem to base this on the claim that hooks (the example being form
> submission protocol hooks) are not well defined. Whether hooks are well
> defined or not doe
On Dec 9, 2013, at 8:45 PM, "Tab Atkins Jr." wrote:
> On Tue, Dec 10, 2013 at 3:33 PM, Ryosuke Niwa wrote:
>> In fact, why do we even bother to add any new API at all for web components
>> if our primary target was framework authors. Ember.js, Angular JS, etc...
>> all work great already because
On Tue, Dec 10, 2013 at 3:33 PM, Ryosuke Niwa wrote:
> In fact, why do we even bother to add any new API at all for web components
> if our primary target was framework authors. Ember.js, Angular JS, etc...
> all work great already because they add an abstraction layer on top of DOM.
> As current
On Dec 9, 2013, at 5:12 PM, Dominic Cooney wrote:
> On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa wrote:
> On Dec 8, 2013, at 4:42 PM, Dominic Cooney wrote:
>> On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa wrote:
>> On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote:
>>> On Fri, Dec 6, 2013 at 3:
On Mon, Dec 9, 2013 at 5:50 PM, Brendan Eich wrote:
> Ryosuke Niwa wrote:
>
>> As for the social "endorse" button, I've never seen a popular SNS share
>> buttons implemented using HTML button elements; most of them add their own
>> DOM to add icons, etc...
>>
>
> Right you are. And there's a deepe
Ryosuke Niwa wrote:
As for the social "endorse" button, I've never seen a popular SNS
share buttons implemented using HTML button elements; most of them add
their own DOM to add icons, etc...
Right you are. And there's a deeper reason why "like" ("endorse", LOL)
buttons use iframes: the abili
On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa wrote:
> On Dec 8, 2013, at 4:42 PM, Dominic Cooney wrote:
>
> On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa wrote:
>>
>> On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote:
>>
>> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa wrote:
>>
>>> On Dec 5, 2
On Dec 8, 2013, at 4:42 PM, Dominic Cooney wrote:
> On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa wrote:
> On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote:
>> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa wrote:
>> On Dec 5, 2013, at 10:09 PM, Hajime Morrita wrote:
>> > On inheritance around HT
On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa wrote:
>
> On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote:
>
> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa wrote:
>
>> On Dec 5, 2013, at 10:09 PM, Hajime Morrita wrote:
>> > On inheritance around HTMLElement family, there seems to be a confusion
± > If someone were to make proposals about adding more hooks to the web
± platform to enable more subtyping use cases (for example, a protocol for
± participating in form submission) I would look forward to working with them
± on those proposals.
±
± I am very interested in such proposals and I
> On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote:
>
>> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa wrote:
>> On Dec 5, 2013, at 10:09 PM, Hajime Morrita wrote:
>> > On inheritance around HTMLElement family, there seems to be a confusion
>> > between interface side inheritance and implement
From: Dominic Cooney [mailto:domin...@google.com]
> If someone were to make proposals about adding more hooks to the web platform
> to enable more subtyping use cases (for example, a protocol for participating
> in form submission) I would look forward to working with them on those
> proposals
On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa wrote:
> On Dec 5, 2013, at 10:09 PM, Hajime Morrita wrote:
> > On inheritance around HTMLElement family, there seems to be a confusion
> between interface side inheritance and implementation side inheritance.
>
> Right. Differentiating the two is ve
I agree that it isn't trivial to inherit from a built-in element as if it
is an author-defined element.
My point was that mentioning relationship between HTMLElement and built-in
elements on WebIDL doesn't matter in this discussion and we should focus on
other reasoning.
On Fri, Dec 6, 2013 at 3:
On Dec 5, 2013, at 10:09 PM, Hajime Morrita wrote:
> On inheritance around HTMLElement family, there seems to be a confusion
> between interface side inheritance and implementation side inheritance.
Right. Differentiating the two is very important.
> For Custom Elements, the inheritance is not
On inheritance around HTMLElement family, there seems to be a confusion
between interface side inheritance and implementation side inheritance.
In WebIDL, interfaces of HTML elements have inherited only from HTMLElement
interface. This is fine just because it cares only about interface (API
signat
On Dec 5, 2013, at 9:30 PM, Dimitri Glazkov wrote:
> On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa wrote:
> On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov wrote:
>> On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa wrote:
>> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov wrote:
>> > 3) The approach pollu
On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa wrote:
> Thanks.
>
> On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov wrote:
>
> On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa wrote:
>
>> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov
>> wrote:
>> > 3) The approach pollutes global name space with construc
Thanks.
On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov wrote:
> On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa wrote:
> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov wrote:
> > 3) The approach pollutes global name space with constructors. This had been
> > voiced many times as unacceptable by develo
On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa wrote:
> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov
> wrote:
> > 3) The approach pollutes global name space with constructors. This had
> been voiced many times as unacceptable by developers.
> >
> > 4) How does build a custom element that uses as
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov wrote:
> 3) The approach pollutes global name space with constructors. This had been
> voiced many times as unacceptable by developers.
>
> 4) How does build a custom element that uses as its base element?
> What about or any other HTML element?
>
33 matches
Mail list logo
