[Custom Elements] Should I write v1 Custom Elements in a way backwards compatible with v0 API?

2016-08-20 Thread /#!/JoePea
Callback() } // back-compat disconnectedCallback() { // code removed for brevity... } detachedCallback() { this.disconnectedCallback() } // back-compat } classCache.set(elementClass, WebComponent) return WebComponent } Any thoughts? */#!/*JoePea

Re: [Custom Elements] Not requiring hyphens in names.

2016-04-22 Thread /#!/JoePea
t; discussion: > https://github.com/w3c/webcomponents/issues/239#issuecomment-190603674 > > > On Fri, Apr 15, 2016 at 7:01 AM, /#!/JoePea wrote: > >> On Wed, Apr 13, 2016 at 1:09 PM, Tab Atkins Jr. >> wrote: >> > That means we lose the lingua franca that HTML provide

Re: [Custom Elements] Not requiring hyphens in names.

2016-04-14 Thread /#!/JoePea
adow roots or the document, it's contained within the shadow root. ``` This would be awesome I think. It'd allow for a level of encapsulation and modularization on a shadow-root basis (which can paired with Custom Elements very nicely). /#!/JoePea

Re: [Custom Elements] Not requiring hyphens in names.

2016-04-13 Thread /#!/JoePea
ide them. Riot.js likes not requiring hyphens too! /#!/JoePea On Wed, Apr 13, 2016 at 11:53 AM, Nick Dugger wrote: > I personal don't mind the hyphenation requirement for custom elements. Tab > Atkins brings up a great point about ensuring that new elements will be able > to be ad

[Custom Elements] Not requiring hyphens in names.

2016-04-13 Thread /#!/JoePea
meElement', SomeElement) document.body.appendChild(document.createElement('someelement')) ``` /#!/JoePea

Re: [Custom Elements] They are globals.

2016-04-12 Thread /#!/JoePea
js import HandyForm from './HandyForm' // elements registered on the document won't cross into shadow roots document.registerElement('handy-form', HandyForm) document.body.appendChild(document.createElement('handy-form')) ``` - Joe /#!/JoePea

Re: [Custom Elements] They are globals.

2016-04-11 Thread /#!/JoePea
dvantage of JavaScript scope directly without build tools: ``` import SomeClass from './SomeClass' import OtherClass from './OtherClass' html` <${SomeClass}> <${OtherClass}> ` ``` /#!/JoePea On Mon, Apr 11, 2016 at 11:2

Re: [Custom Elements] More ES6-like API

2016-04-11 Thread /#!/JoePea
Thanks Ryosuke! That's looking a lot better. /#!/JoePea On Mon, Apr 11, 2016 at 10:28 AM, Ryosuke Niwa wrote: > That's exactly what we're doing. The latest spec uses ES6 class constructor > to define custom elements. See an example below this section in DOM spec: > htt

[Custom Elements] They are globals.

2016-04-11 Thread /#!/JoePea
? I don't really see the solution yet (if any), since the browser needs to know about the elements in order to make them work. Any thoughts? Is a more encapsulated approach possible? Regards, - Joe -- /#!/JoePea

Re: [Custom Elements] Extension of arbitrary elements at runtime.

2016-04-11 Thread /#!/JoePea
: > > > On Sun, Apr 10, 2016 at 11:11 PM, /#!/JoePea > wrote: > >> The is="" attribute lets one specify that some element is actually an >> extended version of that element. >> >> But, in order for this to work, the Custom Element definition has to >

[Custom Elements] Extension of arbitrary elements at runtime.

2016-04-10 Thread /#!/JoePea
ply adding is="" attributes as needed? Would this make things too complicated? The real reason I thought of this idea is because: https://github.com/infamous/infamous/issues/5 There might be a better way, but thought I'd mention it just in case it sparks any ideas. Cheers! - Joe /#!/JoePea

[Custom Elements] More ES6-like API

2016-04-10 Thread /#!/JoePea
It'd be nice if users could define actual constructors, as described here: https://github.com/w3c/webcomponents/issues/423#issuecomment-208131046 Cheers! - Joe /#!/JoePea