Re: Base Template (Was Re: Minimum viable custom elements)

Jan, As for the following, in https://github.com/JanMiksovsky/base-template), > A web component spec bug tried to resolve this question by fixing the platform, but an initial Blink implementation

Re: Base Template (Was Re: Minimum viable custom elements)

Dimitri: Okay, I can follow up with Ryosuke. I’m happy to share our thoughts and needs for subclassing components. Anne/Steve: I’d originally indicated that this technique couldn't be applied to extending native HTML elements. Since the two of your seemed interested in that, I spent some time t

Re: Base Template (Was Re: Minimum viable custom elements)

at you want to solve, no? > > > The problem I think needs solving for minimum viable custom elements is > reducing reliance on bolt-on accessibility. From the example provided > http://janmiksovsky.github.io/base-template/ it appears that in this > instance it does achieve that end.

Base Template (Was Re: Minimum viable custom elements)

> On Feb 12, 2015, at 4:50 AM, Steve Faulkner wrote: > > > On 12 February 2015 at 10:58, Anne van Kesteren <mailto:ann...@annevk.nl>> wrote: > which is a very different problem from what you want to solve, no? > > The problem I think needs solving for min

Re: Minimum viable custom elements

On 12 February 2015 at 10:58, Anne van Kesteren wrote: > which is a very different problem from what you want to solve, no? The problem I think needs solving for minimum viable custom elements is reducing reliance on bolt-on accessibility. From the example provided h

Re: Minimum viable custom elements

On Thu, Feb 12, 2015 at 11:33 AM, Steve Faulkner wrote: > this turned up today: > A possible solution for web component subclasses > https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses > > needs people who actually understand this stuff to critique ;-) W

Re: Minimum viable custom elements

this turned up today: A possible solution for web component subclasses https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses needs people who actually understand this stuff to critique ;-) -- Regards SteveF HTML 5.1

RE: Minimum viable custom elements

On Wed Feb 4 02:08 PM, Ryosuke Niwa wrote: > > > step="5"> > To me this seems like a winning pattern at least when it comes to input. This did a good job a describing the two approaches: https://wiki.whatwg.org/wiki/Behavior_Attachment Where does the decorator pattern/approach stand?

Re: Minimum viable custom elements

On Fri, Feb 6, 2015 at 2:13 AM, Chris Bateman wrote: > ** Bonus issue - I didn't know this, but Chrome doesn't upgrade when you add > the is= attribute to an element that's already been created. Ember builds up > its templates into document fragments - so the input failed to upgrade in > Chrome. T

Re: Minimum viable custom elements

Thanks for the mentioning the Ember issue Chris :) I've filed it here: https://github.com/tildeio/htmlbars/issues/288 On Thu, Feb 5, 2015 at 7:13 AM, Chris Bateman wrote: > As an example I made a simple input-based Custom Element which prevents > alphabetic input, and dropped it in an very simple

Re: Minimum viable custom elements

As an example I made a simple input-based Custom Element which prevents alphabetic input, and dropped it in an very simple Ember app. Here's the version with a subclassed : http://jsbin.com/mevemu/1/edit?html,output And the version with an nested in a custom element: http://jsbin.com/hepuvif/1/e

Re: Minimum viable custom elements

> On Feb 4, 2015, at 11:26 AM, Alice Boxhall wrote: > > So a web page author would write > > > and then the custom element would sprout an with > the attribute values copied across? No. The page author would write . - R. Niwa

Re: Minimum viable custom elements

On 4 February 2015 at 19:05, Alice Boxhall wrote: > So then how do we treat it as "fallback content" i.e. un-rendered, while > allowing it to be accessible to to the AT layer? I suggest as in the working canvas example i provided, it not only be exposed AT but also to keyboard interaction, and

Re: Minimum viable custom elements

So a web page author would write and then the custom element would sprout an with the attribute values copied across? Then the web page author knows nothing about the element, so if they want to programmatically the value of the custom element, they'd modify an attribute on it, rather than the

Re: Minimum viable custom elements

> On Feb 4, 2015, at 11:11 AM, Chris Bateman wrote: > > Ugh, I forgot about that. Without subclassing - terseness is a very minor > drawback, but remapping the interface is a big pain. Could you give us a concrete use case in which remapping the interface is necessary or hard/impossible to d

Re: Minimum viable custom elements

> On Feb 4, 2015, at 11:05 AM, Alice Boxhall wrote: > > On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell > wrote: > > On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall > wrote: > On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa

Re: Minimum viable custom elements

Ugh, I forgot about that. Without subclassing -  terseness is a very minor drawback, but remapping the interface is a big pain. On Wed, Feb 4, 2015 at 1:01 PM, Brian Kardell wrote: > On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall wrote: >> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa wrote: >

Re: Minimum viable custom elements

> On Feb 4, 2015, at 10:54 AM, Alice Boxhall wrote: > > On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa > wrote: > >> On Feb 4, 2015, at 10:12 AM, Brian Kardell > > wrote: >> >> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman >

Re: Minimum viable custom elements

On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell wrote: > > > On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall wrote: > >> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa wrote: >> >>> >>> On Feb 4, 2015, at 10:12 AM, Brian Kardell wrote: >>> >>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman >>> wr

Re: Minimum viable custom elements

On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall wrote: > On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa wrote: > >> >> On Feb 4, 2015, at 10:12 AM, Brian Kardell wrote: >> >> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman >> wrote: >> >>> Yeah, I had noted in that post that wrapping a native elem

Re: Minimum viable custom elements

On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa wrote: > > On Feb 4, 2015, at 10:12 AM, Brian Kardell wrote: > > On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman > wrote: > >> Yeah, I had noted in that post that wrapping a native element with a >> custom element was an option - only drawback is tha

Re: Minimum viable custom elements

> On Feb 4, 2015, at 10:12 AM, Brian Kardell wrote: > > On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman > wrote: > Yeah, I had noted in that post that wrapping a native element with a custom > element was an option - only drawback is that the markup isn't as terse >

Re: Minimum viable custom elements

> On Feb 4, 2015, at 9:05 AM, Steve Faulkner wrote: > > On 4 February 2015 at 16:51, Ryosuke Niwa > wrote: > > > I think if this worked. i.e. hid the styling and allowed styling over top, > while allowing access to the input functionality would be a good solution for

Re: Minimum viable custom elements

On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman wrote: > Yeah, I had noted in that post that wrapping a native element with a > custom element was an option - only drawback is that the markup isn't as > terse (which is generally advertised as one of the selling points of Custom > Elements). But th

Re: Minimum viable custom elements

Yeah, I had noted in that post that wrapping a native element with a custom element was an option - only drawback is that the markup isn't as terse (which is generally advertised as one of the selling points of Custom Elements). But that doesn't seem like a deal breaker to me, if subclassing nee

Re: Minimum viable custom elements

On 4 February 2015 at 16:51, Ryosuke Niwa wrote: > > I think if this worked. i.e. hid the styling and allowed styling over top, while allowing access to the input functionality would be a good solution for the many many instances of native controls being remade as custom controls simply to be a

Re: Minimum viable custom elements

See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html first. > On Feb 4, 2015, at 6:43 AM, Chris Bateman wrote: > > Assuming a situation where a native element – with custom functionality – is >

Re: Minimum viable custom elements

> On Feb 4, 2015, at 7:59 AM, Domenic Denicola wrote: > > In IRC Anne and I were briefly discussing how type="" is the is="" of Web > Applications 1.0. That is, is similar to > or similar---it has a reasonable fallback behavior, but in reality it is a > completely different control than the

RE: Minimum viable custom elements

I hope others can address the question of why custom element callbacks are useful, and meet the bar of being a feature we should add to the web platform (with all the UA-coordination that requires). I just wanted to interject into this discussion. In IRC Anne and I were briefly discussing how

Re: Minimum viable custom elements

On Wed, Feb 4, 2015 at 3:43 PM, Chris Bateman wrote: > An better example of both A and B (than my previous hypothetical) might be > GitHub's extension: > https://github.com/github/time-elements/. FWIW, I do want subclassing of builtins to work. Maybe not necessarily at first, but definitely down

Re: Minimum viable custom elements

Assuming a situation where a native element – with custom functionality – is dynamically injected into the page, the basic options I can think of are: - - and a page-level listener - and call a function after it's injected Option 3 is really cumbersome, in my opinion. Option 2 could work, e

Re: Minimum viable custom elements

> On Feb 3, 2015, at 7:13 AM, Chris Bateman wrote: > > Why don't we just make all input elements support these new attributes we're > adding? > > In my opinion, I'd say because you can't possibly cover every case - what > about doing the same kind of formatting for social security numbers, cr

Re: Minimum viable custom elements

> > Why don't we just make all input elements support these new attributes > we're adding? In my opinion, I'd say because you can't possibly cover every case - what about doing the same kind of formatting for social security numbers, credit card numbers, phone numbers, or who knows what else? How

Re: Minimum viable custom elements

> On Jan 31, 2015, at 10:40 AM, Chris Bateman wrote: > > The -webkit-appreance CSS is definitely another issue, so here's an example > with just JS behavior: > > > > This component would only allow numeric input, and insert decimals, commas, > etc. Let's just assume that devs want to do thi

Re: Minimum viable custom elements

The -webkit-appreance CSS is definitely another issue, so here's an example with just JS behavior: This component would only allow numeric input, and insert decimals, commas, etc. Let's just assume that devs want to do this kind of thing. Here's an example I found of a such behavior: http://open

Re: Minimum viable custom elements

That does not prevent the entering of alphabetic characters, does not add commas, and does not format to a precise number of decimals . Maybe you'd argue that these things shouldn't be done - but I'd think the existence of multiple libraries that do these things demonstrates that it's a valid need.

Re: Minimum viable custom elements

On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren wrote: > On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner > wrote: > > In this radio and checkbox example (view in chrome) > > https://rawgit.com/alice/web-components-demos/master/index.html > > (which has been referenced several times in this t

Re: Minimum viable custom elements

On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren wrote: > On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner > wrote: > > In this radio and checkbox example (view in chrome) > > https://rawgit.com/alice/web-components-demos/master/index.html > > (which has been referenced several times in this t

Re: Minimum viable custom elements

On Sat, Jan 31, 2015 at 7:40 PM, Chris Bateman wrote: > The -webkit-appreance CSS is definitely another issue, so here's an example > with just JS behavior: > > The way to do this, FWIW, is and solve the styling issue. -- https://annevankesteren.nl/

Re: Minimum viable custom elements

On Sat, Jan 31, 2015 at 10:41 PM, Elliott Sprehn wrote: > The animation is a custom element called , where do you see it > using -webkit-tap-highlight-color? The initial page uses that. Ryosuke's reply to this particular demo is a lot more on topic. It's not using is="". (Use of proprietary CSS f

Re: Minimum viable custom elements

On Sat, Jan 31, 2015 at 7:47 PM, Anne van Kesteren wrote: > On Fri, Jan 30, 2015 at 7:22 PM, Alice Boxhall > wrote: > > Sure, that works for this example (which was created in a huge rush at > the > > last minute before a talk, like probably 90% of my productive work), but > I > > don't believe

Re: Minimum viable custom elements

On Sat, Jan 31, 2015 at 5:58 AM, fantasai wrote: > -webkit-appearance: none isn't a proprietary extension, it's a prefixed > version of something that was once in a standards-track document. It > got removed because there were serious design problems with the original > idea, but some values stuck

Re: Minimum viable custom elements

On Sat, Jan 31, 2015 at 8:25 AM, Tantek Çelik wrote: > I'm tracking the state of requests for 'appearance' here: > > https://wiki.csswg.org/spec/css4-ui#appearance > > Feel free to directly edit that wiki page and add more concrete data / > research that you think will help make a decision in term

Re: Minimum viable custom elements

On Fri, Jan 30, 2015 at 7:22 PM, Alice Boxhall wrote: > Sure, that works for this example (which was created in a huge rush at the > last minute before a talk, like probably 90% of my productive work), but I > don't believe it wouldn't work for > http://www.polymer-project.org/components/paper-rad

Re: Minimum viable custom elements

I'm tracking the state of requests for 'appearance' here: https://wiki.csswg.org/spec/css4-ui#appearance Feel free to directly edit that wiki page and add more concrete data / research that you think will help make a decision in terms of design etc. For now, there is insufficient data to show an

Re: Minimum viable custom elements

On 01/30/2015 07:54 PM, Ryosuke Niwa wrote: On Jan 30, 2015, at 10:22 AM, Alice Boxhall mailto:aboxh...@google.com>> wrote: The only way it overcomes that is by relying on a proprietary extension called -webkit-appearance that is not standardized and does not work reliably across b

Re: Minimum viable custom elements

> On Jan 30, 2015, at 10:22 AM, Alice Boxhall wrote: > > On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren > wrote: > On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner > mailto:faulkner.st...@gmail.com>> wrote: > > In this radio and checkbox example (view in chrome) > >

Re: Minimum viable custom elements

> On Jan 30, 2015, at 1:02 AM, Bruce Lawson wrote: > > On 29 January 2015 at 19:48, Ryosuke Niwa wrote: >> And we have a proposal to do both of these things: decorators [1] > > yes, indeed. What is the status of decorators? Last I looked, it had > been removed from the "web components" umbrell

Re: Minimum viable custom elements

On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner wrote: > In this radio and checkbox example (view in chrome) > https://rawgit.com/alice/web-components-demos/master/index.html > (which has been referenced several times in this thread, but no one has > critiqued to my knowledge) all of the above ar

Re: Minimum viable custom elements

I am not championing is= as the answer to all the worlds ills, but it does provide *examples* of built in features that I believe are critical to robust accessibility support in web components: which are: roles/state and property mapping from existing attributes (disabled, required etc) platform/b

Re: Minimum viable custom elements

On 29 January 2015 at 19:48, Ryosuke Niwa wrote: > And we have a proposal to do both of these things: decorators [1] yes, indeed. What is the status of decorators? Last I looked, it had been removed from the "web components" umbrella, so I thought it had been sent to a farm upstate, but I haven'

Re: Minimum viable custom elements

On Thu, Jan 29, 2015 at 2:43 PM, Bruce Lawson wrote: [snip] > "a really first-class fallback option if you don't support JS" is > vital for the quarter of a billion people who use Opera Mini and the > 100 million people who use the Nokia proxy browser. Fallback rather > than non-functional pages

Re: Minimum viable custom elements

> On Jan 29, 2015, at 7:52 AM, Steve Faulkner wrote: > On 29 January 2015 at 15:37, Anne van Kesteren > wrote: > I don't have enough technical understanding to know what is viable or not, > you and others are saying that the current accessibility feature support > bake

Re: Minimum viable custom elements

On 29 January 2015 at 19:09, Brian Kardell wrote: > composition actually seems to let you express something equally good without > ambiguity more easily except insofar as giving you a really first-class > fallback option if you don't support JS, but... I'm having a really hard > time imagining mor

Re: Minimum viable custom elements

On Thu, Jan 29, 2015 at 1:50 PM, Elliott Sprehn wrote: > > > On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell wrote: > >> >> >> On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson wrote: >> >>> On 29 January 2015 at 14:54, Steve Faulkner >>> wrote: >>> > I think being able to extend existing elements

Re: Minimum viable custom elements

On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell wrote: > > > On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson wrote: > >> On 29 January 2015 at 14:54, Steve Faulkner >> wrote: >> > I think being able to extend existing elements has potential value to >> > developers far beyond accessibility (it ju

Re: Minimum viable custom elements

On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson wrote: > On 29 January 2015 at 14:54, Steve Faulkner > wrote: > > I think being able to extend existing elements has potential value to > > developers far beyond accessibility (it just so happens that > accessibility > > is helped a lot by re-use of

Re: Minimum viable custom elements

> > I don't have enough technical understanding to know what is viable or not, >> you and others are saying that the current accessibility feature support >> baked in to custom elements spec via is= is not acceptable >> >> That seems rather disingenuous. > where am I being disingenuous? I don't

Re: Minimum viable custom elements

One additional point, unrelated to accessibility: "is" also enables piggybacking to special parser behavior of existing elements. For example, I can extend or . Here are some examples: http://jsbin.com/xuheb/3/edit?html,output https://blog.polymer-project.org/howto/2014/09/11/template-is-autobi

Re: Minimum viable custom elements

On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner wrote: > I don't have enough technical understanding to know what is viable or not, > you and others are saying that the current accessibility feature support > baked in to custom elements spec via is= is not acceptable That seems rather disingenuou

Re: Minimum viable custom elements

On 29 January 2015 at 14:54, Steve Faulkner wrote: > I think being able to extend existing elements has potential value to > developers far beyond accessibility (it just so happens that accessibility > is helped a lot by re-use of existing HTML features.) I agree with everything Steve has said a

Re: Minimum viable custom elements

> wrote: > > I have not suggested is= as the method that must be implemented (I have > not > > demanded anything), what I have tried to suggest is that minimum viable > > custom elements with all accessibility as bolt-on is a poor solution by > > design. From an

Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 8:06 PM, Domenic Denicola wrote: > From: Ryosuke Niwa [mailto:rn...@apple.com] >> However, nobody has suggested a design that satisfies both of our >> requirements: using ES6 constructor for element initialization > > Could you say more about why this is a requirement? I

Re: Minimum viable custom elements

On Jan 16, 2015, at 4:07 PM, Dimitri Glazkov wrote: > On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa wrote: > >> On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov wrote: >> On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa wrote: >> When an author imports a ES6 module, we don't create a fake object whic

Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa wrote: > > On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov wrote: > On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa wrote: >> >> When an author imports a ES6 module, we don't create a fake object which >> gets resolved later by rewriting its prototype. >

Re: Minimum viable custom elements

> On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov wrote: > On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa > wrote: > When an author imports a ES6 module, we don't create a fake object which gets > resolved later by rewriting its prototype. > > These are two completely diffe

RE: Minimum viable custom elements

From: Ryosuke Niwa [mailto:rn...@apple.com] > However, nobody has suggested a design that satisfies both of our > requirements: using ES6 constructor for element initialization Hi Ryosuke, Could you say more about why this is a requirement? In particular, why you require that developers type

Re: Minimum viable custom elements

> On Jan 16, 2015, at 9:43 AM, Steve Faulkner wrote: > > > On 16 January 2015 at 16:52, Anne van Kesteren > wrote: > Again, I think that unless we solve the styling problem for > native elements, we're not going to see them adopted, not even if you > can subclass them

Re: Minimum viable custom elements

> On Jan 16, 2015, at 9:58 AM, Anne van Kesteren wrote: > > On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa wrote: >> And I'm suggesting to do the same (picking the simplest design) in HTML >> custom elements by only supporting synchronous definition of elements, and >> letting authors and fram

Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa wrote: > And I'm suggesting to do the same (picking the simplest design) in HTML > custom elements by only supporting synchronous definition of elements, and > letting authors and frameworks decide how to "upgrade" existing elements if > they want t

Re: Minimum viable custom elements

On 16 January 2015 at 16:52, Anne van Kesteren wrote: > Again, I think that unless we solve the styling problem for > native elements, we're not going to see them adopted, not even if you > can subclass them (and proper subclassing without the is="" hack is > another hard problem, as explained).

Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 5:45 PM, Steve Faulkner wrote: > I have not suggested is= as the method that must be implemented (I have not > demanded anything), what I have tried to suggest is that minimum viable > custom elements with all accessibility as bolt-on is a poor solution by > d

Re: Minimum viable custom elements

Hi Anne, I have not suggested is= as the method that must be implemented (I have not demanded anything), what I have tried to suggest is that minimum viable custom elements with all accessibility as bolt-on is a poor solution by design. From an acc view it means custom elements are nothing more

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 8:18 PM, Dimitri Glazkov wrote: > Why is "Not having identity at creation-time is currently a mismatch with > the rest of the platform" a problem? Why does it all have to be consistent > across the board? Are there any other platform objects that are created by > HTML parse

Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 11:25 AM, Steve Faulkner wrote: > With custom tags everything must be bolted on, with type extensions this is > not the case. I don't disagree with this, but is="" solves none of the problems of why developers moved away from native elements in the first place. As long as

Re: Minimum viable custom elements

On 16 January 2015 at 10:25, Steve Faulkner wrote: > https://rawgit.com/alice/web-components-demos/master/index.html apologies, this demo needs chrome to illustrate it working well. -- Regards SteveF HTML 5.1

Re: Minimum viable custom elements

hi ted, I think others have responded to your question, but wanted to chip in. I agree that for non interactive elements the usefulness of type extensions is limited, but not useless. For example: An experiment subclassing footer [5] and one implementing the HTML5 outline algorithm [6] There has

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa wrote: > > > On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov > wrote: > > > > FWIW, I think that element upgrade is sort of fundamental to the > usefulness of custom elements. In a world where most scripts are > non-blocking (that's hopefully the moder

Re: Minimum viable custom elements

> On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov wrote: > > FWIW, I think that element upgrade is sort of fundamental to the usefulness > of custom elements. In a world where most scripts are non-blocking (that's > hopefully the modern world we should aim for), I'll effectively expect to > wal

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 5:29 PM, Ryosuke Niwa wrote: > > The only reason you need to have the two-stage setup is because you want > to support asynchronous upgrading of elements. As we have repeatedly > stated in the past, we don't support a design that involves upgrading > elements after the el

Re: Minimum viable custom elements

> On Jan 15, 2015, at 3:17 PM, Domenic Denicola wrote: > > From: Ryosuke Niwa [mailto:rn...@apple.com] > >> If ES6 classes' constructor doesn't fundamentally work with custom elements, >> then why don't we change the design of ES6 classes. > > We would essentially be saying that the design o

Re: Minimum viable custom elements

ssage- > From: Edward O'Connor [mailto:eocon...@apple.com] > Sent: Thursday, January 15, 2015 18:33 > To: WebApps WG > Subject: Re: Minimum viable custom elements > > Hi all, > > Steve wrote: > > >> [I]t also does not address subclassing normal element

RE: Minimum viable custom elements

of the disabled attribute, etc. -Original Message- From: Edward O'Connor [mailto:eocon...@apple.com] Sent: Thursday, January 15, 2015 18:33 To: WebApps WG Subject: Re: Minimum viable custom elements Hi all, Steve wrote: >> [I]t also does not address subclassing normal eleme

Re: Minimum viable custom elements

Hi all, Steve wrote: >> [I]t also does not address subclassing normal elements. Again, while >> that seems desirable > > Given that subclassing normal elements is the easiest and most robust > method (for developers) of implementing semantics[1] and interaction > support necessary for accessibili

RE: Minimum viable custom elements

From: Ryosuke Niwa [mailto:rn...@apple.com] > Unfortunately for developers, native syntax for inheritance in Stink 2.0 > cannot be used to subclass views in Odour. The native syntax for inheritance can definitely be used! You just can't override the constructor, since constructing a view is a

Re: Minimum viable custom elements

> On Jan 15, 2015, at 11:28 AM, Domenic Denicola wrote: > > From: Dimitri Glazkov [mailto:dglaz...@google.com] > >> Why is "Not having identity at creation-time is currently a mismatch with >> the rest of the platform" a problem? Why does it all have to be consistent >> across the board? Are

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 12:27 PM, Ryosuke Niwa wrote: >> On Jan 15, 2015, at 11:47 AM, Brian Kardell wrote: >> Not to sidetrack the discussion but Steve Faulker made what I think was a >> valid observation and I haven't seen a response... Did I miss it? > > When and in which thread? Could you g

Re: Minimum viable custom elements

> On Jan 15, 2015, at 11:47 AM, Brian Kardell wrote: > > Not to sidetrack the discussion but Steve Faulker made what I think was a > valid observation and I haven't seen a response... Did I miss it? When and in which thread? Could you give us a pointer? - R. Niwa

Re: Minimum viable custom elements

Not to sidetrack the discussion but Steve Faulker made what I think was a valid observation and I haven't seen a response... Did I miss it?

RE: Minimum viable custom elements

From: Dimitri Glazkov [mailto:dglaz...@google.com] > Why is "Not having identity at creation-time is currently a mismatch with the > rest of the platform" a problem? Why does it all have to be consistent across > the board? Are there any other platform objects that are created by HTML > parser

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren wrote: > > > * I think we could iterate towards a v2 that has an aspect of > upgrading but perhaps works a bit differently from the current setup. > E.g. a way to include an entire subtree of custom elements with a > fallback mechanism of sorts. O

Re: Minimum viable custom elements

No argument that callbacks are also a useful new addition. :DG<

Re: Minimum viable custom elements

Thanks, this is very useful! On Thu Jan 15 2015 at 5:40:02 PM Anne van Kesteren wrote: > On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen > wrote: > > Anne, maybe you could write on the wiki what the current Web Components > > implementation in Chrome is using. That would make it a b

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen wrote: > Anne, maybe you could write on the wiki what the current Web Components > implementation in Chrome is using. That would make it a bit easier to follow > for people who didn't follow all of the discussion so far. I updated the pa

Re: Minimum viable custom elements

Anne, maybe you could write on the wiki what the current Web Components implementation in Chrome is using. That would make it a bit easier to follow for people who didn't follow all of the discussion so far. Kenneth On Thu Jan 15 2015 at 5:05:35 PM Anne van Kesteren wrote: > On Wed, Jan 14, 201

Re: Minimum viable custom elements

On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov wrote: > FWIW, I think that element upgrade is sort of fundamental to the usefulness > of custom elements. In a world where most scripts are non-blocking (that's > hopefully the modern world we should aim for), I'll effectively expect to > walk the

Re: Minimum viable custom elements

On Wed, Jan 14, 2015 at 9:25 PM, Ryosuke Niwa wrote: >> On Jan 14, 2015, at 6:45 AM, Anne van Kesteren wrote: >> * Existing lifecycle callbacks plus those agreed (copying, adopting). > > Could you give us pointers for a proposed definition of these two callbacks > if there is any? I added a sho

Re: Minimum viable custom elements

FWIW, I think that element upgrade is sort of fundamental to the usefulness of custom elements. In a world where most scripts are non-blocking (that's hopefully the modern world we should aim for), I'll effectively expect to walk the tree anyway. And if I walk the tree anyway, what's the point of

Re: Minimum viable custom elements

> On Jan 14, 2015, at 12:25 PM, Domenic Denicola wrote: > > From: Ryosuke Niwa [mailto:rn...@apple.com] > >> Let me restate the problem using an example. Suppose we're parsing >> . >> >> Once the HTML is parsed, the DOM tree is constructed with two DOM elements. >> Now we call the constru

Re: Minimum viable custom elements

> On Jan 14, 2015, at 6:45 AM, Anne van Kesteren wrote: > > I've been trying to think of the smallest setup that adds value, can > get broad agreement, and is therefore hopefully interoperable fast. > > * ES6-style class syntax to declare the imperative constructor. > * No subclassing of normal

  1   2   >