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

[Dominic Cooney]

I implemented custom elements in Chrome (twice.) This looks reasonable to
me.

The exact timing of createdCallback and constructor running, and errors
around element creation, are different. If authors stick to the
restrictions of custom elements "v1" they should be fine, because they're
more restrictive than v0.

On Sun, Aug 21, 2016 at 11:13 AM, /#!/JoePea  wrote:

> Due to the renaming of some class methods (attached/detached to
> connected/disconnected) and removal of createdCallback in favor of
> constructors (which is a good thing!), I find myself writing my
> WebComponent base class (class-factory mixin) as follows.
>
> My question is, should I be doing what I'm doing, or do you recommend
> something else? Note that the attached/detachedCallback methods simply call
> the connected/disconnectedCallback methods, and also note what I've done
> with `createdCallback` and the `constructor` due to the differences between
> v0 and v1. Subclasses of my WebComponent base class still use
> `createdCallback` rather than a constructor in order to be backwards
> compatible.
>
> The code is as follows, with parts removed for brevity in order to show
> just the parts dealing with the v0/v1 APIs directly and how backwards
> compatibility is maintained:
>
> // Very very stupid hack needed for Safari in order for us to be able
> to extend
> // the HTMLElement class. See:
> // https://github.com/google/traceur-compiler/issues/1709
> if (typeof window.HTMLElement != 'function') {
> const _HTMLElement = function HTMLElement(){}
> _HTMLElement.prototype = window.HTMLElement.prototype
> window.HTMLElement = _HTMLElement
> }
>
> // XXX: Maybe we can improve by clearing items after X amount of time?
> const classCache = new Map
>
> function hasHTMLElementPrototype(constructor) {
> if (!constructor) return false
> if (constructor === HTMLElement) return true
> else return hasHTMLElementPrototype(constructor.prototype)
> }
>

I'm not sure this is right. Would it be simpler anyway to just say
constructor && (constructor === HTMLElement || constructor.prototype
instanceof HTMLElement)?


> /**
>  * Creates a WebComponent base class dynamically, depending on which
>  * HTMLElement class you want it to extend from. Extend from
> WebComponent when
>  * making a new Custom Element class.
>  *
>  * @example
>  * import WebComponent from './WebComponent'
>  * class AwesomeButton extends WebComponent(HTMLButtonElement) { ... }
>  *
>  * @param {Function} elementClass The class that the generated
> WebComponent
>  * base class will extend from.
>  */
> export default
> function WebComponentMixin(elementClass) {
> if (!elementClass) elementClass = HTMLElement
>
> if (!hasHTMLElementPrototype(elementClass)) {
> throw new TypeError(
> 'The argument to WebComponentMixin must be a constructor
> that extends from or is HTMLElement.'
> )
> }
>
> // if a base class that extends the given `elementClass` has
> already been
> // created, return it.
> if (classCache.has(elementClass))
> return classCache.get(elementClass)
>
> // otherwise, create it.
> class WebComponent extends elementClass {
>
> // constructor() is used in v1 Custom Elements instead of
> // createdCallback() as in v0.
> constructor() {
> super()
>
> // If the following is true, then we know the user should
> be using
> // `document.registerElement()` to define an element from
> this class.
> // `document.registerElement()` creates a new constructor,
> so if the
> // constructor here is being called then that means the
> user is not
> // instantiating a DOM HTMLElement as expected because it
> is required
> // that the constructor returned from
> `document.registerElement` be used
> // instead (this is a flaw of Custom Elements v0 which is
> fixed in v1
> // where class constructors can be used directly).
> if (document.registerElement && !customElements.define) {
>
> // TODO: link to docs.
> throw new Error(`
> You cannot instantiate this class directly without
> first registering it
> with \`document.registerElement(...)\`. See an
> example at http://
> `)
>
> }
>
> // Throw an error if no Custom Elements API exists.
> if (!document.registerElement && !customElements.define) {
>
> // TODO: link to docs.
> throw new Error(`
> Your browser does not support the Custom Elements
> API. You'll
>   

Re: [custom-elements] Prefix x- for custom elements like data- attributes

[Brian Kardell]

On Mon, Apr 25, 2016 at 1:06 PM, Bang Seongbeom 
wrote:

> It would be good to restrict custom element's name to start with like
> 'x-' for the future standards. User-defined custom attributes; data
> attributes are also restricted its name to start with 'data-' so we can
> define easily new standard attribute names ('aria-*' or everything
> except for 'data-*'.)
>

You can't really reasonably further restrict future HTML though.  Relaxing
it is easier than restricting it.  I can't really really understand why
you'd want to in this case as they are dasherized.  HTML doesn't need
dasherized native elements.

In practice attributes aren't really restricted either - there is a
veritable ocean of custom attributes out there that are not data-*
prefixed.  data-* attributes do give you a potentially nicer API for
dealing with attribute-oriented properties.  Things like angular used ng-*
and, realistically, those are probably safe.  It's not likely that html
needs those in the future.   They've also done some interesting things at
looking at what is actually functionally valid - like attribute names that
are surrounded by braces or parens.  In any case, since people are well
aware that they -can- use any old attributes, it kind of doesn't matter
what the spec says when it comes to new standards.  If it would break the
web, it would break the web.

Same with custom tags really, HTML has always permitted them because that's
how it is forward parsable... But they haven't had a way to be useful.
Custom elements, make them useful, but put them in a compelling box that
allow us to add anything that isn't dasherized.  That was a long long long
way in the making, I can't honestly see it being undone in an even stricter
fashion.



-- 
Brian Kardell :: @briankardell

Re: [custom-elements] Prefix x- for custom elements like data- attributes

[Tab Atkins Jr.]

On Mon, Apr 25, 2016 at 10:06 AM, Bang Seongbeom
 wrote:
> It would be good to restrict custom element's name to start with like
> 'x-' for the future standards. User-defined custom attributes; data
> attributes are also restricted its name to start with 'data-' so we can
> define easily new standard attribute names ('aria-*' or everything
> except for 'data-*'.)

We already have a similar restriction - custom elements names must
*contain* a dash.

~TJ

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

[Justin Fagnani]

On Fri, Apr 22, 2016 at 8:24 PM, Anne van Kesteren  wrote:

> On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea  wrote:
> > I really believe that we should be allowed to name our elements with any
> > name we wish, and that they should override native elements (that is
> future
> > proof), and that overriding should be on some type of encapsulated basis
> > (for example, override within a shadow root and it won't affect other
> code
> > outside the shadow root).
>
> I don't think anyone disagrees with that in principle, but in practice
> that would require refactoring huge amounts of code which will
> basically not happen anytime soon. Better to iterate in smaller steps.
>

The implied key point here is that we can relax restrictions in the future,
but it's difficult-to-impossible to tighten restrictions.



>
> --
> https://annevankesteren.nl/
>
>

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

[Anne van Kesteren]

On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea  wrote:
> I really believe that we should be allowed to name our elements with any
> name we wish, and that they should override native elements (that is future
> proof), and that overriding should be on some type of encapsulated basis
> (for example, override within a shadow root and it won't affect other code
> outside the shadow root).

I don't think anyone disagrees with that in principle, but in practice
that would require refactoring huge amounts of code which will
basically not happen anytime soon. Better to iterate in smaller steps.


-- 
https://annevankesteren.nl/

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

[/#!/JoePea]

Thanks for the link!

​I really believe that we should be allowed to name our elements with any
name we wish, and that they should override native elements (that is future
proof), and that overriding should be on some type of encapsulated basis
(for example, override within a shadow root and it won't affect other code
outside the shadow root).​


On Thursday, April 14, 2016, Takayoshi Kochi  wrote:

> Just FYI, the idea of allowing non-hyphen elements if they contain
> non-ASCII characters
> which probably won't collide with future HTML elements was posted in the
> 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 provides; two
>> > independent libraries can't ever depend on the core HTML elements,
>> > because the other library might have overridden some of them.
>>
>> Based on my idea of registering elements on a per-shadow-root basis
>> (
>> https://discourse.wicg.io/t/proposal-register-custom-elements-onto-shadowdom-roots/1440
>> ),
>> then libraries could use any native or custom elements that they want
>> within their shadow roots. Shadow roots would provide encapsulation,
>> and element registrations would be scoped to those shadow roots.
>>
>> There are two possible ways to deal with element registrations on the
>> `document`:
>>
>> 1. Either elements registered on the `document` have effect across
>> shadow roots, but shadow roots can override these registrations:
>>
>> ```js
>> document.registerElement('foo-bar', SomeClass)
>> // ...
>> shadowRoot.registerElement('foo-bar', OtherClass) // takes precedence
>> over the document registration.
>> ```
>>
>> 2. Or, document registrations simply wouldn't cross the shadow root
>> boundary.
>>
>> I personally like the second option, leaving maximum control in the
>> hands of the developer, regardless of some global script registering
>> an element on the document that may encroach the scope of a shadow
>> root. If a shadow root author really wants the same element, there's
>> slightly more effort to also register that element with the shadow
>> root, but the overall control outweighs this extra effort in my
>> opinion.
>>
>> Then, if we add the ability to override native elements, we'll have
>> something powerful, IMO.
>>
>> ```js
>> // file1.js
>> import BetterImageWithWebGLFilters from 'better-img'
>> document.registerElement('img', BetterImageWithWebGLFilters)
>>
>> // file2.js
>> let s = el.createShadowRoot()
>> s.appendChild(document.createElement('img')) // uses native
>> HTMLImageElement because document registration stops at shadow root
>> boundary.
>>
>> // file3.js
>> import BetterImageWithWebGLFilters from 'better-img'
>> let s = el.createShadowRoot()
>> s.registerElement('img', BetterImageWithWebGLFilters)
>> s.appendChild(document.createElement('img')) // this person wants
>> BetterImageWithWebGLFilters in their shadow root
>>
>> // file4.js
>> let s = el.createShadowRoot()
>> s.registerElement('div', AwesomeClass) // this does not affect other
>> shadow 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
>>
>>
>
>
> --
> Takayoshi Kochi
>

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

[Takayoshi Kochi]

Just FYI, the idea of allowing non-hyphen elements if they contain
non-ASCII characters
which probably won't collide with future HTML elements was posted in the
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 provides; two
> > independent libraries can't ever depend on the core HTML elements,
> > because the other library might have overridden some of them.
>
> Based on my idea of registering elements on a per-shadow-root basis
> (
> https://discourse.wicg.io/t/proposal-register-custom-elements-onto-shadowdom-roots/1440
> ),
> then libraries could use any native or custom elements that they want
> within their shadow roots. Shadow roots would provide encapsulation,
> and element registrations would be scoped to those shadow roots.
>
> There are two possible ways to deal with element registrations on the
> `document`:
>
> 1. Either elements registered on the `document` have effect across
> shadow roots, but shadow roots can override these registrations:
>
> ```js
> document.registerElement('foo-bar', SomeClass)
> // ...
> shadowRoot.registerElement('foo-bar', OtherClass) // takes precedence
> over the document registration.
> ```
>
> 2. Or, document registrations simply wouldn't cross the shadow root
> boundary.
>
> I personally like the second option, leaving maximum control in the
> hands of the developer, regardless of some global script registering
> an element on the document that may encroach the scope of a shadow
> root. If a shadow root author really wants the same element, there's
> slightly more effort to also register that element with the shadow
> root, but the overall control outweighs this extra effort in my
> opinion.
>
> Then, if we add the ability to override native elements, we'll have
> something powerful, IMO.
>
> ```js
> // file1.js
> import BetterImageWithWebGLFilters from 'better-img'
> document.registerElement('img', BetterImageWithWebGLFilters)
>
> // file2.js
> let s = el.createShadowRoot()
> s.appendChild(document.createElement('img')) // uses native
> HTMLImageElement because document registration stops at shadow root
> boundary.
>
> // file3.js
> import BetterImageWithWebGLFilters from 'better-img'
> let s = el.createShadowRoot()
> s.registerElement('img', BetterImageWithWebGLFilters)
> s.appendChild(document.createElement('img')) // this person wants
> BetterImageWithWebGLFilters in their shadow root
>
> // file4.js
> let s = el.createShadowRoot()
> s.registerElement('div', AwesomeClass) // this does not affect other
> shadow 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
>
>


-- 
Takayoshi Kochi

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

[/#!/JoePea]

On Wed, Apr 13, 2016 at 1:09 PM, Tab Atkins Jr.  wrote:
> That means we lose the lingua franca that HTML provides; two
> independent libraries can't ever depend on the core HTML elements,
> because the other library might have overridden some of them.

Based on my idea of registering elements on a per-shadow-root basis
(https://discourse.wicg.io/t/proposal-register-custom-elements-onto-shadowdom-roots/1440),
then libraries could use any native or custom elements that they want
within their shadow roots. Shadow roots would provide encapsulation,
and element registrations would be scoped to those shadow roots.

There are two possible ways to deal with element registrations on the
`document`:

1. Either elements registered on the `document` have effect across
shadow roots, but shadow roots can override these registrations:

```js
document.registerElement('foo-bar', SomeClass)
// ...
shadowRoot.registerElement('foo-bar', OtherClass) // takes precedence
over the document registration.
```

2. Or, document registrations simply wouldn't cross the shadow root boundary.

I personally like the second option, leaving maximum control in the
hands of the developer, regardless of some global script registering
an element on the document that may encroach the scope of a shadow
root. If a shadow root author really wants the same element, there's
slightly more effort to also register that element with the shadow
root, but the overall control outweighs this extra effort in my
opinion.

Then, if we add the ability to override native elements, we'll have
something powerful, IMO.

```js
// file1.js
import BetterImageWithWebGLFilters from 'better-img'
document.registerElement('img', BetterImageWithWebGLFilters)

// file2.js
let s = el.createShadowRoot()
s.appendChild(document.createElement('img')) // uses native
HTMLImageElement because document registration stops at shadow root
boundary.

// file3.js
import BetterImageWithWebGLFilters from 'better-img'
let s = el.createShadowRoot()
s.registerElement('img', BetterImageWithWebGLFilters)
s.appendChild(document.createElement('img')) // this person wants
BetterImageWithWebGLFilters in their shadow root

// file4.js
let s = el.createShadowRoot()
s.registerElement('div', AwesomeClass) // this does not affect other
shadow 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.

[Tab Atkins Jr.]

On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea  wrote:
> What if custom Elements simply override existing ones then?
>
> ```js
> shadowRoot.registerElement('div', MyElement)
> ```

That means we lose the lingua franca that HTML provides; two
independent libraries can't ever depend on the core HTML elements,
because the other library might have overridden some of them.

Having a well-known common API is worthwhile.  (JS technically has
this problem, but replacing built-ins, when it's done, is typically
just to *expand* them.  And once modules finally ship, we'll have a
built-in module with pristine versions of all the built-ins, too.)

> If overriding native elements was documented, it'd be fine. By
> default, a blank document or shadow root has no elements registered,
> so  would use the native DIV. But, why not let the user define
> what a  is? There could optionally be a warning outputted to
> console:
>
> ```
> Warning: DIV was overridden: /path/to/some/file.js:123:4
> ```

This means every website that overrides any built-in element will have
never-ending console spam, which isn't great.

~TJ

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

[/#!/JoePea]

What if custom Elements simply override existing ones then?

```js
shadowRoot.registerElement('div', MyElement)
```

If overriding native elements was documented, it'd be fine. By
default, a blank document or shadow root has no elements registered,
so  would use the native DIV. But, why not let the user define
what a  is? There could optionally be a warning outputted to
console:

```
Warning: DIV was overridden: /path/to/some/file.js:123:4
```

^ shows where is happens so an end user can easily find and remove the
culprit if that is ever a problem. In JavaScript, we can override many
of the things on the global `window` object. It's the developer's job
to add (or remove) scripts that modify their `window` properties. Why
not give the same level of flexibility with DOM elements? ,
, etc, can just be treated as global variables, overridable.  I
don't think that would do too much harm.

Being able to override on a shadow-root basic could encapsulate the
cases where such overriding is needed.

Being able to override native elements would make some interesting use
cases possible too, like providing alternate functionality to
commonly-used elements without having to touch existing markup of an
existing app. For example, AMP's  element could just be
.

TLDR: browsers would still be able to add new native elements, while
users would be able to override them. Why not? Allowing this won't
break the web (since nothing is currently overridden to begin with).
Let's make both browser makers and web app authors live's better as
much as possible at the same time. Being able to override elements
would be such a compromise: browser developers can add new default
elements, while web app authors can choose to use them or not, or to
override 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 added to spec without worry of name conflicts with existing custom
> elements on the page. It's much more future proof, in my opinion.
>
> On Wed, Apr 13, 2016 at 1:12 PM, /#!/JoePea  wrote:
>>
>> I personally don't like this limitation. I think Custom Elements would
>> be better if we could create elements that have   
>>  , with the possible exception that we can't override the
>> native elements.
>>
>> Based on my previous email about registering elements on shadow roots,
>> I think being able to choose any name would make things just cleaner:
>>
>> ```js
>> //  --- SomeElement.js
>> import MyElement from './MyElement'
>>
>> export default
>> class SomeElement extends HTMLElement {
>> constructor() {
>> this.root = this.createShadowRoot()
>> this.root.registerElement('MyElement', MyElement) //
>>  or 
>>
>> const frag = document.createDocumentFragment()
>> frag.innerHTML = `
>> 
>>   
>>   ...
>>   
>> 
>> `
>> this.root.appendChild(frag)
>> }
>>
>> static get observedAttributes() { return [ ... ] }
>> connectedCallback() { ... }
>> disconnectedCallback() { ... }
>> attributeChangedCallback() { ... }
>> }
>>
>> //  --- app.js
>> import SomeElement from './SomeElement'
>>
>> // elements registered on the document won't cross into shadow roots
>> document.registerElement('SomeElement', SomeElement)
>> document.body.appendChild(document.createElement('someelement'))
>> ```
>>
>> /#!/JoePea
>>
>

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

[Nick Dugger]

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 added to spec without worry of name conflicts with existing
custom elements on the page. It's much more future proof, in my opinion.

On Wed, Apr 13, 2016 at 1:12 PM, /#!/JoePea  wrote:

> I personally don't like this limitation. I think Custom Elements would
> be better if we could create elements that have   
>  , with the possible exception that we can't override the
> native elements.
>
> Based on my previous email about registering elements on shadow roots,
> I think being able to choose any name would make things just cleaner:
>
> ```js
> //  --- SomeElement.js
> import MyElement from './MyElement'
>
> export default
> class SomeElement extends HTMLElement {
> constructor() {
> this.root = this.createShadowRoot()
> this.root.registerElement('MyElement', MyElement) //
>  or 
>
> const frag = document.createDocumentFragment()
> frag.innerHTML = `
> 
>   
>   ...
>   
> 
> `
> this.root.appendChild(frag)
> }
>
> static get observedAttributes() { return [ ... ] }
> connectedCallback() { ... }
> disconnectedCallback() { ... }
> attributeChangedCallback() { ... }
> }
>
> //  --- app.js
> import SomeElement from './SomeElement'
>
> // elements registered on the document won't cross into shadow roots
> document.registerElement('SomeElement', SomeElement)
> document.body.appendChild(document.createElement('someelement'))
> ```
>
> /#!/JoePea
>
>

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

[Tab Atkins Jr.]

On Wed, Apr 13, 2016 at 11:12 AM, /#!/JoePea  wrote:
> I personally don't like this limitation. I think Custom Elements would
> be better if we could create elements that have   
>  , with the possible exception that we can't override the
> native elements.

This would prevent us from ever adding any new elements to the
language, or at least require us to do real-world usage checks and
avoid names that would break too many pages if we took it over.
Requiring a dash is a minimal cost to element authors, and permanently
avoids any clashes.

This is similar to CSS requiring custom properties to start with a
double-dash, like --foo.

~TJ

Re: [Custom Elements] They are globals.

[/#!/JoePea]

On Mon, Apr 11, 2016 at 4:44 PM, Ryosuke Niwa  wrote:
> You'd have to instead write it as "new SomeClass(this.shadowRoot)" and then 
> (1) needs to be modified as: `super(..arguments)` to pass the argument along 
> to the HTMLElement constructor.

For sure, similar to the examples in the GitHub issue. :]

React doesn't encourage the instantiation of element classes directly.
What if browsers did that too and threw errors whenever someone tried
to instantiate a class using `new` that extended from any of the
native classes:

```js
import {SomeElement} from 'some-library'

// this would cause a `TypeError: Illegal constructor` or something
let el = new SomeElement()

// does not return a constructor
shadowRoot1.registerElement('any-name', SomeElement)

// only this instantiation method is allowed
let el1 = shadowRoot1.createElement('any-name')

// we can use the same class in a different component where
//  is already defined but isn't backed by SomeElement
shadowRoot2.registerElement('other-name', SomeElement)
let el2 = shadowRoot2.createElement('other-name')

// maybe this should throw an error instead of returning
// HTMLUnknownElement, otherwise it might hide the obvious
// human error instead teaching the developer
shadowRoot1.registerElement('a-name', SomeElement)
let el3 = shadowRoot2.createElement('a-name')

// this would cause an error because el1 was created from
// shadowRoot1 so el1 doesn't work in shadowRoot2
shadowRoot2.appendChild(el1)
```

ShadowDOM is still evolving and the Web Component spec hasn't
officially settled, so I think there's a good opportunity here for the
web to be more helpful by throwing errors and not being ambiguous as
for example in `document.createElement('ths-has-a-typo')`.

TLDR - ShadowDOM could be the encapsulation of HTML to Custom Elements
as JSX is the encapsulation of HTML to React Components (in a morphed
way, as obviously the mechanics are different).

Here's what a small component might look like:

```js
//  --- HandyForm.js
import AwesomeButton from './AwesomeButton'
import { FancyForm, FancyInput } from './FancyForm'

export default
class HandyForm extends HTMLElement {
constructor() {
this.root = this.createShadowRoot()
this.root.registerElement('', AwesomeButton)
this.root.registerElement('', FancyForm)
this.root.registerElement('', FancyInput)

const frag = document.createDocumentFragment()
frag.innerHTML = `


 



`
this.root.appendChild(frag)
}

static get observedAttributes() { return [ ... ] }

connectedCallback() { ... }
disconnectedCallback() { ... }
attributeChangedCallback() { ... }
}

//  --- app.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.

[Ryosuke Niwa]

> On Apr 11, 2016, at 2:29 PM, /#!/JoePea  wrote:
> 
> What if custom elements can be registered on a shadow-root basis, so
> that the author of a Custom Element (one that isn't registered by
> default) can register a bunch of elements that it's shadow root will
> use, passing constructors that the author code may have imported from
> anywhere. Then that same author simply exports the custom element
> (does not register it) for a following author to use. The following
> author would import that custom element, then register it with the
> shadow roots of his/her new custom elements, and thus the cycle
> continues, with registered elements defined on shadow roots on a
> per-custom-element basis, without those elements ever being registered
> to some global registry.
> 
> ```
> // library code
> import SomeClass from './somewhere'
> 
> export default
> class AuthorElement extends HTMLElement {
>constructor() {
>this.shadowRoot.defineElement(
>'authors-should-call-this-anything-they-want',
>SomeClass
>)
>// ...
>}
> }
> ```

Now, let's say you do "new SomeClass" now, and SomeClass is defined as follows:

```js
class SomeClass extends HTMLElement {
constructor()
{
super(); // (1)
}
}
```

When HTMLElement's constructor is involved in (1), it needs to construct an 
element by the name of "authors-should-call-this-anything-they-want".  However, 
it has no idea to which shadow root or document it belongs.  The fundamental 
here is that any construction of new element now needs to specify the shadow 
root or document for which it is created so simple "new SomeClass" would not 
work.  You'd have to instead write it as "new SomeClass(this.shadowRoot)" and 
then (1) needs to be modified as: `super(..arguments)` to pass the argument 
along to the HTMLElement constructor.

- R. Niwa

Re: [Custom Elements] They are globals.

[/#!/JoePea]

I get what you mean about the behaviors defined from classes that
exist in the scope, in React. The really great thing about React is
the ability to compose a class by using multiple classes to return the
render spec. One of React's strong-points at a high level is it offers
encapsulation where the components used in the HTML (which don't map
directly to the actual DOM result that the browser is finally given)
are specific to the component, encapsulated there.

The current methods of encapsulation that I see with normal HTML are
documents and shadow roots, where shadow roots seem to be closer to
React than documents because the top-level HTML that we inspect in the
DOM may not be what is actually rendered (like with React), although
the implementation is completely different, but at a high level shadow
dom has that small similarity with React.

So, to make code-reuse as possible as it is with React (due to React's
aforementioned encapsulation and use of the JavaScript scopefor it's
"HTML elements"), maybe the Custom Element API can take advantage of
ShadowDOM instead of documents?

What if custom elements can be registered on a shadow-root basis, so
that the author of a Custom Element (one that isn't registered by
default) can register a bunch of elements that it's shadow root will
use, passing constructors that the author code may have imported from
anywhere. Then that same author simply exports the custom element
(does not register it) for a following author to use. The following
author would import that custom element, then register it with the
shadow roots of his/her new custom elements, and thus the cycle
continues, with registered elements defined on shadow roots on a
per-custom-element basis, without those elements ever being registered
to some global registry.

```
// library code
import SomeClass from './somewhere'

export default
class AuthorElement extends HTMLElement {
constructor() {
this.shadowRoot.defineElement(
'authors-should-call-this-anything-they-want',
SomeClass
)
// ...
}
}
```

Then, finally, the top-level app author can register the top-most
custom elements using an API similar to current, in the top-level
namespace (global scope) for the window or document.

```
// app code
import AuthorElement from './AuthorElement'
document.defineElement(
'any-name-the-app-author-wants',
SomeClass
)
```

So, basically, inaddition to global/window-or-document-based elements
there'd also be shadow root definitions for encapsulation, since
shadow roots are to custom elements as what (slightly stretched) JSX
specs are to React components.

An important part of the Custom Element API would be that Custom
Element authors should never register their Custom Elements globally,
only export them for the user of their custom element to register
them. The final top-level app author would register only the elements
that will be used in the top-level HTML of the app, all other elements
already registered in their shadow roots by the authors of each
element.

Something like this would create a development environment much more
similar to React, having encapsulation and making code more re-usable.
The only downside of this approach would be the need to manually
register elements per-shadow-root, not just importing them (in react,
importing is enough, as the JSX uses the JavaScript scope as the
element registry).

On a side note, interestingly, template string tag functions would let
us take advantage 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:25 AM, Domenic Denicola  wrote:
> I think you are being misled by a superficial similarity with React's JSX.
>
> JSX's `` desugars to `React.createElement(Foo)`, which creates a `` 
> element with some of its behavior derived from the `Foo` class, found in 
> JavaScript lexical scope. The `Foo` token has no impact on the DOM tree.
>
> Custom elements' `` is completely unlike that. In that case, `x-foo` 
> is a tag name, and a full participant in the DOM tree structure. It affects 
> CSS selector matching, APIs like querySelector and getElementsByTagName, and 
> more. It's not just a div.
>
> As Ryosuke notes, it's very hard to imagine how "scoped tag names" would 
> work. Both for implementation reasons, like the HTMLElement constructor, but 
> also for cases like CSS or the DOM APIs, which operate fundamentally on a 
> global mapping.
>

Re: [Custom Elements] More ES6-like API

[/#!/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: 
> https://dom.spec.whatwg.org/#concept-element-custom-element-state
>
> - R. Niwa
>
>> On Apr 10, 2016, at 7:58 PM, /#!/JoePea  wrote:
>>
>> 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
>>

RE: [Custom Elements] They are globals.

[Domenic Denicola]

I think you are being misled by a superficial similarity with React's JSX.

JSX's `` desugars to `React.createElement(Foo)`, which creates a `` 
element with some of its behavior derived from the `Foo` class, found in 
JavaScript lexical scope. The `Foo` token has no impact on the DOM tree.

Custom elements' `` is completely unlike that. In that case, `x-foo` is 
a tag name, and a full participant in the DOM tree structure. It affects CSS 
selector matching, APIs like querySelector and getElementsByTagName, and more. 
It's not just a div.

As Ryosuke notes, it's very hard to imagine how "scoped tag names" would work. 
Both for implementation reasons, like the HTMLElement constructor, but also for 
cases like CSS or the DOM APIs, which operate fundamentally on a global mapping.

Re: [Custom Elements] They are globals.

[Ryosuke Niwa]

> On Apr 11, 2016, at 9:02 AM, /#!/JoePea  wrote:
> 
> Is it possible to take an approach more similar to React where Custom 
> Elements aren't registered in a global pool? What if two libraries we'd like 
> to use define elements of the same name, and we wish to import these via 
> `import` and not modify the source code of our dependencies?
> 
> 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?

We discussed a similar issue related to having multiple documents per global 
object: https://github.com/w3c/webcomponents/issues/369 


The problem here is that HTMLElement constructor, which is involved as a super 
call in a custom element constructor, cannot determine which set of custom 
elements to use because it doesn't get any contextual information about where 
the element is constructed.

- R. Niwa

Re: [Custom Elements] More ES6-like API

[Ryosuke Niwa]

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: 
https://dom.spec.whatwg.org/#concept-element-custom-element-state

- R. Niwa

> On Apr 10, 2016, at 7:58 PM, /#!/JoePea  wrote:
> 
> 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
> 

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

[/#!/JoePea]

Hello Brian

The purpose of the motor-scene and motor-node elements is that they will be
easy to apply 3D transforms to (and WebGL soon), with easing for example. I
suppose a better approach for augmenting and existing DOM could be to
simply apply the transforms via selectors instead of trying to apply the
behavior via extending with is="". This wouldn't allow custom attributes
though, like extending would.

I think the best solution, for now, is as you recommended: to add the
layers if possible.

Thanks for the input!
- Joe

On Monday, April 11, 2016, Brian Kardell  wrote:

>
>
> 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
>> deliberately extend that same basic element type or else it won't
>> work.
>>
>> It'd be nice if a Custom Element definition could be arbitrarily
>> applied to any type of element, with the is="" tag for example, and
>> that the element would then be upgraded to the extending type at
>> runtime. The custom element could be told what class it is extending
>> at runtime in order to perhaps act differently using conditional
>> statements.
>>
>> So, writing defining the element could be like this:
>>
>> ```js
>> let isDynamic = true
>> document.registerElement('some-element', {
>>   createdCallback: function() {
>> if (this.typeExtended == 'DIV")
>>   // ...
>> if (this.typeExtended == 'BUTTON')
>>   // ...
>>   },
>> }, isDynamic)
>> ```
>>
>> then using the element could be like this:
>>
>> ```html
>> 
>> 
>> 
>> ```
>>
>> What are your thoughts on such a way to extend any type of element at
>> runtime? Could it be a way for augmenting, for example, an existing
>> app without necessarily having to modify it's markup, just simply
>> 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
>>
>>
>
> Is there a reason that you cannot wrap with fallback?  For example, in
> your github issue you are given and existing app with markup like:
>
> 
>   
> Hello
>   
>
>
> and the issue wanted to change it to
>
> 
>   
> Hello
>   
>
>
> Is there a reason it could it not just be
>
> 
>   
>   
> Hello
> 
> 
>
>
> There isn't really a significant difference between div and motor-scene to
> non-supporting browsers.
>
>
> --
> Brian Kardell :: @briankardell
>


-- 
/#!/JoePea

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

[Brian Kardell]

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
> deliberately extend that same basic element type or else it won't
> work.
>
> It'd be nice if a Custom Element definition could be arbitrarily
> applied to any type of element, with the is="" tag for example, and
> that the element would then be upgraded to the extending type at
> runtime. The custom element could be told what class it is extending
> at runtime in order to perhaps act differently using conditional
> statements.
>
> So, writing defining the element could be like this:
>
> ```js
> let isDynamic = true
> document.registerElement('some-element', {
>   createdCallback: function() {
> if (this.typeExtended == 'DIV")
>   // ...
> if (this.typeExtended == 'BUTTON')
>   // ...
>   },
> }, isDynamic)
> ```
>
> then using the element could be like this:
>
> ```html
> 
> 
> 
> ```
>
> What are your thoughts on such a way to extend any type of element at
> runtime? Could it be a way for augmenting, for example, an existing
> app without necessarily having to modify it's markup, just simply
> 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
>
>

Is there a reason that you cannot wrap with fallback?  For example, in your
github issue you are given and existing app with markup like:


  
Hello
  


and the issue wanted to change it to


  
Hello
  


Is there a reason it could it not just be


  
  
Hello




There isn't really a significant difference between div and motor-scene to
non-supporting browsers.


-- 
Brian Kardell :: @briankardell

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Ryosuke Niwa]

> On Feb 26, 2016, at 3:36 PM, Elliott Sprehn  wrote:
> 
> 
> 
> On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa  wrote:
>> 
>> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn  wrote:
>> >
>> >
>> >
>> > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa  wrote:
>> >>
>> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn  
>> >> > wrote:
>> >> >
>> >> > Can you give a code example of how this happens?
>> >>
>> >> For example, execCommand('Delete') would result in sequentially deleting 
>> >> nodes as needed.
>> >> During this compound operation, unload events may fire on iframes that 
>> >> got deleted by this operation.
>> >>
>> >> I would like components to be notified that they got removed/disconnected 
>> >> from the document
>> >> before such an event is getting fired.
>> >>
>> >
>> > I'd rather not do that, all the sync script inside editing operations is a 
>> > bug, and you shouldn't depend on the state of the world around you in 
>> > there anyway since all browsers disagree (ex. not all of them fire the 
>> > event sync).
>> 
>> I don't think that's a bug given Safari, Chrome, and Gecko all fires unload 
>> event before finishing the delete operation.  It's an interoperable 
>> behavior, which should be spec'ed.
> 
> Firefox's behavior of when to fire unload definitely doesn't match Chrome or 
> Safari, but maybe it does in this one instance. I don't think it's worth 
> trying to get consistency there though, unload is largely a bug, we should 
> add a new event and get people to stop using it.

I strongly disagree with the assessment and oppose to adding a new event.

>> Anyway, this was just an easy example I could come up with.  There are many 
>> other examples that involve DOM mutation events if you'd prefer seeing those 
>> instead.
> 
> I'm not interested in making using mutation events easier.

And I'm not interested in pushing your agenda to deprecate mutation events 
either.

>> The fact of matter is that we don't live in the future, and it's better for 
>> API to be consistent in this imperfect world than for it to have weird edge 
>> cases.  As a matter of fact, if you end up being able to kill those sync 
>> events in the future, this will become non-issue since end-of-nano-task as 
>> you (Google) proposed will happen before dispatching of any event.
>> 
>> As things stand, however, we should dispatch lifecycle callbacks before 
>> dispatching these (legacy but compat mandating) events.
> 
> I disagree. Mutation events are poorly speced and not interoperably 
> implemented across browsers. I don't think we should run nanotasks down there.

It doesn't matter how poorly things are spec'ed.  The reality is that unload 
events and DOM mutation events are required for Web compatibility, and as such, 
should be considered when designing new API.

Anyhow, I'm going to invoke lifecycle callbacks before dispatching events in 
WebKit for now since we can't seem to come to consensus on this matter.

- R. Niwa

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Elliott Sprehn]

On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa  wrote:

>
> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn 
> wrote:
> >
> >
> >
> > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa  wrote:
> >>
> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn 
> wrote:
> >> >
> >> > Can you give a code example of how this happens?
> >>
> >> For example, execCommand('Delete') would result in sequentially
> deleting nodes as needed.
> >> During this compound operation, unload events may fire on iframes that
> got deleted by this operation.
> >>
> >> I would like components to be notified that they got
> removed/disconnected from the document
> >> before such an event is getting fired.
> >>
> >
> > I'd rather not do that, all the sync script inside editing operations is
> a bug, and you shouldn't depend on the state of the world around you in
> there anyway since all browsers disagree (ex. not all of them fire the
> event sync).
>
> I don't think that's a bug given Safari, Chrome, and Gecko all fires
> unload event before finishing the delete operation.  It's an interoperable
> behavior, which should be spec'ed.
>

Firefox's behavior of when to fire unload definitely doesn't match Chrome
or Safari, but maybe it does in this one instance. I don't think it's worth
trying to get consistency there though, unload is largely a bug, we should
add a new event and get people to stop using it.


>
> Anyway, this was just an easy example I could come up with.  There are
> many other examples that involve DOM mutation events if you'd prefer seeing
> those instead.
>

I'm not interested in making using mutation events easier.


>
> The fact of matter is that we don't live in the future, and it's better
> for API to be consistent in this imperfect world than for it to have weird
> edge cases.  As a matter of fact, if you end up being able to kill those
> sync events in the future, this will become non-issue since
> end-of-nano-task as you (Google) proposed will happen before dispatching of
> any event.
>
> As things stand, however, we should dispatch lifecycle callbacks before
> dispatching these (legacy but compat mandating) events.
>

I disagree. Mutation events are poorly speced and not interoperably
implemented across browsers. I don't think we should run nanotasks down
there.

- E

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Ryosuke Niwa]

> On Feb 26, 2016, at 3:22 PM, Elliott Sprehn  wrote:
> 
> 
> 
> On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa  wrote:
>> 
>> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn  wrote:
>> >
>> > Can you give a code example of how this happens?
>> 
>> For example, execCommand('Delete') would result in sequentially deleting 
>> nodes as needed.
>> During this compound operation, unload events may fire on iframes that got 
>> deleted by this operation.
>> 
>> I would like components to be notified that they got removed/disconnected 
>> from the document
>> before such an event is getting fired.
>> 
> 
> I'd rather not do that, all the sync script inside editing operations is a 
> bug, and you shouldn't depend on the state of the world around you in there 
> anyway since all browsers disagree (ex. not all of them fire the event sync).

I don't think that's a bug given Safari, Chrome, and Gecko all fires unload 
event before finishing the delete operation.  It's an interoperable behavior, 
which should be spec'ed.

Anyway, this was just an easy example I could come up with.  There are many 
other examples that involve DOM mutation events if you'd prefer seeing those 
instead.

The fact of matter is that we don't live in the future, and it's better for API 
to be consistent in this imperfect world than for it to have weird edge cases.  
As a matter of fact, if you end up being able to kill those sync events in the 
future, this will become non-issue since end-of-nano-task as you (Google) 
proposed will happen before dispatching of any event.

As things stand, however, we should dispatch lifecycle callbacks before 
dispatching these (legacy but compat mandating) events.

- R. Niwa

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Elliott Sprehn]

On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa  wrote:

>
> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn 
> wrote:
> >
> > Can you give a code example of how this happens?
>
> For example, execCommand('Delete') would result in sequentially deleting
> nodes as needed.
> During this compound operation, unload events may fire on iframes that got
> deleted by this operation.
>
> I would like components to be notified that they got removed/disconnected
> from the document
> before such an event is getting fired.
>
>
I'd rather not do that, all the sync script inside editing operations is a
bug, and you shouldn't depend on the state of the world around you in there
anyway since all browsers disagree (ex. not all of them fire the event
sync).

- E

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Ryosuke Niwa]

> On Feb 24, 2016, at 9:06 PM, Elliott Sprehn  wrote:
> 
> Can you give a code example of how this happens?

For example, execCommand('Delete') would result in sequentially deleting nodes 
as needed.
During this compound operation, unload events may fire on iframes that got 
deleted by this operation.

I would like components to be notified that they got removed/disconnected from 
the document
before such an event is getting fired.

```html


ElementWithInDocumentFlag extends HTMLElement {
  constructor(...args) {
 super(...args);
 this.inDocument = false;
  }

  connectedWithDocument() {
 this.inDocument = true;
  }

  disconnectedWithDocument() {
 this.inDocument = false;
  }
}

document.defineElement('hello-world', ElementWithInDocumentFlag);



  
  
  sucks



var helloWorld = document.querySelector('hello-world');
var container = document.getElementById('editor');

setTimeout(function () {
  document.querySelector('iframe').contentWindow.onunload = function () {
console.log(container.innerHTML); // This does not contain hello-world
console.assert(!helloWorld.inDocument); // This should be false!
  }
  container.focus();
  getSelection().selectAllChildren(container);
  setTimeout(function () {
document.execCommand('Delete');
  }, 500);
}, 500);


```

- R. Niwa

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Elliott Sprehn]

Can you give a code example of how this happens?
On Feb 24, 2016 8:30 PM, "Ryosuke Niwa"  wrote:

>
> > On Feb 23, 2016, at 1:16 AM, Anne van Kesteren  wrote:
> >
> > On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa  wrote:
> >> Hi,
> >>
> >> We propose to change the lifecycle callback to be fired both before
> invoking author scripts (e.g. for dispatching events) and before returning
> to author scripts.
> >>
> >> Without this change, event listeners that call custom elements' methods
> would end up seeing inconsistent states during compound DOM operation such
> as Range.extractContents and editing operations, and we would like to avoid
> that as much as possible.
> >
> > These are the events we wanted to try and delay to dispatch around the
> > same time lifecycle callbacks are supposed to be called?
>
> Yeah, I'm talking about focus, unload, etc... and DOM mutation events.
> It's possible that we can make all those event async in the future but
> that's not the current state of the world, and we would like to keep the
> custom elements' states consistent for authors.
>
> - R. Niwa
>
>
>

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Ryosuke Niwa]

> On Feb 23, 2016, at 1:16 AM, Anne van Kesteren  wrote:
> 
> On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa  wrote:
>> Hi,
>> 
>> We propose to change the lifecycle callback to be fired both before invoking 
>> author scripts (e.g. for dispatching events) and before returning to author 
>> scripts.
>> 
>> Without this change, event listeners that call custom elements' methods 
>> would end up seeing inconsistent states during compound DOM operation such 
>> as Range.extractContents and editing operations, and we would like to avoid 
>> that as much as possible.
> 
> These are the events we wanted to try and delay to dispatch around the
> same time lifecycle callbacks are supposed to be called?

Yeah, I'm talking about focus, unload, etc... and DOM mutation events.  It's 
possible that we can make all those event async in the future but that's not 
the current state of the world, and we would like to keep the custom elements' 
states consistent for authors.

- R. Niwa

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Anne van Kesteren]

On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa  wrote:
> Hi,
>
> We propose to change the lifecycle callback to be fired both before invoking 
> author scripts (e.g. for dispatching events) and before returning to author 
> scripts.
>
> Without this change, event listeners that call custom elements' methods would 
> end up seeing inconsistent states during compound DOM operation such as 
> Range.extractContents and editing operations, and we would like to avoid that 
> as much as possible.

These are the events we wanted to try and delay to dispatch around the
same time lifecycle callbacks are supposed to be called?


-- 
https://annevankesteren.nl/

Re: [custom-elements] Steps inside HTMLElement's constructor

[Ryosuke Niwa]

> On Feb 22, 2016, at 10:46 PM, Ryosuke Niwa  wrote:
> 
> Here are steps to construct a custom element as agreed during Jan F2F as I 
> promised to write down [1] [2]:

There's a very appealing alternative to this, which doesn't involve having a 
element construction stack per definition.

We add an extra argument, let us call it exoticNewTarget, to [[Construct]] 
internal method [7], which is initially Null.  More precisely, [[Construct]] 
now takes arguments (a List of any, Object, Object) where the third argument is 
a newly created exotic object.

Add a new environmental records field, [[ExoticNewTarget]], which is either an 
Object or undefined. If this Environment Record was created by the 
[[Construct]] internal method, [[ExoticNewTarget]] is the value of the 
[[ExoticNewTarget]] exoticNewTarget parameter. Otherwise, its value is 
undefined.

Add a new abstract operation GetExoticNewTarget(), which performs the following 
steps:
1. Let envRec be GetThisEnvironment().
2. Assert: envRec has a [[ExoticNewTarget]] field.
3. Return envRec.[[ExoticNewTarget]].

We also modify step 7 of runtime semantics of SuperCall from:
7. Let result be Construct(func, argList, newTarget).
to
7. Let result be Construct(func, argList, newTarget, GetExoticNewTarget()).

With these simple changes, we can simplify the algorithm as follows and it 
would ALWYAS construct the right element:


== Custom Element Construction Algorithm ==

Input
 NAME, the custom element name.
 DOCUMENT, the owner document for new custom element.
 EXOTIC-TARGET, the target Element to be constructed / upgraded.
OUTPUT
 ELEMENT, new custom element instance.
 ERROR, could be either "None", "NotFound", "InvalidStateError", or an 
ECMAScript exception.

1. Let ERROR be "None".
2. Let REGISTRY be the (custom element) registry of DOCUMENT.
3. If DOCUMENT is an HTML document, let NAME be converted to ASCII lowercase.
4. Let DEFINITION be the element definition of with the local name, NAME, in 
REGISTRY.
5. If there is no matching definition, set ERROR to "NotFound" and terminate 
these steps.
7. Invoke the [[Construct]] internal method [3] on the custom element 
interface, INTERFACE, of DEFINITION
   with (INTERFACE, an empty list, INTERFACE, EXOTIC-TARGET)
9. If the [[Construct]] invocation resulted in an exception, set ERROR to the 
raised exception, and terminate these steps.
10. Otherwise, let ELEMENT be the result of the invocation.
11. If ELEMENT is not an instance of INTERFACE with local name, NAME, set ERROR 
to "InvalidStateError", and terminate these steps.


== HTMLElement constructor ==

1. Let TARGET be GetNewTarget(). [4]
2. Let EXOTIC-TARGET be GetExoticNewTarget().
3. If EXOTIC-TARGET is not undefined, return EXOTIC-TARGET and terminate these 
steps.
4. Let DOCUMENT be the associated document of the global object (the result of 
GetGlobalObject() [5]).
5. Let REGISTRY be the (custom element) registry of DOCUMENT.
6. Let DEFINITION be the element definition with the element interface, TARGET, 
in REGISTRY.
7. If there is no matching definition, throw TypeError and terminate these 
steps.
8. Let NAME be the local name of DEFINITION.
9. Return a new element that implements HTMLElement, with no attributes, 
namespace set to the HTML namespace,
   local name set to NAME, and node document set to DOCUMENT.

[7] http://www.ecma-international.org/ecma-262/6.0/#table-6
[8] 
http://www.ecma-international.org/ecma-262/6.0/#sec-super-keyword-runtime-semantics-evaluation

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[Xiaoqian Wu]

Hi Kochi, and all,

The remote participation information of the 25th Jan Web Components meeting is 
available:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md#logistics
 


- VoIP: Join WebEx meeting (via 
https://mit.webex.com/mit/j.php?MTID=me4b93a7982bfcc65aec97d2fa899e787), 
Password [1] Required.
- Phone: +1-617-324- (US Toll Number), 645770213 (access code).

Thanks.

--
xiaoqian

[1] https://lists.w3.org/Archives/Member/w3c-archive/2016Jan/0079.html 


> On 6 Jan 2016, at 6:59 PM, Takayoshi Kochi (河内 隆仁)  wrote:
> 
> 
> 
> On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa  > wrote:
> 
> > On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁)  > > wrote:
> >
> > Is there any option to attend this remotely (telcon or video conference)?
> >
> > 2015年12月9日(水) 10:26 Ryosuke Niwa >:
> >>
> >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile 
> >> > > wrote:
> >> >
> >> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile 
> >> > > wrote:
> >> >
> >> >> we are trying to shift the date of the Custom Elements meeting to *25* 
> >> >> Jan, from the previously proposed date of 29th.
> >> >>
> >> >> We are currently looking for a host in the Bay area - offers gratefully 
> >> >> received.
> >> >
> >> > Apple have kindly agreed to host the meeting, so it will be at 1 
> >> > Infinite Loop, Cupertino. I'll update the page shortly with logistics 
> >> > information.
> >> >
> >> > Note that if you are driving, you should allow an extra 10 minutes or so 
> >> > for parking. Carpool!
> >>
> >> Added logistics on
> >> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md 
> >> 
> 
> The conference room has a video/telephone conference capability so we should 
> be able to set up Webinars assuming someone from W3C can help us set it up.
> 
> 
> Thanks!
> Please update the logistics page if it is set up.
>  
> - R. Niwa
> 
> 
> -- 
> Takayoshi Kochi

Remote participation Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[Chaals McCathie Nevile]

On Wed, 06 Jan 2016 11:59:55 +0100, Takayoshi Kochi (河内 隆仁)  
 wrote:



On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa  wrote:

> On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁)  


>
> Is there any option to attend this remotely (telcon or video  
conference)?

>
> 2015年12月9日(水) 10:26 Ryosuke Niwa :

[...]

>> Added logistics on
>>  
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md


The conference room has a video/telephone conference capability so we
should be able to set up Webinars assuming someone from W3C can help us  
set it up.



Thanks!
Please update the logistics page if it is set up.



On my task list this week.

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[Ryosuke Niwa]

> On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁)  wrote:
> 
> Is there any option to attend this remotely (telcon or video conference)?
> 
> 2015年12月9日(水) 10:26 Ryosuke Niwa :
>> 
>> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile  
>> > wrote:
>> >
>> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile 
>> >  wrote:
>> >
>> >> we are trying to shift the date of the Custom Elements meeting to *25* 
>> >> Jan, from the previously proposed date of 29th.
>> >>
>> >> We are currently looking for a host in the Bay area - offers gratefully 
>> >> received.
>> >
>> > Apple have kindly agreed to host the meeting, so it will be at 1 Infinite 
>> > Loop, Cupertino. I'll update the page shortly with logistics information.
>> >
>> > Note that if you are driving, you should allow an extra 10 minutes or so 
>> > for parking. Carpool!
>> 
>> Added logistics on
>> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md

The conference room has a video/telephone conference capability so we should be 
able to set up Webinars assuming someone from W3C can help us set it up.

- R. Niwa

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[河内 隆仁]

On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa  wrote:

>
> > On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) 
> wrote:
> >
> > Is there any option to attend this remotely (telcon or video conference)?
> >
> > 2015年12月9日(水) 10:26 Ryosuke Niwa :
> >>
> >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >> >
> >> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >> >
> >> >> we are trying to shift the date of the Custom Elements meeting to
> *25* Jan, from the previously proposed date of 29th.
> >> >>
> >> >> We are currently looking for a host in the Bay area - offers
> gratefully received.
> >> >
> >> > Apple have kindly agreed to host the meeting, so it will be at 1
> Infinite Loop, Cupertino. I'll update the page shortly with logistics
> information.
> >> >
> >> > Note that if you are driving, you should allow an extra 10 minutes or
> so for parking. Carpool!
> >>
> >> Added logistics on
> >> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md
>
> The conference room has a video/telephone conference capability so we
> should be able to set up Webinars assuming someone from W3C can help us set
> it up.
>
>
Thanks!
Please update the logistics page if it is set up.


> - R. Niwa
>
>
-- 
Takayoshi Kochi

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[河内 隆仁]

Is there any option to attend this remotely (telcon or video conference)?

2015年12月9日(水) 10:26 Ryosuke Niwa :

>
> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >
> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >
> >> we are trying to shift the date of the Custom Elements meeting to *25*
> Jan, from the previously proposed date of 29th.
> >>
> >> We are currently looking for a host in the Bay area - offers gratefully
> received.
> >
> > Apple have kindly agreed to host the meeting, so it will be at 1
> Infinite Loop, Cupertino. I'll update the page shortly with logistics
> information.
> >
> > Note that if you are driving, you should allow an extra 10 minutes or so
> for parking. Carpool!
>
> Added logistics on
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md
>
> - R. Niwa
>
>
>

RE: Custom elements contentious bits

[Domenic Denicola]

From: Brian Kardell [mailto:bkard...@gmail.com] 

> I'd really like to understand where things really are with async/sync/almost 
> sync - does anyone have more notes or would they be willing to provide more 
> exlpanation?  I've read the linked contentious bit and I'm still not sure 
> that I understand.

The question is essentially about at what time the custom element callbacks are 
being called. There are three possible times:

1. Synchronously, i.e. from within the middle of the DOM Standard's relevant 
algorithms/from within browser C++ code, we call out to JavaScript. There is 
then no queuing.
2. "Nanotask" timing, i.e. right before exiting C++ code and returning back to 
JS, we call out to queued JS.
3. Microtask timing, i.e. we put the callbacks on the standard microtask queue, 
letting any JS run to completion before running the microtasks.

The difference between 1 and 2 is very subtle and shows up only rarely, in 
complicated algorithms like cloning or editing. 3 is what you would more 
traditionally think of as "async".

> I can say, for whatever it is worth, that given some significant time now 
> (we're a few years in) with web component polyfills at this point I do see 
> more clearly the desire for sync.  It's unintuitive at some level in a world 
> where we (including me) tend to really want to make things async but if I am 
> being completely honest, I've found an increasing number of times where this 
> is a actually little nightmarish to deal with and I feel almost like perhaps 
> this might be something of a "least worst" choice.  Perhaps there's some 
> really good ideas that I just haven't thought of/stumbled across yet but I 
> can tell you that for sure a whole lot of frameworks and even apps have their 
> own lifecycles in which they reason about things and the async nature makes 
> this very hard in those cases.

I'm not really sure what you're talking about here. Is it something besides 
Chrome's web components, perhaps some unrelated framework or polyfill? Chrome's 
web components have always used (2), which is not really async in any 
meaningful sense.

> Shadow DOM will definitely help address a whole lot of my cases because it'll 
> hide one end of things, but I can definitely see cases where even that 
> doesn't help if I need to actually coordinate.  I don't know if it is really 
> something to panic about but I feel like it's worth bringing up while there 
> are discussions going on.  The declarative nature and the seeming agreement 
> to adopt web-component _looking_ tags even in situations where they are not 
> exactly web components makes it easy enough to have mutually agreeing 
> "enough" implementations of things.  For example, I currently have a few 
> custom elements for which I have both a "native" definition and an angular 
> directive so that designers I know who write HTML and CSS can learn a 
> slightly improved vocabulary, say what they mean and quickly get a page setup 
> while app engineers can then simply make sure they wire up the right 
> implementation for the final product.  This wasn't my first choice:  I tried 
> going purely native but problems like the one described above created way too 
> much contention, more code, pitfalls and performance issues.  In the end it 
> was much simpler to have two for now and reap a significant portion of the 
> benefit if not the whole thing.

This is a bit off-topic but...

As you point out, the main benefit of custom elements is not that you can use 
custom tag names in your markup---that is easily accomplished today. The 
benefits are being able to use the DOM API on the resulting tree 
(document.querySelector("my-custom-el").myCustomMethod()) and, most 
importantly, lifecycle callbacks. If you want lifecycle callbacks with a 
third-party framework, you must let that framework control your page lifecycle. 
The things Angular does to ensure this are horrendous, e.g. monkeypatching 
every DOM method so that it can know when certain lifecycle events happen. 
Letting the browser simply call out to author-supplied callbacks when it's 
already doing work is going to be much nicer.

> Anywho... I'm really curious to understand where this stands atm or where 
> various companies disagree if they do.

Since nobody is proposing 3, where we stand now is that there seems to be a 
disagreement between 1 and 2. I don't really understand the advantages of 1 
over 2, but I do believe Apple still prefers 1. It would be great to hear more.

Re: Custom elements contentious bits

[Anne van Kesteren]

On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola  wrote:
> A bit ago Jan put together an initial draft of the "contentious bits" for 
> custom elements, in preparation for our January F2F. Today I went through and 
> expanded on the issues he put together, with the result at 
> https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits. 
> It morphed into a kind of agenda for the meeting, containing "Previously 
> contentious bits", "Contentious bits", "Other things to work out", and "Other 
> issues worth mentioning".
>
> It would be lovely if other vendors could take a look, and fill in anything 
> they think is missing, or correct any inaccuracies.

So my impression is that Apple is still in favor of synchronous
construction. Talking to developers from Ember.js they care about that
too (to the extent they even think this problem is worthwhile
solving). The "upgrade" problem is a more general problem we also have
with service workers and such. There's some kind of boostrapping thing
that might warrant a more general solution.

Would be great to have some cards on the table.

And with respect to that, Mozilla is interested in shipping Shadow
DOM. We continue to have concerns with regards to lack of integration
with the HTML Standard, but hope those will get resolved. Custom
elements is less of a priority for us at this point, so we're not sure
what to make of this meeting if things are still up in the air.


-- 
https://annevankesteren.nl/

Re: Custom elements contentious bits

[Brian Kardell]

On Thu, Dec 10, 2015 at 3:23 PM, Anne van Kesteren  wrote:

> On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola  wrote:
> > A bit ago Jan put together an initial draft of the "contentious bits"
> for custom elements, in preparation for our January F2F. Today I went
> through and expanded on the issues he put together, with the result at
> https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits.
> It morphed into a kind of agenda for the meeting, containing "Previously
> contentious bits", "Contentious bits", "Other things to work out", and
> "Other issues worth mentioning".
> >
> > It would be lovely if other vendors could take a look, and fill in
> anything they think is missing, or correct any inaccuracies.
>
> So my impression is that Apple is still in favor of synchronous
> construction. Talking to developers from Ember.js they care about that
> too (to the extent they even think this problem is worthwhile
> solving). The "upgrade" problem is a more general problem we also have
> with service workers and such. There's some kind of boostrapping thing
> that might warrant a more general solution.
>
> Would be great to have some cards on the table.
>
> And with respect to that, Mozilla is interested in shipping Shadow
> DOM. We continue to have concerns with regards to lack of integration
> with the HTML Standard, but hope those will get resolved. Custom
> elements is less of a priority for us at this point, so we're not sure
> what to make of this meeting if things are still up in the air.
>
>
> --
> https://annevankesteren.nl/
>
>

I'd really like to understand where things really are with
async/sync/almost sync - does anyone have more notes or would they be
willing to provide more exlpanation?  I've read the linked contentious bit
and I'm still not sure that I understand.  I can say, for whatever it is
worth, that given some significant time now (we're a few years in) with web
component polyfills at this point I do see more clearly the desire for
sync.  It's unintuitive at some level in a world where we (including me)
tend to really want to make things async but if I am being completely
honest, I've found an increasing number of times where this is a actually
little nightmarish to deal with and I feel almost like perhaps this might
be something of a "least worst" choice.  Perhaps there's some really good
ideas that I just haven't thought of/stumbled across yet but I can tell you
that for sure a whole lot of frameworks and even apps have their own
lifecycles in which they reason about things and the async nature makes
this very hard in those cases.

Shadow DOM will definitely help address a whole lot of my cases because
it'll hide one end of things, but I can definitely see cases where even
that doesn't help if I need to actually coordinate.  I don't know if it is
really something to panic about but I feel like it's worth bringing up
while there are discussions going on.  The declarative nature and the
seeming agreement to adopt web-component _looking_ tags even in situations
where they are not exactly web components makes it easy enough to have
mutually agreeing "enough" implementations of things.  For example, I
currently have a few custom elements for which I have both a "native"
definition and an angular directive so that designers I know who write HTML
and CSS can learn a slightly improved vocabulary, say what they mean and
quickly get a page setup while app engineers can then simply make sure they
wire up the right implementation for the final product.  This wasn't my
first choice:  I tried going purely native but problems like the one
described above created way too much contention, more code, pitfalls and
performance issues.  In the end it was much simpler to have two for now and
reap a significant portion of the benefit if not the whole thing.

Anywho... I'm really curious to understand where this stands atm or where
various companies disagree if they do.


-- 
Brian Kardell :: @briankardell

Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[Chaals McCathie Nevile]

On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile  
 wrote:


we are trying to shift the date of the Custom Elements meeting to *25*  
Jan, from the previously proposed date of 29th.


We are currently looking for a host in the Bay area - offers gratefully  
received.


Apple have kindly agreed to host the meeting, so it will be at 1 Infinite  
Loop, Cupertino. I'll update the page shortly with logistics information.


Note that if you are driving, you should allow an extra 10 minutes or so  
for parking. Carpool!


cheers

Chaals


If you plan to attend, please add your name to the meeting page:
  
(or let me know directly by email and I will add you).


Note that there are two attendee lists currently - those who hope to  
attend, and those who have made a firm commitment. I currently believe  
that Domenic, Travis, Elliott and I are confirmed for the 25th, so  
listed those people already


cheers

Chaals
For the chairs



--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[Ryosuke Niwa]

> On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile  
> wrote:
> 
> On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile 
>  wrote:
> 
>> we are trying to shift the date of the Custom Elements meeting to *25* Jan, 
>> from the previously proposed date of 29th.
>> 
>> We are currently looking for a host in the Bay area - offers gratefully 
>> received.
> 
> Apple have kindly agreed to host the meeting, so it will be at 1 Infinite 
> Loop, Cupertino. I'll update the page shortly with logistics information.
> 
> Note that if you are driving, you should allow an extra 10 minutes or so for 
> parking. Carpool!

Added logistics on
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md

- R. Niwa

Re: Custom elements contentious bits

[Dylan Barrell]

Domenic,

Closed shadow DOM and its impact on test automation and auditing is also a
very important issue.

--Dylan


On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola  wrote:

> Hi all,
>
> A bit ago Jan put together an initial draft of the "contentious bits" for
> custom elements, in preparation for our January F2F. Today I went through
> and expanded on the issues he put together, with the result at
> https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits.
> It morphed into a kind of agenda for the meeting, containing "Previously
> contentious bits", "Contentious bits", "Other things to work out", and
> "Other issues worth mentioning".
>
> It would be lovely if other vendors could take a look, and fill in
> anything they think is missing, or correct any inaccuracies.
>
> Over all I'm pretty optimistic that we've narrowed this down to a small
> set of issues and will be able to make progress at the F2F.
>
>


-- 
Download FireEyes Free: http://getfireeyes.com/

Life is ten percent what happens to you and ninety percent how you respond
to it. - Lou Holtz

Re: Custom elements backing swap proposal

[Dominic Cooney]

On Sat, Oct 24, 2015 at 4:02 PM, Ryosuke Niwa  wrote:

>
> > On Oct 24, 2015, at 9:55 AM, Elliott Sprehn 
> wrote:
> >
> > I've been thinking about ways to make custom elements violate the
> consistency principle less often and had a pretty awesome idea recently.
> >
> > Unfortunately I won't be at TPAC, but I'd like to discuss this idea in
> person. Can we setup a custom element discussion later in the year?
>
> Certainly. I won't be back in the states until 11/8 and both Blink and
> WebKit are having their contributor's meetings in the following week so how
> about the week of November 16th?
>
> If not, the first and the second weeks of December also works.
>
> > The current  "synchronous in the parser" model doesn’t feel good to me
> because cloneNode() and upgrades are still async,
>
> I've been making a prototype of custom elements API in which cloneNode and
> all other internal construction of elements are sync so only upgrading is
> async in our design.
>
> > and I fear other things (ex. parser in editing, innerHTML) may need to
> be as well.
>
> Not in our design.
>
> > So, while we've covered up the inconsistent state of the element in one
> place (parser), we've left it to be a surprise in the others which seems
> worse than just always being async. This led me to a crazy idea that would
> get us consistency between all these cases:
> >
> > What if we use a different pimpl object (C++ implementation object) when
> running the constructor, and then move the children/shadows and attributes
> after the fact? This element can be reused (as implementation detail), and
> any attempt to append it to another element would throw.
>
> This is not the first time this (or a similar) idea has been brought up.
>
> The problem with this approach is that authors can still find the old
> non-temporary "pimpl" (where did this term come from?) via
> querySelectorAll, getElementsByTagName, etc... because it's still in the
> document. (If it's not in the document, then we would have the iframe
> reloading problem)
>

I agree this is a problem.
document.querySelector('some-creating-custom-element').parentNode being
null is surprising.

esprehn, could your proposal be spec'ed equivalently by saying that the
APIs which look up the tree (parentNode, etc.) return null during "creation
time"?


> And when the constructors or unrelated code invoked by the constructor
> access the old "pimpl", we have two options:
>
> 1. Use the same wrapper as the one we're creating.  This is weird because
> the element as perceived by other DOM APIs such as querySelectorAll and the
> actual object behaves differently.
>
> 2. Create a new wrapper. But what are we going to do this with new wrapper
> when we swap back "pimpl" after calling the constructor?  Also, this would
> mean that the identify of elements will change.
>
> There is yet another alternative: make all other DOM APIs behave as if
> these pre-construction custom elements don't exist. However, that is a much
> tricker thing to implement (especially if you didn't want to worsen the
> performance) than making all construction sync at least in WebKit.
>
> - R. Niwa
>
>
>

Re: Custom elements backing swap proposal

[Ryosuke Niwa]

> On Oct 24, 2015, at 9:55 AM, Elliott Sprehn  wrote:
> 
> I've been thinking about ways to make custom elements violate the consistency 
> principle less often and had a pretty awesome idea recently. 
> 
> Unfortunately I won't be at TPAC, but I'd like to discuss this idea in 
> person. Can we setup a custom element discussion later in the year?

Certainly. I won't be back in the states until 11/8 and both Blink and WebKit 
are having their contributor's meetings in the following week so how about the 
week of November 16th?

If not, the first and the second weeks of December also works.

> The current  "synchronous in the parser" model doesn’t feel good to me 
> because cloneNode() and upgrades are still async,

I've been making a prototype of custom elements API in which cloneNode and all 
other internal construction of elements are sync so only upgrading is async in 
our design.

> and I fear other things (ex. parser in editing, innerHTML) may need to be as 
> well.

Not in our design.

> So, while we've covered up the inconsistent state of the element in one place 
> (parser), we've left it to be a surprise in the others which seems worse than 
> just always being async. This led me to a crazy idea that would get us 
> consistency between all these cases:
> 
> What if we use a different pimpl object (C++ implementation object) when 
> running the constructor, and then move the children/shadows and attributes 
> after the fact? This element can be reused (as implementation detail), and 
> any attempt to append it to another element would throw.

This is not the first time this (or a similar) idea has been brought up.

The problem with this approach is that authors can still find the old 
non-temporary "pimpl" (where did this term come from?) via querySelectorAll, 
getElementsByTagName, etc... because it's still in the document. (If it's not 
in the document, then we would have the iframe reloading problem)

And when the constructors or unrelated code invoked by the constructor access 
the old "pimpl", we have two options:

1. Use the same wrapper as the one we're creating.  This is weird because the 
element as perceived by other DOM APIs such as querySelectorAll and the actual 
object behaves differently.

2. Create a new wrapper. But what are we going to do this with new wrapper when 
we swap back "pimpl" after calling the constructor?  Also, this would mean that 
the identify of elements will change.

There is yet another alternative: make all other DOM APIs behave as if these 
pre-construction custom elements don't exist. However, that is a much tricker 
thing to implement (especially if you didn't want to worsen the performance) 
than making all construction sync at least in WebKit.

- R. Niwa

RE: Custom elements Constructor-Dmitry baseline proposal

[Domenic Denicola]

From: Maciej Stachowiak [mailto:m...@apple.com]


 On Aug 17, 2015, at 3:19 PM, Domenic Denicola d...@domenic.me wrote:

  - Parser-created custom elements and upgraded custom elements will
 have their constructor and attributeChange callbacks called at a time when all
 their children and attributes are already present, but
 
 Did you change that relative to the spec? Previously, parser-created custom
 elements would have their constructor called at a time when an
 unpredictable number of their children were present.

You're right that I didn't get this quite spelled out. Fortunately, given your 
below suggestion, I would have had to rewrite it anyway :).

  - Elements created via new XCustomElement() or
 document.createElement(x-custom-element) will have their constructor
 run at a time when no children or attributes are present.
 
 If you really got it down to two states, I like reducing the number of word
 states, but I would prefer to put parser-created custom elements in this
 second bucket. They should have their constructor called while they have no
 children and attributes, instead of when they have all of them.

This seems reasonable and doable. Here's my try at making it work:

- Diff from previous revision: 
https://github.com/w3c/webcomponents/pull/297/files?short_path=876522d#diff-876522df93719f9da9871064880af5d2
- All together: 
https://github.com/domenic/webcomponents/blob/constructor-dmitry-revisions/proposals/Constructor-Dmitry.md

 If any of this happens, an upgradeable element will be stuck in the pre-
 upgrade state for a possibly unboundedly long amount of time.

This seems totally fine to me though. You're basically saying that you don't 
upgrade elements that are left often. Not a big deal. You have to actually have 
a full `x-custom-foo.../x-custom-foo` before you get a proper custom 
element. Just `x-custom-foo...` alone does not cut it.

 Against this, we have the proposal to forcibly put elements in a naked state
 before calling the constructor for upgrade, then restore them. That has the
 known bad property of forcing iframe children to reload. I owe the group
 thoughts on whether we can avoid that problem.

 ...

 I will read the document more closely soon, to see if it seems like a
 reasonable baseline. I agree it would be fine to start with something good
 that uses the constructor and has two possible stats for constructor
 invocation, then see if we can get it down to one.

Awesome! And yeah, the intent of this was exactly to provide such a baseline, 
and see if we could come up with a good solution for reducing the two states 
down to one using trickery such as that you mention. As a summary, after the 
above changes we have these two states:

- Upgraded custom elements, or elements created via other algorithms that are 
constructing a larger tree (such as cloneNode), will have their constructor and 
attributeChange callbacks called at a time when all their children and 
attributes are already present.
- Elements created via new XCustomElement() or 
document.createElement(x-custom-element) or via the parser will have their 
constructor run at a time when no children or attributes are present.

Note that we could move elements created via other algorithms that are 
constructing a larger tree into the latter bucket too, at the cost of 
synchronous script execution during all such algorithms. But the UA appetite 
for that was... mixed, and I don't think we should do so. It seems fine to 
leave their fate the same as upgrades, whichever way it shakes out.

Re: Custom elements Constructor-Dmitry baseline proposal

[Maciej Stachowiak]

 On Aug 17, 2015, at 3:19 PM, Domenic Denicola d...@domenic.me wrote:
 
 In 
 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_webcomponents_blob_gh-2Dpages_proposals_Constructor-2DDmitry.mdd=BQIGaQc=eEvniauFctOgLOKGJOplqwr=Cq0heWYmrUNShLjLIzuzGQm=U2qIHSkYawudMNTponjVOJxTr1-blzlm_skvYTCFFrks=Fqq6RL3oe2zmH8pGykh6XfqVC6LYMZILABlqZPRGG74e=
   I’ve written up in some detail what I consider to be the current 
 state-of-the-art in custom elements proposals. That is, if we take the 
 current spec, and modify it in ways that everyone agrees are good ideas, we 
 end up with the Constructor-Dmitry proposal.
 
 The changes, in descending order of importance, are:
 
 - Don't generate new classes as return values from registerElement, i.e. 
 don't treat the second argument as a dumb { prototype } property bag. (This 
 is the original Dmitry proposal.)
 - Allow the use of ES2015 constructors directly, instead of createdCallback. 
 (This uses the constructor-call trick we discovered at the F2F.)
 - Use symbols instead of strings for custom element callbacks.
 - Fire attributeChanged and attached callbacks during parsing/upgrading
 
 Those of you at the F2F may remember me saying something like If only we 
 knew about the constructor call trick before this meeting, I think we would 
 have had consensus! This document outlines what I think the consensus would 
 have looked like, perhaps modulo some quibbling about replacing or 
 supplementing attached/detached with different callbacks.
 
 So my main intent in writing this up is to provide a starting point that we 
 can all use, to talk about potential modifications. In particular, at the F2F 
 there was a lot of contention over the consistent world view issue, which 
 is still present in the proposal:
 
 - Parser-created custom elements and upgraded custom elements will have their 
 constructor and attributeChange callbacks called at a time when all their 
 children and attributes are already present, but

Did you change that relative to the spec? Previously, parser-created custom 
elements would have their constructor called at a time when an unpredictable 
number of their children were present. 

 - Elements created via new XCustomElement() or 
 document.createElement(x-custom-element) will have their constructor run at 
 a time when no children or attributes are present.

If you really got it down to two states, I like reducing the number of word 
states, but I would prefer to put parser-created custom elements in this second 
bucket. They should have their constructor called while they have no children 
and attributes, instead of when they have all of them.

My reasons for this:

(1) This is more likely to lead to correctly coding your custom elements to 
rely on change notifications exclusively, rather than on what is present at 
parse time.
(2) Framework developers find it a footgun and an inconvenience for 
parser-created elements to have their constructor called with children present.
(3) It is possible for a parser-created element to render before all of its 
children are present. It's also possible for it to never reach the state where 
it is known all of its children [that will be created by the parser] are 
present. I can give examples if you like. Based on this, I think it's better 
to upgrade them as early as possible.

For these two reasons (#1 and #2 were mentioned in the f2f, #3 is something I 
thought of later), I think parser-created elements should have their 
constructor called early instead of late.

However, if we care about these edge cases, note that #3 *also* applies to 
upgrade. If we want to do upgrade late, and it's on a parser-created element, 
it may be the case that the element has already rendered when the info needed 
to upgrade it comes in, but it may be an unboundedly long time until all its 
children come in.

I guess I should give examples, so cases where this can happen:

(A) Load of the main document stalls partway through the element's children, 
before a close tag has been seen. But the upgrade script comes in via script 
async even during the stall.
(B) The document keeps loading forever by design. Admittedly this is unlikely 
for modern web design.
(C) The document is created with document.open()/document.write(), the element 
in question never has a close tag written, and no one ever calls 
document.close(). People actually still do this sometimes to populate opened 
windows or the like.

If any of this happens, an upgradeable element will be stuck in the pre-upgrade 
state for a possibly unboundedly long amount of time.

This seems like a bad property. 

Against this, we have the proposal to forcibly put elements in a naked state 
before calling the constructor for upgrade, then restore them. That has the 
known bad property of forcing iframe children to reload. I owe the group 
thoughts on whether we can avoid that problem.

 
 If we still think that this is a showstopper to consensus (do we!?) then I 
 

Re: Custom elements Constructor-Dmitry baseline proposal

[Anne van Kesteren]

Thank you for writing this up. Would be interesting to hear what
Maciej and Ryosuke think.

On Tue, Aug 18, 2015 at 12:19 AM, Domenic Denicola d...@domenic.me wrote:
 - Use symbols instead of strings for custom element callbacks.

So the way this is done is that they are publicly available on the
prototype. Does that mean behavior can change during the lifetime?
What does that mean for builtin elements that do not have these
callbacks on their prototype?

Also, we probably need to rename registerElement() due to the
different semantics.

Also, you want to sort the attributes in some way before calling
attributeChanged from upgrades, or we must finally agree on that
attributes are sorted in some deterministic way:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=17871

I also thought the idea was to pass attached/detached their changed
ancestor and perhaps rename them inserted/removed (and no longer scope
them to document change).


-- 
https://annevankesteren.nl/

Re: Custom Elements: createdCallback cloning

[Olli Pettay]

On 07/13/2015 09:22 AM, Anne van Kesteren wrote:

On Sun, Jul 12, 2015 at 9:32 PM, Olli Pettay o...@pettay.fi wrote:

Well, this printing case would just clone the final flattened tree without
the original document knowing any cloning happened.
(scripts aren't suppose to run in Gecko's static clone documents, which
print preview on linux and Windows and printing use)

If one needs a special DOM tree for printing, beforeprint event should be
used to modify the DOM.


Sure, but you'd lose some stuff, e.g. canvas, and presumably custom
elements if they require copying some state, due to the cloning.
(Unless it's doing more than just cloning.)




Clone-for-printing takes a snapshot of canvas and animated images etc.

And what state from a custom element would be needed in static clone document?
If the state is there in original document, and the state is somehow affecting 
layout, it should be
copied (well, not :focus/:active and such).

Anyhow, I see clone-for-printing very much an implementation detail, and 
wouldn't be too worried about it here.
There is enough to worry with plain normal element.cloneNode(true); or 
selection/range handling.



-Olli

Re: Custom Elements: createdCallback cloning

[Ryosuke Niwa]

 On Jul 12, 2015, at 11:30 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Mon, Jul 13, 2015 at 1:10 AM, Dominic Cooney domin...@google.com wrote:
 Yes. I am trying to interpret this in the context of the esdiscuss thread
 you linked. I'm not sure I understand the problem with private state,
 actually. Private state is allocated for DOM wrappers in Chromium today
 (like Gecko), including Custom Elements; it's not a problem. DOM wrapper
 creation is controlled by the UA, which can arrange for allocating the
 slots.
 
 Sure, but this assumes elements will be backed by something other than
 JavaScript forever. Or at the very least that custom elements will
 always be able to do less than builtin elements.
 
 
 Is there a plan for author classes to be able to have private state or
 something?
 
 Yes, as discussed in that es-discuss thread.
 
 
 Thanks. I can understand how editing and Range.cloneContents would use
 cloning. How is it relevant that Range is depended on by Selection?
 Selection may delete things but it does not clone them.
 
 Editing operations operate on selections, but maybe I'm mistaken about
 that? Either way, you got the problem.

Editing operations use cloning heavily.  As counter-intuitive as it sounds, 
deleting a range of text also involves cloning elements in some cases.

- R. Niwa

Re: Custom Elements: createdCallback cloning

[Anne van Kesteren]

On Sun, Jul 12, 2015 at 9:32 PM, Olli Pettay o...@pettay.fi wrote:
 Well, this printing case would just clone the final flattened tree without
 the original document knowing any cloning happened.
 (scripts aren't suppose to run in Gecko's static clone documents, which
 print preview on linux and Windows and printing use)

 If one needs a special DOM tree for printing, beforeprint event should be
 used to modify the DOM.

Sure, but you'd lose some stuff, e.g. canvas, and presumably custom
elements if they require copying some state, due to the cloning.
(Unless it's doing more than just cloning.)


-- 
https://annevankesteren.nl/

Re: Custom Elements: createdCallback cloning

[Anne van Kesteren]

On Mon, Jul 13, 2015 at 1:10 AM, Dominic Cooney domin...@google.com wrote:
 Yes. I am trying to interpret this in the context of the esdiscuss thread
 you linked. I'm not sure I understand the problem with private state,
 actually. Private state is allocated for DOM wrappers in Chromium today
 (like Gecko), including Custom Elements; it's not a problem. DOM wrapper
 creation is controlled by the UA, which can arrange for allocating the
 slots.

Sure, but this assumes elements will be backed by something other than
JavaScript forever. Or at the very least that custom elements will
always be able to do less than builtin elements.


 Is there a plan for author classes to be able to have private state or
 something?

Yes, as discussed in that es-discuss thread.


 Thanks. I can understand how editing and Range.cloneContents would use
 cloning. How is it relevant that Range is depended on by Selection?
 Selection may delete things but it does not clone them.

Editing operations operate on selections, but maybe I'm mistaken about
that? Either way, you got the problem.


 That during cloning certain DOM operations cease to function, basically.

 This sounds interesting; it may even be useful for authors to be able to
 assert that between two points they did not modify the DOM.

Short of rewriting ranges and editing, that seems like the only viable
alternative to prototype swizzling, provided you're okay with seeing
upgrades as a distinct problem.


-- 
https://annevankesteren.nl/

Re: Custom Elements: createdCallback cloning

[Olli Pettay]

On 07/12/2015 08:09 PM, Anne van Kesteren wrote:

On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney domin...@google.com wrote:

I think the most important question here, though, is not constructors or
prototype swizzling.


I guess that depends on what you want to enable. If you want to
recreate existing elements in terms of Custom Elements, you need
private state.



- Progressive Enhancement. The author can write more things in markup and
present them while loading definitions asynchronously. Unlike progressive
enhancement by finding and replacing nodes in the tree, prototype swizzling
means that the author is free to detach a subtree, do a setTimeout, and
reattach it without worrying whether the definition was registered in the
interim.


How does this not result in the same issues we see with FOUC? It seems
rather problematic for the user to be able to interact with components
that do not actually work, but I might be missing things.



- Fewer (no?) complications with parsing and cloning. Prototype swizzling
makes it possible to decouple constructing the tree, allocating the wrapper,
and running Custom Element initialization. For example, if you have a Custom
Element in Chromium that does not have a createdCallback, we don't actually
allocate its wrapper until it's touched (like any Element.) But it would not
be possible to distinguish whether a user-provided constructor is trivial
and needs this.


True true.



Could you share a list of things that use the cloning algorithm?


In the DOM specification a heavy user is ranges. In turn, selection
heavily depends upon ranges. Which brings us to editing operations
such as cut  copy. None of those algorithms anticipate the DOM
changing around under them. (Though perhaps as long as mutation events
are still supported there are some corner cases there, though the
level of support of those varies.)

In Gecko printing also clones the tree and definitely does not expect
that to have side effects.


Well, this printing case would just clone the final flattened tree without the 
original document knowing any cloning happened.
(scripts aren't suppose to run in Gecko's static clone documents, which print 
preview on linux and Windows and printing use)


If one needs a special DOM tree for printing, beforeprint event should be used 
to modify the DOM.



Note that this would break with prototype
swizzling too. Or at least you'd get a less pretty page when
printing...



What do you mean by mode switch?


That during cloning certain DOM operations cease to function, basically.

Re: Custom Elements: createdCallback cloning

[Dominic Cooney]

On Mon, Jul 13, 2015 at 4:32 AM, Olli Pettay o...@pettay.fi wrote:

 On 07/12/2015 08:09 PM, Anne van Kesteren wrote:

 On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney domin...@google.com
 wrote:

 I think the most important question here, though, is not constructors or
 prototype swizzling.


 I guess that depends on what you want to enable. If you want to
 recreate existing elements in terms of Custom Elements, you need
 private state.


Yes. I am trying to interpret this in the context of the esdiscuss thread
you linked. I'm not sure I understand the problem with private state,
actually. Private state is allocated for DOM wrappers in Chromium today
(like Gecko), including Custom Elements; it's not a problem. DOM wrapper
creation is controlled by the UA, which can arrange for allocating the
slots.

Is there a plan for author classes to be able to have private state or
something?


  - Progressive Enhancement. The author can write more things in markup and
 present them while loading definitions asynchronously. Unlike progressive
 enhancement by finding and replacing nodes in the tree, prototype
 swizzling
 means that the author is free to detach a subtree, do a setTimeout, and
 reattach it without worrying whether the definition was registered in the
 interim.


 How does this not result in the same issues we see with FOUC? It seems
 rather problematic for the user to be able to interact with components
 that do not actually work, but I might be missing things.


Although you mention FOUC, this isn't the same as FOUC because the
component can be styled (particularly with :unresolved). But as you go on
to mention, there is the question of interactivity. Here are my
observations:

- In some cases, the user may not care that the component is briefly not
interactive. For example, have you noticed that the GitHub 3 days ago
labels don't have their definitions briefly?

- In some cases, the author can continue to use things like onclick
attributes to provide some fallback interactivity.

- In the majority of cases, you have to ask what's better. Is it better to
have some presentation (like an :unresolved rule showing a loading spinner,
maybe with animated transitions to the interactive state) with the page
scrollable and other things interactive, or a blank page blocked on
definitions?

 - Fewer (no?) complications with parsing and cloning. Prototype swizzling
 makes it possible to decouple constructing the tree, allocating the
 wrapper,
 and running Custom Element initialization. For example, if you have a
 Custom
 Element in Chromium that does not have a createdCallback, we don't
 actually
 allocate its wrapper until it's touched (like any Element.) But it would
 not
 be possible to distinguish whether a user-provided constructor is trivial
 and needs this.


 True true.


  Could you share a list of things that use the cloning algorithm?


 In the DOM specification a heavy user is ranges. In turn, selection
 heavily depends upon ranges. Which brings us to editing operations
 such as cut  copy. None of those algorithms anticipate the DOM
 changing around under them. (Though perhaps as long as mutation events
 are still supported there are some corner cases there, though the
 level of support of those varies.)


Thanks. I can understand how editing and Range.cloneContents would use
cloning. How is it relevant that Range is depended on by Selection?
Selection may delete things but it does not clone them.


 In Gecko printing also clones the tree and definitely does not expect
 that to have side effects.


 Well, this printing case would just clone the final flattened tree without
 the original document knowing any cloning happened.
 (scripts aren't suppose to run in Gecko's static clone documents, which
 print preview on linux and Windows and printing use)


 If one needs a special DOM tree for printing, beforeprint event should be
 used to modify the DOM.



  Note that this would break with prototype
 swizzling too. Or at least you'd get a less pretty page when
 printing...


  What do you mean by mode switch?


 That during cloning certain DOM operations cease to function, basically.


This sounds interesting; it may even be useful for authors to be able to
assert that between two points they did not modify the DOM.

Re: Custom Elements: createdCallback cloning

[Anne van Kesteren]

On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney domin...@google.com wrote:
 I think the most important question here, though, is not constructors or
 prototype swizzling.

I guess that depends on what you want to enable. If you want to
recreate existing elements in terms of Custom Elements, you need
private state.


 - Progressive Enhancement. The author can write more things in markup and
 present them while loading definitions asynchronously. Unlike progressive
 enhancement by finding and replacing nodes in the tree, prototype swizzling
 means that the author is free to detach a subtree, do a setTimeout, and
 reattach it without worrying whether the definition was registered in the
 interim.

How does this not result in the same issues we see with FOUC? It seems
rather problematic for the user to be able to interact with components
that do not actually work, but I might be missing things.


 - Fewer (no?) complications with parsing and cloning. Prototype swizzling
 makes it possible to decouple constructing the tree, allocating the wrapper,
 and running Custom Element initialization. For example, if you have a Custom
 Element in Chromium that does not have a createdCallback, we don't actually
 allocate its wrapper until it's touched (like any Element.) But it would not
 be possible to distinguish whether a user-provided constructor is trivial
 and needs this.

True true.


 Could you share a list of things that use the cloning algorithm?

In the DOM specification a heavy user is ranges. In turn, selection
heavily depends upon ranges. Which brings us to editing operations
such as cut  copy. None of those algorithms anticipate the DOM
changing around under them. (Though perhaps as long as mutation events
are still supported there are some corner cases there, though the
level of support of those varies.)

In Gecko printing also clones the tree and definitely does not expect
that to have side effects. Note that this would break with prototype
swizzling too. Or at least you'd get a less pretty page when
printing...


 What do you mean by mode switch?

That during cloning certain DOM operations cease to function, basically.


-- 
https://annevankesteren.nl/

Re: Custom Elements: createdCallback cloning

[Dominic Cooney]

On Thu, Jul 2, 2015 at 4:05 PM, Anne van Kesteren ann...@annevk.nl wrote:

 In the interest of moving forward I tried to more seriously consider
 Dmitry's approach. Based on es-discussion discussion
 https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors
 it seems likely new JavaScript features (such as private state) will
 be tied to object creation. This makes the prototype-swizzling design
 even less appealing, in my opinion.


Ironically this is a minor reason that Chromium preferred prototype
swizzling to blessing author-provided constructors:

When allocating JavaScript objects to wrap DOM objects (wrappers),
Chromium adds extra internal space to hold the address of the corresponding
C++ object. (V8 calls this extra internal space mechanism an Internal
Field
https://code.google.com/p/chromium/codesearch#chromium/src/v8/include/v8.hq=v8.h%20include/vsq=package:chromiumtype=csl=4660.)
This is efficient (the space is accessed by offset; they don't have names
like properties do) and private (this mechanism is ancient--it predates
symbols--and is inaccessible to JavaScript because the space has no name
and is separate to how properties are stored.)

Because Custom Elements did not change how wrappers were allocated, Custom
Elements wrappers in Chromium continue to have the necessary extra storage
space. Because the Custom Element constructor was controlled by the user
agent, we could ensure that it used the same mechanism for allocating
wrappers.

We can't do that with a user-provided constructor, because V8 has already
allocated the object (for this) by the time the constructor starts to
run. Any solution in this space may force Chromium to allocate an
additional object with the extra space. This may not be a disaster because,
first, generational GC makes allocating lots of short-lived objects
relatively cheap; and second, like Objective-C, JavaScript allows
constructors to return a different object (and my understanding is that
doing this in an ES6 constructor effectively sets this.) But it is a bit
gross.

Around summer 2012? 2013? I experimented with using a Symbol-like thing
(which V8 calls Hidden Fields) to store the pointer to the C++ object on
Custom Element wrappers in Chromium. (So those wrappers had a different
shape to most element wrappers.) We felt this design was not feasible
because it was slower to access, made the objects larger, and complicated
Chromium's DOM bindings which now needed to fall back to checking for this
property.

I think the most important question here, though, is not constructors or
prototype swizzling. It's whether elements created before a definition is
available get enlivened with the definition when it is available. I don't
like prototype swizzling, but I do like what it lets us do:

- Progressive Enhancement. The author can write more things in markup and
present them while loading definitions asynchronously. Unlike progressive
enhancement by finding and replacing nodes in the tree, prototype swizzling
means that the author is free to detach a subtree, do a setTimeout, and
reattach it without worrying whether the definition was registered in the
interim.

- Fewer (no?) complications with parsing and cloning. Prototype swizzling
makes it possible to decouple constructing the tree, allocating the
wrapper, and running Custom Element initialization. For example, if you
have a Custom Element in Chromium that does not have a createdCallback, we
don't actually allocate its wrapper until it's touched (like any Element.)
But it would not be possible to distinguish whether a user-provided
constructor is trivial and needs this.

It's a tradeoff. There are definite disadvantages to the current
specification; prototype swizzling is one of them. Not sure if that
background is useful...


 Meanwhile, I have not made much progress on the cloning question. As
 Domenic pointed out, that would also either require
 prototype-swizzling or invoking the constructor, there's not really a
 third way. I guess for that to work cloneNode() and various editing
 operations would have to become resilient against JavaScript executing
 in the middle of them,


Could you share a list of things that use the cloning algorithm?


 something that has caused (is causing?) us a
 ton of headaches with mutation events. (Or the alternative, have some
 kind of mode switch for the DOM which is similarly a large
 undertaking.)


What do you mean by mode switch?


 Not sure what to do now :-/


 --
 https://annevankesteren.nl/

Re: Custom Elements: is=

[Dominic Cooney]

On Thu, Jul 2, 2015 at 3:59 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Jun 13, 2015, at 4:49 PM, Léonie Watson lwat...@paciellogroup.com
 wrote:
 
  From: Bruce Lawson [mailto:bru...@opera.com]
  Sent: 13 June 2015 16:34
 
  On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com
 wrote:
  why not use the extends= syntax you mentioned?
 
  my-button extends=button attributesPush/my-button
 
  because browsers that don't know about web components wouldn't pay any
 attention to my-button, and render Push as plain text.
 
  Of course! I should have thought of that.

 That's not entirely true.  If the implementation of my-button, let us call
 it MyButtonElement had the prototype that extends HTMLButtonElement, then
 the browser can set role=button just fine.


Excuse the intrusion, but I'm slightly confused by at least one point.
Maybe you could help me clear it up. It's related to what you term the
implementation of my-button. What is that? Is it something defined by the
web author (how?) or the user agent?

Sincerely,

Dominic

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

[Xiaoqian Wu]

 On 6 Jul, 2015, at 5:18 pm, Hayato Ito hay...@google.com wrote:
 
 I've finished the migration. All 141 bugs have been migrated [1]. I'll triage 
 the migrated bugs manually later.
 
 I'm sorry that public-webapps@ has received the mass flood of bugspam mail 
 again this time. That's unintentional.
 The lesson for for the future: We need to change also the setting of *every* 
 bugs to stop the auto-emails, not only from the default CC list.
 
 From now on, please use the GitHub issues [2] to file a bug for Web 
 Components. I've already updated [3] the editors' drafts of Custom Elements 
 and HTML Imports so that they have a link to GitHub Issues.
 xiaoqian@ will kindly disable the bugzilla component, Component Models, so 
 that people won't add a bug there.

Thanks Hayato.

Fyi, this bugzilla component has been disabled and renamed as HISTORICAL - 
Component Model”.

—
xiaoqian

 
 - [1]: https://github.com/w3c/webcomponents/issues/119 
 https://github.com/w3c/webcomponents/issues/119
 - [2]: https://github.com/w3c/webcomponents/issues 
 https://github.com/w3c/webcomponents/issues
 - [3]: 
 https://github.com/w3c/webcomponents/commit/54434ada278440999649915b00772b6e96e57d4d
  
 https://github.com/w3c/webcomponents/commit/54434ada278440999649915b00772b6e96e57d4d
 
 
 On Wed, Jul 1, 2015 at 4:24 PM Xiaoqian Wu xiaoq...@w3.org 
 mailto:xiaoq...@w3.org wrote:
 
 On 1 Jul, 2015, at 1:30 pm, Hayato Ito hay...@google.com 
 mailto:hay...@google.com wrote:
 
 Thank you. I appreciate that. Then, let me migrate all open bugs of 
 'Component Model'. I think that include also HTML Imports bugs in addition 
 to Custom Elements bugs.
 When I finish, I'll announce that.
 
 SGTM. Please go ahead.
 
 —
 xiaoqian

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

[Hayato Ito]

I've finished the migration. All 141 bugs have been migrated [1]. I'll
triage the migrated bugs manually later.

I'm sorry that public-webapps@ has received the mass flood of bugspam mail
again this time. That's unintentional.
The lesson for for the future: We need to change also the setting of
*every* bugs to stop the auto-emails, not only from the default CC list.

From now on, please use the GitHub issues [2] to file a bug for Web
Components. I've already updated [3] the editors' drafts of Custom Elements
and HTML Imports so that they have a link to GitHub Issues.
xiaoqian@ will kindly disable the bugzilla component, Component Models,
so that people won't add a bug there.

- [1]: https://github.com/w3c/webcomponents/issues/119
- [2]: https://github.com/w3c/webcomponents/issues
- [3]:
https://github.com/w3c/webcomponents/commit/54434ada278440999649915b00772b6e96e57d4d


On Wed, Jul 1, 2015 at 4:24 PM Xiaoqian Wu xiaoq...@w3.org wrote:


 On 1 Jul, 2015, at 1:30 pm, Hayato Ito hay...@google.com wrote:

 Thank you. I appreciate that. Then, let me migrate all open bugs of
 'Component Model'. I think that include also HTML Imports bugs in addition
 to Custom Elements bugs.
 When I finish, I'll announce that.


 SGTM. Please go ahead.

 —
 xiaoqian

Re: Custom Elements: is=

[Ryosuke Niwa]

 On Jun 13, 2015, at 4:49 PM, Léonie Watson lwat...@paciellogroup.com wrote:
 
 From: Bruce Lawson [mailto:bru...@opera.com] 
 Sent: 13 June 2015 16:34
 
 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote:
 why not use the extends= syntax you mentioned?
 
 my-button extends=button attributesPush/my-button
 
 because browsers that don't know about web components wouldn't pay any 
 attention to my-button, and render Push as plain text.
 
 Of course! I should have thought of that.

That's not entirely true.  If the implementation of my-button, let us call it 
MyButtonElement had the prototype that extends HTMLButtonElement, then the 
browser can set role=button just fine.

 On Jun 13, 2015, at 5:41 PM, Patrick H. Lauke re...@splintered.co.uk wrote:
 
 On 13/06/2015 16:33, Bruce Lawson wrote:
 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote:
 why not use the extends= syntax you mentioned?
 
 my-button extends=button attributesPush/my-button
 
 because browsers that don't know about web components wouldn't pay any
 attention to my-button, and render Push as plain text.
 
  Browsers that don't know about web components will fall back to
 button with button
 this-is-made-much-more-marvellous-by=my-button (or whatever)
 
 However, this fallback will only really be useful for very simple cases, 
 where web components have been used to jazz up what essentially is still the 
 element that was extended. And, I would posit, any scripting that was done to 
 act on the all-singing, all-dancing new web component button (if it does 
 anything more than a regular button) would not work for the fallback. Unless 
 it's really just using web components for fancy styling (for instance having 
 a material design button that essentially still works just like a button) - 
 in which case, it makes more sense to work on stylability of standard 
 elements.


Precisely!  I've been saying that for the last two years.  It's so nice  
refreshing to hear someone making the same argument :)  And we (Apple) would 
love to solve the stylability issue of form elements.

- R. Niwa

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

[Xiaoqian Wu]

 On 1 Jul, 2015, at 1:30 pm, Hayato Ito hay...@google.com wrote:
 
 Thank you. I appreciate that. Then, let me migrate all open bugs of 
 'Component Model'. I think that include also HTML Imports bugs in addition to 
 Custom Elements bugs.
 When I finish, I'll announce that.

SGTM. Please go ahead.

—
xiaoqian

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

[Hayato Ito]

Thank you. I appreciate that. Then, let me migrate all open bugs of
'Component Model'. I think that include also HTML Imports bugs in addition
to Custom Elements bugs.
When I finish, I'll announce that.

On Tue, Jun 30, 2015 at 11:21 PM Xiaoqian Wu xiaoq...@w3.org wrote:

 Hi Hayato,

 public-webapps has been removed from the default CC list of ‘Component
 Model’. Please let us know when you finish migrating and we will recover
 this component ASAP.

 Thanks.

 —
 xiaoqian

  On 29 Jun, 2015, at 10:42 pm, Arthur Barstow art.bars...@gmail.com
 wrote:
 
  Yves, Xiaoqian, Mike - would one of you please do as Hayato requests
 below (and then notify him so he can move the Custom Elements bugs to
 Github)?
 
  -Thanks, ArtB
 
  On 6/25/15 2:49 AM, Hayato Ito wrote:
  I am thinking about migrating Custom Element bugs[1] to Web Components
 GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the
 consistency.
 
  Could someone turn off the automatic email to public-webapps for Custom
 Elements Bugs in the bugzilla so that we won't receive the mass flood of
 bugspam by marking the all bugs MOVED? I'm assuming the automatic email is
 on for public-webapps@.
 
  If you have any concerns about migrating, let me know that.
 
  [1]
 https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968hide_resolved=1
  [2] https://github.com/w3c/webcomponents/issues
 
  On Thu, May 28, 2015 at 10:35 AM Hayato Ito hay...@google.com mailto:
 hay...@google.com wrote:
 
 I totally agree. I'm really sorry for spamming. I forgot that
 closing a bug would trigger sending a mail to public-webapps@. My
 bad.
 
 I thought that a closing bug would notify only people who opted-in
 to add themselves to a list of cc in each bug. That might be a
 good opportunity for them to keep tracking of the bug status by
 subscribing a migrated bug on GitHub Issues.
 
 On Thu, May 28, 2015 at 6:49 AM Tab Atkins Jr.
 jackalm...@gmail.com mailto:jackalm...@gmail.com wrote:
 
 Note for the future (to you and editors of other specs in
 WebApps):
 
 Before doing this kind of mass bug editting, please turn off the
 automatic email to public-webapps.  If you can't do that
 yourself,
 Mike Smith can (at least, he's done it in the past).  That
 prevents
 the mass flood of bugspam from clogging up people's inboxes. ^_^
 
 ~TJ
 
 On Tue, May 26, 2015 at 8:30 PM, Hayato Ito hay...@google.com
 mailto:hay...@google.com wrote:
  PSA: I've finished the migration. All open bugs are now
 marked as MOVED
  with a link to the corresponding GitHub issue.
 
  On Mon, May 25, 2015 at 5:58 PM Hayato Ito
 hay...@google.com mailto:hay...@google.com wrote:
 
  Regarding with the Shadow DOM spec, more and more workflows
 are happening
  [1] on GitHub w3c/webcomponents repository recently.
  Therefore, I am thinking about migrating the bugs of the
 Shadow DOM spec,
  from the bugzilla [2], to the GitHub issues [3], as some of
 other specs are
  already doing so.
 
  As an experiment, I've just migrated the existing open bugs
 on the
  bugzilla to the GitHub issues, by a tiny script I've
 written using GitHub
  APIs.
 
  Unless there is an objection to the migration, I am going
 to close the
  existing open Shadow DOM spec bugs on the bugzilla, with a
 link to the
  corresponding bug on the GitHub issues.
 
  Please let me know if you have a concern.
 
  [1] https://github.com/w3c/webcomponents/commits/gh-pages
  [2]
 https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978
  [3] https://github.com/w3c/webcomponents/issues
 
 
 
 

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

[Xiaoqian Wu]

Hi Hayato, 

public-webapps has been removed from the default CC list of ‘Component Model’. 
Please let us know when you finish migrating and we will recover this component 
ASAP.

Thanks.

—
xiaoqian

 On 29 Jun, 2015, at 10:42 pm, Arthur Barstow art.bars...@gmail.com wrote:
 
 Yves, Xiaoqian, Mike - would one of you please do as Hayato requests below 
 (and then notify him so he can move the Custom Elements bugs to Github)?
 
 -Thanks, ArtB
 
 On 6/25/15 2:49 AM, Hayato Ito wrote:
 I am thinking about migrating Custom Element bugs[1] to Web Components 
 GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the 
 consistency.
 
 Could someone turn off the automatic email to public-webapps for Custom 
 Elements Bugs in the bugzilla so that we won't receive the mass flood of 
 bugspam by marking the all bugs MOVED? I'm assuming the automatic email is 
 on for public-webapps@.
 
 If you have any concerns about migrating, let me know that.
 
 [1] 
 https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968hide_resolved=1
 [2] https://github.com/w3c/webcomponents/issues
 
 On Thu, May 28, 2015 at 10:35 AM Hayato Ito hay...@google.com 
 mailto:hay...@google.com wrote:
 
I totally agree. I'm really sorry for spamming. I forgot that
closing a bug would trigger sending a mail to public-webapps@. My bad.
 
I thought that a closing bug would notify only people who opted-in
to add themselves to a list of cc in each bug. That might be a
good opportunity for them to keep tracking of the bug status by
subscribing a migrated bug on GitHub Issues.
 
On Thu, May 28, 2015 at 6:49 AM Tab Atkins Jr.
jackalm...@gmail.com mailto:jackalm...@gmail.com wrote:
 
Note for the future (to you and editors of other specs in
WebApps):
 
Before doing this kind of mass bug editting, please turn off the
automatic email to public-webapps.  If you can't do that yourself,
Mike Smith can (at least, he's done it in the past).  That
prevents
the mass flood of bugspam from clogging up people's inboxes. ^_^
 
~TJ
 
On Tue, May 26, 2015 at 8:30 PM, Hayato Ito hay...@google.com
mailto:hay...@google.com wrote:
 PSA: I've finished the migration. All open bugs are now
marked as MOVED
 with a link to the corresponding GitHub issue.

 On Mon, May 25, 2015 at 5:58 PM Hayato Ito
hay...@google.com mailto:hay...@google.com wrote:

 Regarding with the Shadow DOM spec, more and more workflows
are happening
 [1] on GitHub w3c/webcomponents repository recently.
 Therefore, I am thinking about migrating the bugs of the
Shadow DOM spec,
 from the bugzilla [2], to the GitHub issues [3], as some of
other specs are
 already doing so.

 As an experiment, I've just migrated the existing open bugs
on the
 bugzilla to the GitHub issues, by a tiny script I've
written using GitHub
 APIs.

 Unless there is an objection to the migration, I am going
to close the
 existing open Shadow DOM spec bugs on the bugzilla, with a
link to the
 corresponding bug on the GitHub issues.

 Please let me know if you have a concern.

 [1] https://github.com/w3c/webcomponents/commits/gh-pages
 [2]
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978
 [3] https://github.com/w3c/webcomponents/issues


 
 

[admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

[Arthur Barstow]

Yves, Xiaoqian, Mike - would one of you please do as Hayato requests 
below (and then notify him so he can move the Custom Elements bugs to 
Github)?


-Thanks, ArtB

On 6/25/15 2:49 AM, Hayato Ito wrote:
I am thinking about migrating Custom Element bugs[1] to Web Components 
GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the 
consistency.


Could someone turn off the automatic email to public-webapps for 
Custom Elements Bugs in the bugzilla so that we won't receive the mass 
flood of bugspam by marking the all bugs MOVED? I'm assuming the 
automatic email is on for public-webapps@.


If you have any concerns about migrating, let me know that.

[1] 
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968hide_resolved=1

[2] https://github.com/w3c/webcomponents/issues

On Thu, May 28, 2015 at 10:35 AM Hayato Ito hay...@google.com 
mailto:hay...@google.com wrote:


I totally agree. I'm really sorry for spamming. I forgot that
closing a bug would trigger sending a mail to public-webapps@. My bad.

I thought that a closing bug would notify only people who opted-in
to add themselves to a list of cc in each bug. That might be a
good opportunity for them to keep tracking of the bug status by
subscribing a migrated bug on GitHub Issues.

On Thu, May 28, 2015 at 6:49 AM Tab Atkins Jr.
jackalm...@gmail.com mailto:jackalm...@gmail.com wrote:

Note for the future (to you and editors of other specs in
WebApps):

Before doing this kind of mass bug editting, please turn off the
automatic email to public-webapps.  If you can't do that yourself,
Mike Smith can (at least, he's done it in the past).  That
prevents
the mass flood of bugspam from clogging up people's inboxes. ^_^

~TJ

On Tue, May 26, 2015 at 8:30 PM, Hayato Ito hay...@google.com
mailto:hay...@google.com wrote:
 PSA: I've finished the migration. All open bugs are now
marked as MOVED
 with a link to the corresponding GitHub issue.

 On Mon, May 25, 2015 at 5:58 PM Hayato Ito
hay...@google.com mailto:hay...@google.com wrote:

 Regarding with the Shadow DOM spec, more and more workflows
are happening
 [1] on GitHub w3c/webcomponents repository recently.
 Therefore, I am thinking about migrating the bugs of the
Shadow DOM spec,
 from the bugzilla [2], to the GitHub issues [3], as some of
other specs are
 already doing so.

 As an experiment, I've just migrated the existing open bugs
on the
 bugzilla to the GitHub issues, by a tiny script I've
written using GitHub
 APIs.

 Unless there is an objection to the migration, I am going
to close the
 existing open Shadow DOM spec bugs on the bugzilla, with a
link to the
 corresponding bug on the GitHub issues.

 Please let me know if you have a concern.

 [1] https://github.com/w3c/webcomponents/commits/gh-pages
 [2]
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978
 [3] https://github.com/w3c/webcomponents/issues

Re: Custom Elements: is=

[Mark Giffin]

On 6/12/2015 11:19 PM, Anne van Kesteren wrote:

On Fri, Jun 12, 2015 at 7:41 PM, Léonie Watson
lwat...@paciellogroup.com wrote:

Is there a succinct explanation of why the is= syntax is disliked?

Rather than

   button is=my-button/button

you want

   my-button/my-button

that just gets all the button goodness through composition/inheritance.


When I first learned about web components, the biggest disappointment 
for me was learning that if I wanted to base my new custom element on a 
native element like button, I could no longer have a custom tag name. 
So instead of having my-button, I had to use the funky and awkward 
button is=my-button. I realize there are good reasons for this, but 
it's very disappointing because it broke my idea of custom elements. I 
created a pull request for this in the Drawbacks section of the summary doc.


Mark

Re: Custom Elements: is=

[Erik Isaksen]

I agree with Anne. A stopgap could hinder cross browser development
significantly (with regards to backwards compatibility  browser needs of
clients). Does it gain enough for us to justify one? I am just joining the
conversation now so please correct me if I missed something on 'is'.

As far as naming goes, an 'extends' attribute with a prototype path seems
to be the most intuitive for me. Using element names in the naming
conventions to define inheritance is limiting. Eventually we would want to
be able to support extending other custom elements (whether this happens in
v1 or v2).

Custom elements can have long names. For the most part I have seen elements
with 2-3 hyphenated words but it is possible to have elements that are like
'crazy-long-awesome-button-thing' so extending this without an attribute
reference might look like
'crazy-long-awesome-button-thing-my-fabulous-button' where
'my-fabulous-button' is the new element namespace. Although this is a
problem with 'is' or 'extends' as well, it is more intuitive to have some
attribute reference to denote a change rather than a a long concatenated
element name. On a side note, developers suck at naming generally speaking.


On Mon, Jun 15, 2015 at 5:07 AM, Léonie Watson lwat...@paciellogroup.com
wrote:

 From: Bruce Lawson [mailto:bru...@opera.com]
 Sent: 15 June 2015 09:46

 On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote:
  it makes more sense to work on stylability of standard elements.

 I'd like to keep the is= construct (or better name) in the knowledge
 that it's a stopgap for v1, and put our energies we're currently expending
 debating this into styling standard elements - which is currently being
 considered http://dev.w3.org/csswg/css-forms/

 Will leaving is= (or whatever we call it) in situ create backward
 compatibility problems later on if/when it changes?

 That aside, concentrating efforts on styling native HTML elements makes a
 lot of sense.


 Léonie

 --
 Léonie Watson - Senior accessibility engineer
 @LeonieWatson @PacielloGroup PacielloGroup.com







-- 



*Erik Isaksen *


*Google Developer Expert HTML5
https://developers.google.com/experts/people/erik-isaksen*

*The Web Platform Podcast http://thewebplatform.libsyn.com/ Show Host*

*ReadTheSource.io http://ReadTheSource.io Co-Host*


*nevra...@gmail.com nevra...@gmail.com*
*@eisaksen https://twitter.com/eisaksen   *

*The Web Platform Podcast Links*

Twitter - https://twitter.com/thewebplatform

Google Plus - https://plus.google.com/u/0/106965203807974584370

Stream/Web -http://thewebplatform.libsyn.com/

Facebook - https://www.facebook.com/thewebplatform

iTunes -
https://itunes.apple.com/us/podcast/the-web-platform-podcast/id899384794?mt=2

Stitcher - http://www.stitcher.com/podcast/the-web-platform-podcast

YouTube (not all episodes available)  -
https://www.youtube.com/channel/UCjz3j22CyBpy6Qk5SL6UwcQ

RSS - http://thewebplatform.libsyn.com/rss

Github - https://github.com/thewebplatform


*Read The Source: Open Source Companion Live Screencast*

Twitter - http://hangouts.readthesource.io/

Google Plus - https://plus.google.com/105627089988168968277/

Youtube - https://www.youtube.com/channel/UCVqD-Rd1nMmvbvf-AvQvgZw

Github - https://github.com/readthesource

RSS - http://hangouts.readthesource.io/index.xml

Re: Custom Elements: is=

[Anne van Kesteren]

On Mon, Jun 15, 2015 at 10:45 AM, Bruce Lawson bru...@opera.com wrote:
 On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote:
 it makes more sense to work on stylability of standard elements.

 I'd like to keep the is= construct (or better name) in the knowledge
 that it's a stopgap for v1, and put our energies we're currently
 expending debating this into styling standard elements - which is
 currently being considered http://dev.w3.org/csswg/css-forms/

Why should we standardize a stopgap?


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=

[Bruce Lawson]

On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote:
 it makes more sense to work on stylability of standard elements.

I'd like to keep the is= construct (or better name) in the knowledge
that it's a stopgap for v1, and put our energies we're currently
expending debating this into styling standard elements - which is
currently being considered http://dev.w3.org/csswg/css-forms/

b

RE: Custom Elements: is=

[Léonie Watson]

From: Bruce Lawson [mailto:bru...@opera.com] 
Sent: 15 June 2015 09:46

On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote:
 it makes more sense to work on stylability of standard elements.

I'd like to keep the is= construct (or better name) in the knowledge that 
it's a stopgap for v1, and put our energies we're currently expending debating 
this into styling standard elements - which is currently being considered 
http://dev.w3.org/csswg/css-forms/

Will leaving is= (or whatever we call it) in situ create backward compatibility 
problems later on if/when it changes? 

That aside, concentrating efforts on styling native HTML elements makes a lot 
of sense.


Léonie

-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

Re: Custom Elements: is=

[Tobie Langel]

On Sat, Jun 13, 2015, at 18:52, Alice Boxhall wrote:
 Doc in progress at
 https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Type-Extensions.md

Sent a pull request your way[1].

--tobie

---
[1]: https://github.com/w3c/webcomponents/pull/117

Re: Custom Elements: is=

[Patrick H. Lauke]

On 13/06/2015 16:33, Bruce Lawson wrote:

On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote:

why not use the extends= syntax you mentioned?

my-button extends=button attributesPush/my-button


because browsers that don't know about web components wouldn't pay any
attention to my-button, and render Push as plain text.

  Browsers that don't know about web components will fall back to
button with button
this-is-made-much-more-marvellous-by=my-button (or whatever)


However, this fallback will only really be useful for very simple cases, 
where web components have been used to jazz up what essentially is still 
the element that was extended. And, I would posit, any scripting that 
was done to act on the all-singing, all-dancing new web component button 
(if it does anything more than a regular button) would not work for the 
fallback. Unless it's really just using web components for fancy styling 
(for instance having a material design button that essentially still 
works just like a button) - in which case, it makes more sense to work 
on stylability of standard elements.


P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

RE: Custom Elements: is=

[Léonie Watson]

From: Bruce Lawson [mailto:bru...@opera.com] 
Sent: 13 June 2015 16:34

On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote:
 why not use the extends= syntax you mentioned?

 my-button extends=button attributesPush/my-button

because browsers that don't know about web components wouldn't pay any 
attention to my-button, and render Push as plain text.

Of course! I should have thought of that.

Léonie.


-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

RE: Custom Elements: is=

[Léonie Watson]

From: Tobie Langel [mailto:to...@codespeaks.com] 
Sent: 12 June 2015 21:26

On Fri, Jun 12, 2015, at 19:41, Léonie Watson wrote:
 Is there a succinct explanation of why the is= syntax is disliked? The 
 info on the WHATWG wiki explains where is= breaks, but doesn’t offer 
 much on the syntax issue [1].

[...]

So in summary it's ugly, has a high cognitive load, doesn't express the 
developers intent (actually even expresses the opposite), is hard to spot when 
reading code, and is error prone.

Hope this helps. :)

It does, thank you.

At the risk of asking the obvious question, why not use the extends= syntax you 
mentioned?

my-button extends=button attributesPush/my-button

It follows the expected X extends Y convention, and makes it reasonably clear 
what the attributes have been applied to I think.

Léonie.

RE: Custom Elements: is=

[Léonie Watson]

From: Bruce Lawson [mailto:bru...@opera.com] 
Sent: 13 June 2015 14:57
Subject: Re: Custom Elements: is=

On 12 June 2015 at 21:26, Tobie Langel to...@codespeaks.com wrote:
 I'm also concerned developers will mistakenly write:

 my-button is=button

 As it is much closer in form to what they want to achieve (see the 
 extend=parent syntax I wrote earlier).

That's true (and I've done exactly this myself). But wouldn't

button extendedby=my-button

solve that?

I think the problem with this would be that it still turns the expected X 
extends Y convention on its head? It also appears as though the attributes 
relate to button rather than the element indicated in the extendedby= 
attribute.

Léonie.

-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

Re: Custom Elements: is=

[Bruce Lawson]

On 12 June 2015 at 21:26, Tobie Langel to...@codespeaks.com wrote:
 I'm also concerned developers will mistakenly write:

 my-button is=button

 As it is much closer in form to what they want to achieve (see the
 extend=parent syntax I wrote earlier).

That's true (and I've done exactly this myself). But wouldn't

button extendedby=my-button

solve that?

b

Re: Custom Elements: is=

[Anne van Kesteren]

On Fri, Jun 12, 2015 at 7:41 PM, Léonie Watson
lwat...@paciellogroup.com wrote:
 Is there a succinct explanation of why the is= syntax is disliked?

Rather than

  button is=my-button/button

you want

  my-button/my-button

that just gets all the button goodness through composition/inheritance.


Also the fact that you need form is=my-form to be able to submit
custom elements is something we should fix in the design of form.
That is= can make certain hacks a little simpler is nice, but that's
not enough to justify standardizing it. I have the feeling we're going
in circles though, since the arguments on both sides have been made
repeatedly for the past x years.


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=

[Dimitri Glazkov]

Folks,

I agree with Anne that we've been having a somewhat circular re-discovery
of the pros/cons here. I believe that the best way to address this is to
capture all of these points in one doc -- this would be a just a little
extra work for the current participants, but super awesome for the future
folk.

For example, Domenic started such a doc for another custom elements
contentious bit:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md.
Please help break the cycle of re-discovery :)

:DG

Re: Custom Elements: is=

[Bruce Lawson]

On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote:
 why not use the extends= syntax you mentioned?

 my-button extends=button attributesPush/my-button

because browsers that don't know about web components wouldn't pay any
attention to my-button, and render Push as plain text.

 Browsers that don't know about web components will fall back to
button with button
this-is-made-much-more-marvellous-by=my-button (or whatever)

b

Re: Custom Elements: is=

[Alice Boxhall]

Doc in progress at
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Type-Extensions.md

On Sat, Jun 13, 2015 at 8:50 AM, Dimitri Glazkov dglaz...@google.com
wrote:

 Folks,

 I agree with Anne that we've been having a somewhat circular re-discovery
 of the pros/cons here. I believe that the best way to address this is to
 capture all of these points in one doc -- this would be a just a little
 extra work for the current participants, but super awesome for the future
 folk.

 For example, Domenic started such a doc for another custom elements
 contentious bit:
 https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md.
 Please help break the cycle of re-discovery :)

 :DG

Re: Custom Elements: is=

[Tobie Langel]

On Fri, Jun 12, 2015, at 19:41, Léonie Watson wrote:
 Is there a succinct explanation of why the is= syntax is disliked? The
 info on the WHATWG wiki explains where is= breaks, but doesn’t offer much
 on the syntax issue [1].

Esthetics aside, the main issue it is takes the concept of inheritance
developers are familiar with and stands it on its head.

The idea with inheritance is that you build a new object and it happens
to inherit from another one, so for example:

my-button extends=button

makes a lot of sense. Clearly, you're building a new element that
extends the capabilities of the existing button object. With the is=
syntax, however, what it is you're doing isn't clear at all:

button is=my-button

What's the message here? Oh this is just a button. Oh wait no it's not,
it's a my-button. But does it actually inherit from button? Mmm. Not
clear from the syntax. 

Further more, what about when you add a bunch of extra attributes in
there:

button value=45 class=button button-large is=my-button
id=cta /

It becomes hard to spot that this element isn't actually a traditional
button. Things get easily lost when scanning code. 

I'm also concerned developers will mistakenly write:

my-button is=button

As it is much closer in form to what they want to achieve (see the
extend=parent syntax I wrote earlier).

So in summary it's ugly, has a high cognitive load, doesn't express the
developers intent (actually even expresses the opposite), is hard to
spot when reading code, and is error prone.

Hope this helps. :)

--tobie

Re: Custom Elements: is=

[Justin Fagnani]

We also have an extension of form which collects values from both native
and custom inputs.

On Thu, Jun 11, 2015 at 1:41 PM, Joshua Peek j...@joshpeek.com wrote:

 GitHub has been using tag extensions in a few places for progressive
 enhancement. Form and button elements have been the most useful things
 to extend the behavior of. is= syntax aside, I do agree extending
 complex native element prototypes in general has alot of associated
 undefined behavior. If is= is going to be dropped, we'll probably
 revert back to annotating these elements with special class names or
 data- attributes and avoid custom elements for these use cases.

 On Tue, Jun 9, 2015 at 9:05 AM, Alice Boxhall aboxh...@google.com wrote:
 
  On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl
 wrote:
 
  On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com
  wrote:
   - In the time between v1 and v2 (however long that ends up being) we
 are
   left without any way to solve this problem, assuming we don't come up
   with
   something else for v1. If developers start using custom elements where
   they
   would previously have used a native element, this could well result
 in a
   regression in accessibility for the web as a whole for this period,
 and
   we
   will be stuck with the legacy of code written during this period for
   much
   longer as well.
 
  I don't see how it is a regression compared to the current situation.
 
 
  Exactly: this describes the current situation, which I think is
  unsatisfactory.
 
   - I realise that to some extent developers already aren't using native
   elements, in part because of the styling issues we've discussed which
   also
   affect is=. My concern here is that custom elements will further
   legitimise
   this habit, which we've been making some recent progress in changing -
   we
   stand to backslide on that effort. Having is= would allow us to roll
 it
   into
   the use native elements where possible message rather than diluting
 it
   with unless you're using a custom element in which case here's a
   checklist
   which you're not going to look at of everything it should do until we
   come
   up with an alternative.
 
  Most examples of custom elements to date are not actually with is=,
  simply because custom tag names are much more appealing. The
  ergonomics don't back up the message.
 
 
  Polymer have a whole suite of elements which use is=:
  https://elements.polymer-project.org/browse?package=gold-elements
 
  When you refer to ergonomics, are you talking purely about the syntax?
 Or
  about the set of issues involved in using native elements compared to
 (lower
  case c) custom elements: essentially, whether or not you're ceding some
  control over styling and behaviour to the browser?
 
   - v1 sets the stage for people to develop habits and expectations
 about
   how
   custom elements work. New features tend to be slowly adopted, by both
   browser vendors and (partly as a consequence) developers, so even if
 we
   do
   come up with something for v2, it will be even longer before it
 becomes
   mainstream (and as I mentioned earlier we will still be stuck with
 code
   written to v1 for much longer again).
 
  I don't see how it will be longer. is= is not getting acceptance
  as-is. So all this would result in is not getting custom elements
  across browsers until v2 is done.
 
 
  I think Dimitri responded to this better than I could.
 
 
   Here's where we differ, because:
   - I don't think it's a wart. I've given this a great deal of thought
 and
   I
   keep ending up back at the current syntax when I try to think of
   reasonable
   alternatives, even assuming we could magically fix all the
   implementation
   issues with any alternative proposal.
 
  I think if we figured out how the behavior of current elements is
  composed and how to address the styling problem we'd be much closer to
  an agreement. And I think everyone agrees those need to be solved, so
  I'm a bit lost as to why we don't focus on those.
 
 
  I agree that those problems need to be solved (in particular, the styling
  issue also comes into play when using is=), but I think that these are
  multiple pieces of the same puzzle.
 
  The primitives are critical for creating novel types of elements, which
  won't be able to benefit from type extensions in any case. Styling is
  critical for getting people to use native elements with or without type
  extensions.
 
  Allowing developers to extend native types means that users benefit from
 not
  relying on custom element developers who just want to create a button
 with
  some fancy rendering (beyond what can be achieved using CSS alone), or
  custom behaviour, remembering to re-implement all of the accessibility
  affordances which are built in to an HTML button. It also means that
  developers benefit from not having to do the extra legwork for
  accessibility.
 
  We see time after time after time that accessibility 

RE: Custom Elements: is=

[Léonie Watson]

Is there a succinct explanation of why the is= syntax is disliked? The info on 
the WHATWG wiki explains where is= breaks, but doesn’t offer much on the syntax 
issue [1].

 

Léonie.

[1] https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements 

 

-- 

Léonie Watson - Senior accessibility engineer

@LeonieWatson @PacielloGroup PacielloGroup.com

 

 

 

Re: Custom Elements: is=

[Joshua Peek]

GitHub has been using tag extensions in a few places for progressive
enhancement. Form and button elements have been the most useful things
to extend the behavior of. is= syntax aside, I do agree extending
complex native element prototypes in general has alot of associated
undefined behavior. If is= is going to be dropped, we'll probably
revert back to annotating these elements with special class names or
data- attributes and avoid custom elements for these use cases.

On Tue, Jun 9, 2015 at 9:05 AM, Alice Boxhall aboxh...@google.com wrote:

 On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com
 wrote:
  - In the time between v1 and v2 (however long that ends up being) we are
  left without any way to solve this problem, assuming we don't come up
  with
  something else for v1. If developers start using custom elements where
  they
  would previously have used a native element, this could well result in a
  regression in accessibility for the web as a whole for this period, and
  we
  will be stuck with the legacy of code written during this period for
  much
  longer as well.

 I don't see how it is a regression compared to the current situation.


 Exactly: this describes the current situation, which I think is
 unsatisfactory.

  - I realise that to some extent developers already aren't using native
  elements, in part because of the styling issues we've discussed which
  also
  affect is=. My concern here is that custom elements will further
  legitimise
  this habit, which we've been making some recent progress in changing -
  we
  stand to backslide on that effort. Having is= would allow us to roll it
  into
  the use native elements where possible message rather than diluting it
  with unless you're using a custom element in which case here's a
  checklist
  which you're not going to look at of everything it should do until we
  come
  up with an alternative.

 Most examples of custom elements to date are not actually with is=,
 simply because custom tag names are much more appealing. The
 ergonomics don't back up the message.


 Polymer have a whole suite of elements which use is=:
 https://elements.polymer-project.org/browse?package=gold-elements

 When you refer to ergonomics, are you talking purely about the syntax? Or
 about the set of issues involved in using native elements compared to (lower
 case c) custom elements: essentially, whether or not you're ceding some
 control over styling and behaviour to the browser?

  - v1 sets the stage for people to develop habits and expectations about
  how
  custom elements work. New features tend to be slowly adopted, by both
  browser vendors and (partly as a consequence) developers, so even if we
  do
  come up with something for v2, it will be even longer before it becomes
  mainstream (and as I mentioned earlier we will still be stuck with code
  written to v1 for much longer again).

 I don't see how it will be longer. is= is not getting acceptance
 as-is. So all this would result in is not getting custom elements
 across browsers until v2 is done.


 I think Dimitri responded to this better than I could.


  Here's where we differ, because:
  - I don't think it's a wart. I've given this a great deal of thought and
  I
  keep ending up back at the current syntax when I try to think of
  reasonable
  alternatives, even assuming we could magically fix all the
  implementation
  issues with any alternative proposal.

 I think if we figured out how the behavior of current elements is
 composed and how to address the styling problem we'd be much closer to
 an agreement. And I think everyone agrees those need to be solved, so
 I'm a bit lost as to why we don't focus on those.


 I agree that those problems need to be solved (in particular, the styling
 issue also comes into play when using is=), but I think that these are
 multiple pieces of the same puzzle.

 The primitives are critical for creating novel types of elements, which
 won't be able to benefit from type extensions in any case. Styling is
 critical for getting people to use native elements with or without type
 extensions.

 Allowing developers to extend native types means that users benefit from not
 relying on custom element developers who just want to create a button with
 some fancy rendering (beyond what can be achieved using CSS alone), or
 custom behaviour, remembering to re-implement all of the accessibility
 affordances which are built in to an HTML button. It also means that
 developers benefit from not having to do the extra legwork for
 accessibility.

 We see time after time after time that accessibility is fighting an uphill
 battle because it isn't on developers' radars as a priority for v1. This
 causes constant regressions in functionality for people who rely on
 assistive technology. The promise of the HTML platform is that it should be
 accessible if we use the native elements as 

Re: Custom Elements: is=

[Anne van Kesteren]

On Mon, Jun 8, 2015 at 11:48 PM, Justin Fagnani
justinfagn...@google.com wrote:
 And I'm still concerned that removing is= would severely harm the cases
 where you need access to special parsing behavior like template and
 style.

With synchronous constructors you could imagine setting the parsing
policy in the constructor (as `this[Element.parsingPolicy] = x` or
some such). I wouldn't want to do that for v1, but it opens up that
possibility of making the HTML parser hackable.


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=

[Dimitri Glazkov]

On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote:


  - v1 sets the stage for people to develop habits and expectations about
 how
  custom elements work. New features tend to be slowly adopted, by both
  browser vendors and (partly as a consequence) developers, so even if we
 do
  come up with something for v2, it will be even longer before it becomes
  mainstream (and as I mentioned earlier we will still be stuck with code
  written to v1 for much longer again).

 I don't see how it will be longer. is= is not getting acceptance
 as-is. So all this would result in is not getting custom elements
 across browsers until v2 is done.


I sort of assumes that the reason for this discussion is to get everyone on
the same page regarding type extension and hope to arrive at better
acceptance.

Arguing that something isn't getting acceptance when the purpose of
discussion is attempting to gain the said acceptance seems a bit circular.

Other than that, please do continue this conversation! :)

:DG

Re: Custom Elements: is=

[Anne van Kesteren]

On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com wrote:
 - In the time between v1 and v2 (however long that ends up being) we are
 left without any way to solve this problem, assuming we don't come up with
 something else for v1. If developers start using custom elements where they
 would previously have used a native element, this could well result in a
 regression in accessibility for the web as a whole for this period, and we
 will be stuck with the legacy of code written during this period for much
 longer as well.

I don't see how it is a regression compared to the current situation.


 - I realise that to some extent developers already aren't using native
 elements, in part because of the styling issues we've discussed which also
 affect is=. My concern here is that custom elements will further legitimise
 this habit, which we've been making some recent progress in changing - we
 stand to backslide on that effort. Having is= would allow us to roll it into
 the use native elements where possible message rather than diluting it
 with unless you're using a custom element in which case here's a checklist
 which you're not going to look at of everything it should do until we come
 up with an alternative.

Most examples of custom elements to date are not actually with is=,
simply because custom tag names are much more appealing. The
ergonomics don't back up the message.


 - v1 sets the stage for people to develop habits and expectations about how
 custom elements work. New features tend to be slowly adopted, by both
 browser vendors and (partly as a consequence) developers, so even if we do
 come up with something for v2, it will be even longer before it becomes
 mainstream (and as I mentioned earlier we will still be stuck with code
 written to v1 for much longer again).

I don't see how it will be longer. is= is not getting acceptance
as-is. So all this would result in is not getting custom elements
across browsers until v2 is done.


 Here's where we differ, because:
 - I don't think it's a wart. I've given this a great deal of thought and I
 keep ending up back at the current syntax when I try to think of reasonable
 alternatives, even assuming we could magically fix all the implementation
 issues with any alternative proposal.

I think if we figured out how the behavior of current elements is
composed and how to address the styling problem we'd be much closer to
an agreement. And I think everyone agrees those need to be solved, so
I'm a bit lost as to why we don't focus on those.


 - I don't think shipping in one browser is nothing. People (both framework
 authors and web page authors) are already writing code using is=.

Well, I disagree. E.g. Microsoft had a ton of features shipping in
Internet Explorer 5.0 that were used and never ended up as-is (or at
all) in other browsers. In the long run it's pretty close to
nothing.


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=

[Justin Fagnani]

On Jun 9, 2015 8:45 AM, Dimitri Glazkov dglaz...@google.com wrote:

 On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl
wrote:


  - v1 sets the stage for people to develop habits and expectations
about how
  custom elements work. New features tend to be slowly adopted, by both
  browser vendors and (partly as a consequence) developers, so even if
we do
  come up with something for v2, it will be even longer before it becomes
  mainstream (and as I mentioned earlier we will still be stuck with code
  written to v1 for much longer again).

 I don't see how it will be longer. is= is not getting acceptance
 as-is. So all this would result in is not getting custom elements
 across browsers until v2 is done.


 I sort of assumes that the reason for this discussion is to get everyone
on the same page regarding type extension and hope to arrive at better
acceptance.

 Arguing that something isn't getting acceptance when the purpose of
discussion is attempting to gain the said acceptance seems a bit circular.

 Other than that, please do continue this conversation! :)

I'll also note that a large fraction of Polymer elements and Polymer using
pages, thus a large fraction of existing custom elements and use, uses is=,
via template is=dom-repeat / dom-if / dom-bind and style
is=custom-style. So as far as current custom elements are concerned, is=
is accepted.


 :DG

Re: Custom Elements: is=

[Alice Boxhall]

On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com
 wrote:
  - In the time between v1 and v2 (however long that ends up being) we are
  left without any way to solve this problem, assuming we don't come up
 with
  something else for v1. If developers start using custom elements where
 they
  would previously have used a native element, this could well result in a
  regression in accessibility for the web as a whole for this period, and
 we
  will be stuck with the legacy of code written during this period for much
  longer as well.

 I don't see how it is a regression compared to the current situation.


Exactly: this describes the current situation, which I think is
unsatisfactory.

 - I realise that to some extent developers already aren't using native
  elements, in part because of the styling issues we've discussed which
 also
  affect is=. My concern here is that custom elements will further
 legitimise
  this habit, which we've been making some recent progress in changing - we
  stand to backslide on that effort. Having is= would allow us to roll it
 into
  the use native elements where possible message rather than diluting it
  with unless you're using a custom element in which case here's a
 checklist
  which you're not going to look at of everything it should do until we
 come
  up with an alternative.

 Most examples of custom elements to date are not actually with is=,
 simply because custom tag names are much more appealing. The
 ergonomics don't back up the message.


Polymer have a whole suite of elements which use is=:
https://elements.polymer-project.org/browse?package=gold-elements

When you refer to ergonomics, are you talking purely about the syntax? Or
about the set of issues involved in using native elements compared to
(lower case c) custom elements: essentially, whether or not you're ceding
some control over styling and behaviour to the browser?

 - v1 sets the stage for people to develop habits and expectations about
 how
  custom elements work. New features tend to be slowly adopted, by both
  browser vendors and (partly as a consequence) developers, so even if we
 do
  come up with something for v2, it will be even longer before it becomes
  mainstream (and as I mentioned earlier we will still be stuck with code
  written to v1 for much longer again).

 I don't see how it will be longer. is= is not getting acceptance
 as-is. So all this would result in is not getting custom elements
 across browsers until v2 is done.


I think Dimitri responded to this better than I could.


  Here's where we differ, because:
  - I don't think it's a wart. I've given this a great deal of thought and
 I
  keep ending up back at the current syntax when I try to think of
 reasonable
  alternatives, even assuming we could magically fix all the implementation
  issues with any alternative proposal.

 I think if we figured out how the behavior of current elements is
 composed and how to address the styling problem we'd be much closer to
 an agreement. And I think everyone agrees those need to be solved, so
 I'm a bit lost as to why we don't focus on those.


I agree that those problems need to be solved (in particular, the styling
issue also comes into play when using is=), but I think that these are
multiple pieces of the same puzzle.

The primitives are critical for creating novel types of elements, which
won't be able to benefit from type extensions in any case. Styling is
critical for getting people to use native elements with or without type
extensions.

Allowing developers to extend native types means that *users* benefit from
not relying on custom element developers who just want to create a button
with some fancy rendering (beyond what can be achieved using CSS alone), or
custom behaviour, remembering to re-implement all of the accessibility
affordances which are built in to an HTML button. It also means that
*developers* benefit from not having to do the extra legwork for
accessibility.

We see time after time after time that accessibility is fighting an uphill
battle because it isn't on developers' radars as a priority for v1. This
causes constant regressions in functionality for people who rely on
assistive technology. The promise of the HTML platform is that it should be
accessible if we use the native elements as they were designed to be used.
Part of my day job is helping make sure that the browser I work on upholds
its part of that bargain.

You could argue that what we need is a way to wrap *all* of the
accessibility affordances of a button into a mix-in object; I really don't
see a much more efficient way to do that than extending a button element,
either in terms of creating the spec or in terms of using the object.

 - I don't think shipping in one browser is nothing. People (both
 framework
  authors and web page authors) are already writing code using is=.

 Well, I disagree. E.g. Microsoft 

Re: Custom Elements: is=

[Alice Boxhall]

Did anyone have any further thoughts on this? My concerns haven't changed.

On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com wrote:

 On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com
 wrote:
  I definitely acknowledge is= may not be the ideal solution to the latter
  problem - it definitely has some holes in it, especially when you start
  adding author shadow roots to things - but I think it does have
 potential.
  I'd really like to be convinced that we either have a reasonable
 alternative
  solution, or that it's not worth worrying about.

 I think it is worth worrying about, but I don't think it's worth
 holding up a minimal v1 of Custom Elements for. The way to get
 agreement among all parties is to do less. And then take baby steps
 from.


 I can definitely see that logic.

 My concerns with this in practice are:

 - In the time between v1 and v2 (however long that ends up being) we are
 left without any way to solve this problem, assuming we don't come up with
 something else for v1. If developers start using custom elements where they
 would previously have used a native element, this could well result in a
 regression in accessibility for the web as a whole for this period, and we
 will be stuck with the legacy of code written during this period for much
 longer as well.

 - I realise that to some extent developers already aren't using native
 elements, in part because of the styling issues we've discussed which also
 affect is=. My concern here is that custom elements will further legitimise
 this habit, which we've been making some recent progress in changing - we
 stand to backslide on that effort. Having is= would allow us to roll it
 into the use native elements where possible message rather than diluting
 it with unless you're using a custom element in which case here's a
 checklist which you're not going to look at of everything it should do
 until we come up with an alternative.

 - v1 sets the stage for people to develop habits and expectations about
 how custom elements work. New features tend to be slowly adopted, by both
 browser vendors and (partly as a consequence) developers, so even if we do
 come up with something for v2, it will be even longer before it becomes
 mainstream (and as I mentioned earlier we will still be stuck with code
 written to v1 for much longer again).


 The way I look at this is that currently you have nothing, since only
 Chrome ships this. There's a chance to get three more browsers if you
 make some concessions on the warts. And then hopefully we can iterate
 from there in a more cooperative fashion.


 Here's where we differ, because:
 - I don't think it's a wart. I've given this a great deal of thought and I
 keep ending up back at the current syntax when I try to think of reasonable
 alternatives, even assuming we could magically fix all the implementation
 issues with any alternative proposal.
 - I don't think shipping in one browser is nothing. People (both
 framework authors and web page authors) are already writing code using is=.


 (The thread Steve shared about ARIA seemed like an equivalent effort
 by the way, to expose some of the semantics of native elements through
 simple attributes.)


 Thanks for the pointer - I followed up on that thread with some thoughts
 on that proposal.

Re: Custom Elements: is=

[Alice Boxhall]

On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:
 
  Did anyone have any further thoughts on this? My concerns haven't
 changed.

 Nothing new.

  On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com
 wrote:
  On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl
 wrote:
  On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com
 wrote:
   I definitely acknowledge is= may not be the ideal solution to the
 latter
   problem - it definitely has some holes in it, especially when you
 start
   adding author shadow roots to things - but I think it does have
 potential.
   I'd really like to be convinced that we either have a reasonable
 alternative
   solution, or that it's not worth worrying about.
 
  I think it is worth worrying about, but I don't think it's worth
  holding up a minimal v1 of Custom Elements for. The way to get
  agreement among all parties is to do less. And then take baby steps
  from.
 
  I can definitely see that logic.
 
  My concerns with this in practice are:
 
  - In the time between v1 and v2 (however long that ends up being) we
 are left without any way to solve this problem, assuming we don't come up
 with something else for v1. If developers start using custom elements where
 they would previously have used a native element, this could well result in
 a regression in accessibility for the web as a whole for this period, and
 we will be stuck with the legacy of code written during this period for
 much longer as well.

 Web developers are already writing their own custom elements as a bunch
 of nested div's.  How does introducing custom elements make it worse?


I believe the rest of my comment already addressed this.


 The argument that it'll make things worse between v1 and v2 is moot
 because we haven't agreed on anything. is= syntax may never be realized due
 to various issues associated with it.


This was in response to Anne's suggestion to take baby steps. If this is
going to happen at all, I believe it needs to happen in V1 rather than
later, for the reasons I outlined.


  - I realise that to some extent developers already aren't using native
 elements, in part because of the styling issues we've discussed which also
 affect is=. My concern here is that custom elements will further legitimise
 this habit, which we've been making some recent progress in changing - we
 stand to backslide on that effort. Having is= would allow us to roll it
 into the use native elements where possible message rather than diluting
 it with unless you're using a custom element in which case here's a
 checklist which you're not going to look at of everything it should do
 until we come up with an alternative.

 In the case of stylizing elements, it doesn't really matter if authors
 attach a shadow DOM on top of a builtin input element or to a div because
 as soon as the shadow DOM replaces the rendered contents, we can't make
 assumptions about how to expose that element to AT.


That's simply not true at all. If someone replaces the rendered content of
a `button`, we know that their intent is to create an element which is
semantically a button, and may even be rendered as a button in some cases.
Similarly for `input` with a `type` attribute. This is no different to
using an ARIA role as far as assistive technology is concerned.


  The way I look at this is that currently you have nothing, since only
  Chrome ships this. There's a chance to get three more browsers if you
  make some concessions on the warts. And then hopefully we can iterate
  from there in a more cooperative fashion.
 
  Here's where we differ, because:
  - I don't think it's a wart. I've given this a great deal of thought
 and I keep ending up back at the current syntax when I try to think of
 reasonable alternatives, even assuming we could magically fix all the
 implementation issues with any alternative proposal.

 FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly)
 spec'ed.


Any chance you could go into more detail on that? What exactly is it you
dislike about it?


  - I don't think shipping in one browser is nothing. People (both
 framework authors and web page authors) are already writing code using is=.

 Some developers are always going to use a feature only implemented by a
 single browser (ActiveX in Trident, NaCl in Chrome, current web components
 implementation in Chrome). In fact, why would any browser vendor ship a
 feature that's not going to be used by anyone? However, that doesn't mean
 the feature will be standardized or adopted by other browser vendors.


No, but unlike the first two examples, this is a proposed web standard.

Thanks,

Alice

Re: Custom Elements: is=

[Ryosuke Niwa]

 On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:
 
 Did anyone have any further thoughts on this? My concerns haven't changed.

Nothing new.

 On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com wrote:
 On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com wrote:
  I definitely acknowledge is= may not be the ideal solution to the latter
  problem - it definitely has some holes in it, especially when you start
  adding author shadow roots to things - but I think it does have potential.
  I'd really like to be convinced that we either have a reasonable 
  alternative
  solution, or that it's not worth worrying about.
 
 I think it is worth worrying about, but I don't think it's worth
 holding up a minimal v1 of Custom Elements for. The way to get
 agreement among all parties is to do less. And then take baby steps
 from.
 
 I can definitely see that logic.
 
 My concerns with this in practice are:
 
 - In the time between v1 and v2 (however long that ends up being) we are 
 left without any way to solve this problem, assuming we don't come up with 
 something else for v1. If developers start using custom elements where they 
 would previously have used a native element, this could well result in a 
 regression in accessibility for the web as a whole for this period, and we 
 will be stuck with the legacy of code written during this period for much 
 longer as well.

Web developers are already writing their own custom elements as a bunch of 
nested div's.  How does introducing custom elements make it worse?

The argument that it'll make things worse between v1 and v2 is moot because we 
haven't agreed on anything. is= syntax may never be realized due to various 
issues associated with it.

 - I realise that to some extent developers already aren't using native 
 elements, in part because of the styling issues we've discussed which also 
 affect is=. My concern here is that custom elements will further legitimise 
 this habit, which we've been making some recent progress in changing - we 
 stand to backslide on that effort. Having is= would allow us to roll it into 
 the use native elements where possible message rather than diluting it 
 with unless you're using a custom element in which case here's a checklist 
 which you're not going to look at of everything it should do until we come 
 up with an alternative.

In the case of stylizing elements, it doesn't really matter if authors attach a 
shadow DOM on top of a builtin input element or to a div because as soon as the 
shadow DOM replaces the rendered contents, we can't make assumptions about how 
to expose that element to AT.

 The way I look at this is that currently you have nothing, since only
 Chrome ships this. There's a chance to get three more browsers if you
 make some concessions on the warts. And then hopefully we can iterate
 from there in a more cooperative fashion.
 
 Here's where we differ, because:
 - I don't think it's a wart. I've given this a great deal of thought and I 
 keep ending up back at the current syntax when I try to think of reasonable 
 alternatives, even assuming we could magically fix all the implementation 
 issues with any alternative proposal.

FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly) 
spec'ed.

 - I don't think shipping in one browser is nothing. People (both framework 
 authors and web page authors) are already writing code using is=.

Some developers are always going to use a feature only implemented by a single 
browser (ActiveX in Trident, NaCl in Chrome, current web components 
implementation in Chrome). In fact, why would any browser vendor ship a feature 
that's not going to be used by anyone? However, that doesn't mean the feature 
will be standardized or adopted by other browser vendors.

- R. Niwa

Re: Custom Elements: is=

[Justin Fagnani]

And I'm still concerned that removing is= would severely harm the cases
where you need access to special parsing behavior like template and
style.

On Mon, Jun 8, 2015 at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:

 Did anyone have any further thoughts on this? My concerns haven't changed.

 On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com wrote:

 On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com
 wrote:
  I definitely acknowledge is= may not be the ideal solution to the
 latter
  problem - it definitely has some holes in it, especially when you start
  adding author shadow roots to things - but I think it does have
 potential.
  I'd really like to be convinced that we either have a reasonable
 alternative
  solution, or that it's not worth worrying about.

 I think it is worth worrying about, but I don't think it's worth
 holding up a minimal v1 of Custom Elements for. The way to get
 agreement among all parties is to do less. And then take baby steps
 from.


 I can definitely see that logic.

 My concerns with this in practice are:

 - In the time between v1 and v2 (however long that ends up being) we are
 left without any way to solve this problem, assuming we don't come up with
 something else for v1. If developers start using custom elements where they
 would previously have used a native element, this could well result in a
 regression in accessibility for the web as a whole for this period, and we
 will be stuck with the legacy of code written during this period for much
 longer as well.

 - I realise that to some extent developers already aren't using native
 elements, in part because of the styling issues we've discussed which also
 affect is=. My concern here is that custom elements will further legitimise
 this habit, which we've been making some recent progress in changing - we
 stand to backslide on that effort. Having is= would allow us to roll it
 into the use native elements where possible message rather than diluting
 it with unless you're using a custom element in which case here's a
 checklist which you're not going to look at of everything it should do
 until we come up with an alternative.

 - v1 sets the stage for people to develop habits and expectations about
 how custom elements work. New features tend to be slowly adopted, by both
 browser vendors and (partly as a consequence) developers, so even if we do
 come up with something for v2, it will be even longer before it becomes
 mainstream (and as I mentioned earlier we will still be stuck with code
 written to v1 for much longer again).


 The way I look at this is that currently you have nothing, since only
 Chrome ships this. There's a chance to get three more browsers if you
 make some concessions on the warts. And then hopefully we can iterate
 from there in a more cooperative fashion.


 Here's where we differ, because:
 - I don't think it's a wart. I've given this a great deal of thought and
 I keep ending up back at the current syntax when I try to think of
 reasonable alternatives, even assuming we could magically fix all the
 implementation issues with any alternative proposal.
 - I don't think shipping in one browser is nothing. People (both
 framework authors and web page authors) are already writing code using is=.


 (The thread Steve shared about ARIA seemed like an equivalent effort
 by the way, to expose some of the semantics of native elements through
 simple attributes.)


 Thanks for the pointer - I followed up on that thread with some thoughts
 on that proposal.

Re: Custom Elements: is=

[Ryosuke Niwa]

 On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote:
 
 On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com 
  mailto:aboxh...@google.com wrote:
 Web developers are already writing their own custom elements as a bunch of 
 nested div's.  How does introducing custom elements make it worse?
 
 I believe the rest of my comment already addressed this.

Sorry, I don't follow.

  - I realise that to some extent developers already aren't using native 
  elements, in part because of the styling issues we've discussed which 
  also affect is=. My concern here is that custom elements will further 
  legitimise this habit, which we've been making some recent progress in 
  changing - we stand to backslide on that effort. Having is= would allow 
  us to roll it into the use native elements where possible message 
  rather than diluting it with unless you're using a custom element in 
  which case here's a checklist which you're not going to look at of 
  everything it should do until we come up with an alternative.
 
 In the case of stylizing elements, it doesn't really matter if authors 
 attach a shadow DOM on top of a builtin input element or to a div because as 
 soon as the shadow DOM replaces the rendered contents, we can't make 
 assumptions about how to expose that element to AT.
 
 That's simply not true at all. If someone replaces the rendered content of a 
 `button`, we know that their intent is to create an element which is 
 semantically a button, and may even be rendered as a button in some cases. 
 Similarly for `input` with a `type` attribute. This is no different to 
 using an ARIA role as far as assistive technology is concerned.

Perhaps I should have said we can't _always_ make assumptions about how to 
expose that element to AT.

Consider creating a date picker in the time we haven't added type=date yet.  
Inside the shadow DOM of this color picker may contain various buttons and 
controls to move between months and pick a date.  Treating the entire control 
as a text field will provide a very poor user experience.

All the use cases I can think of that let UA can safely make assumptions about 
the ARIA role of the element involves tweaking the appearance, which is better 
served by better styling mechanisms for form controls.


  The way I look at this is that currently you have nothing, since only
  Chrome ships this. There's a chance to get three more browsers if you
  make some concessions on the warts. And then hopefully we can iterate
  from there in a more cooperative fashion.
 
  Here's where we differ, because:
  - I don't think it's a wart. I've given this a great deal of thought and I 
  keep ending up back at the current syntax when I try to think of 
  reasonable alternatives, even assuming we could magically fix all the 
  implementation issues with any alternative proposal.
 
 FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly) 
 spec'ed.
 
 Any chance you could go into more detail on that? What exactly is it you 
 dislike about it?

See our replies on the topic on public-webapps.  I don't have a time to collect 
all our replies or restate all the problems we have with is= syntax.  (Perhaps 
I should put up a document somewhere to reference since someone brings up the 
same question every six months or so, and I'm getting sick and tried to even 
say that I don't have a time to re-iterate the same points over and over...)

  - I don't think shipping in one browser is nothing. People (both 
  framework authors and web page authors) are already writing code using 
  is=.
 
 Some developers are always going to use a feature only implemented by a 
 single browser (ActiveX in Trident, NaCl in Chrome, current web components 
 implementation in Chrome). In fact, why would any browser vendor ship a 
 feature that's not going to be used by anyone? However, that doesn't mean 
 the feature will be standardized or adopted by other browser vendors.
 
 No, but unlike the first two examples, this is a proposed web standard.

Well, not everything people propose as a standard becomes a standard.  When a 
proposed standard is rejected, however, people tend to come up with an 
alternative proposal to address those issues.  As far as is= syntax is 
concerned, I haven't heard of any proposals to fix it so as to address 
everyone's concerns.

If you're really passionate about this feature, I suggest you can go dig all 
the discussions we've had in the last three years and see if you can resolve 
all the concerns raised by various participants of the working group.  Now, 
some of those concerns we and others have raised may not be relevant, and they 
may have changed their positions and opinions on matters.  Regardless, I don't 
think keep saying you like (or that you think we need) this feature without 
proposing fixes to raised concerns is productive.

- R. 

Re: Custom Elements: is=

[Alice Boxhall]

On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote:

 On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:
 Web developers are already writing their own custom elements as a bunch
 of nested div's.  How does introducing custom elements make it worse?


 I believe the rest of my comment already addressed this.


 Sorry, I don't follow.

  - I realise that to some extent developers already aren't using native
 elements, in part because of the styling issues we've discussed which also
 affect is=. My concern here is that custom elements will further legitimise
 this habit, which we've been making some recent progress in changing - we
 stand to backslide on that effort. Having is= would allow us to roll it
 into the use native elements where possible message rather than diluting
 it with unless you're using a custom element in which case here's a
 checklist which you're not going to look at of everything it should do
 until we come up with an alternative.

 In the case of stylizing elements, it doesn't really matter if authors
 attach a shadow DOM on top of a builtin input element or to a div because
 as soon as the shadow DOM replaces the rendered contents, we can't make
 assumptions about how to expose that element to AT.


 That's simply not true at all. If someone replaces the rendered content of
 a `button`, we know that their intent is to create an element which is
 semantically a button, and may even be rendered as a button in some cases.
 Similarly for `input` with a `type` attribute. This is no different to
 using an ARIA role as far as assistive technology is concerned.


 Perhaps I should have said we can't _always_ make assumptions about how
 to expose that element to AT.

 Consider creating a date picker in the time we haven't added type=date
 yet.  Inside the shadow DOM of this color picker may contain various
 buttons and controls to move between months and pick a date.  Treating the
 entire control as a text field will provide a very poor user experience.


Ah, I see what you're saying now, thanks for clarifying.

In this case, the custom element author can add semantic markup inside
Shadow DOM just as the browser does for a date picker currently - no
assumptions need to be made, since even in the case of type extensions the
Shadow DOM is available to the accessibility tree. I don't think it will
ever treat the entire control as a text field.


 All the use cases I can think of that let UA can safely make assumptions
 about the ARIA role of the element involves tweaking the appearance, which
 is better served by better styling mechanisms for form controls.


I don't think it's an either/or question between is= and styling mechanisms
for form controls. I actually think we need both.

  The way I look at this is that currently you have nothing, since only
  Chrome ships this. There's a chance to get three more browsers if you
  make some concessions on the warts. And then hopefully we can iterate
  from there in a more cooperative fashion.
 
  Here's where we differ, because:
  - I don't think it's a wart. I've given this a great deal of thought
 and I keep ending up back at the current syntax when I try to think of
 reasonable alternatives, even assuming we could magically fix all the
 implementation issues with any alternative proposal.

 FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly)
 spec'ed.


 Any chance you could go into more detail on that? What exactly is it you
 dislike about it?


 See our replies on the topic on public-webapps.  I don't have a time to
 collect all our replies or restate all the problems we have with is=
 syntax.  (Perhaps I should put up a document somewhere to reference since
 someone brings up the same question every six months or so, and I'm getting
 sick and tried to even say that I don't have a time to re-iterate the same
 points over and over...)


If you did have time to put together such a document at some point, it
would be much appreciated!

I do absolutely realise that it's important to address the existing
concerns, but I've been having a really hard time trying to figure out
exactly what those are. (It's also unfortunately really difficult to search
for 'is=' when search engines strip out punctuation from search terms.)

  - I don't think shipping in one browser is nothing. People (both
 framework authors and web page authors) are already writing code using is=.

 Some developers are always going to use a feature only implemented by a
 single browser (ActiveX in Trident, NaCl in Chrome, current web components
 implementation in Chrome). In fact, why would any browser vendor ship a
 feature that's not going to be used by anyone? However, that doesn't mean
 the feature will be standardized or adopted by other browser vendors.


 No, but unlike the first two 

Re: Custom Elements: is=

[Ryosuke Niwa]

 On Jun 8, 2015, at 4:37 PM, Alice Boxhall aboxh...@google.com wrote:
 
 
 
 On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote:
 
 On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote:
 
 On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote:
 
  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:
 Web developers are already writing their own custom elements as a bunch 
 of nested div's.  How does introducing custom elements make it worse?
 
 I believe the rest of my comment already addressed this.
 
 Sorry, I don't follow.
 
  - I realise that to some extent developers already aren't using native 
  elements, in part because of the styling issues we've discussed which 
  also affect is=. My concern here is that custom elements will further 
  legitimise this habit, which we've been making some recent progress in 
  changing - we stand to backslide on that effort. Having is= would allow 
  us to roll it into the use native elements where possible message 
  rather than diluting it with unless you're using a custom element in 
  which case here's a checklist which you're not going to look at of 
  everything it should do until we come up with an alternative.
 
 In the case of stylizing elements, it doesn't really matter if authors 
 attach a shadow DOM on top of a builtin input element or to a div because 
 as soon as the shadow DOM replaces the rendered contents, we can't make 
 assumptions about how to expose that element to AT.
 
 That's simply not true at all. If someone replaces the rendered content of 
 a `button`, we know that their intent is to create an element which is 
 semantically a button, and may even be rendered as a button in some cases. 
 Similarly for `input` with a `type` attribute. This is no different to 
 using an ARIA role as far as assistive technology is concerned.
 
 Perhaps I should have said we can't _always_ make assumptions about how to 
 expose that element to AT.
 
 Consider creating a date picker in the time we haven't added type=date yet.  
 Inside the shadow DOM of this color picker may contain various buttons and 
 controls to move between months and pick a date.  Treating the entire 
 control as a text field will provide a very poor user experience.
 
 Ah, I see what you're saying now, thanks for clarifying.
 
 In this case, the custom element author can add semantic markup inside Shadow 
 DOM just as the browser does for a date picker currently - no assumptions 
 need to be made, since even in the case of type extensions the Shadow DOM is 
 available to the accessibility tree. I don't think it will ever treat the 
 entire control as a text field.

If you're fine with that, why don't you just let authors just put ARIA role in 
buttons' shadow DOM as well?

It would also mean that the author must override the ARIA role implicitly set 
(text field) by UA in this case.  I'd say that's exactly the kind of feature 
that makes the Web platform annoying.

 All the use cases I can think of that let UA can safely make assumptions 
 about the ARIA role of the element involves tweaking the appearance, which 
 is better served by better styling mechanisms for form controls.
  
 I don't think it's an either/or question between is= and styling mechanisms 
 for form controls. I actually think we need both.

Why?  Having authors use two completely different mechanisms to define 
semantics seems like the worst of the both worlds.

- R. Niwa

Re: Custom Elements: is=

[Travis Leithead]

My current understanding of is= is a request for an implementation to 
plug-in a native element's backing behavior under a custom element name. This 
feature would otherwise not be available without is=, as custom elements are 
always generic by design.

As Dimitri has noted in the past, I think this feature nicely solves some 
accessibility gaps in the platform. It's not ideal, but I believe it is useful. 
I'm not wedded to the syntax or API for doing this though, and I'd welcome 
suggestions to improve it.


From: Ryosuke Niwa rn...@apple.com
Sent: Monday, June 8, 2015 5:58 PM
To: Alice Boxhall
Cc: Anne van Kesteren; Léonie Watson; WebApps WG
Subject: Re: Custom Elements: is=

 On Jun 8, 2015, at 4:37 PM, Alice Boxhall aboxh...@google.com wrote:



 On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote:

 On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote:

  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:
 Web developers are already writing their own custom elements as a bunch 
 of nested div's.  How does introducing custom elements make it worse?

 I believe the rest of my comment already addressed this.

 Sorry, I don't follow.

  - I realise that to some extent developers already aren't using native 
  elements, in part because of the styling issues we've discussed which 
  also affect is=. My concern here is that custom elements will further 
  legitimise this habit, which we've been making some recent progress in 
  changing - we stand to backslide on that effort. Having is= would allow 
  us to roll it into the use native elements where possible message 
  rather than diluting it with unless you're using a custom element in 
  which case here's a checklist which you're not going to look at of 
  everything it should do until we come up with an alternative.

 In the case of stylizing elements, it doesn't really matter if authors 
 attach a shadow DOM on top of a builtin input element or to a div because 
 as soon as the shadow DOM replaces the rendered contents, we can't make 
 assumptions about how to expose that element to AT.

 That's simply not true at all. If someone replaces the rendered content of 
 a `button`, we know that their intent is to create an element which is 
 semantically a button, and may even be rendered as a button in some cases. 
 Similarly for `input` with a `type` attribute. This is no different to 
 using an ARIA role as far as assistive technology is concerned.

 Perhaps I should have said we can't _always_ make assumptions about how to 
 expose that element to AT.

 Consider creating a date picker in the time we haven't added type=date yet.  
 Inside the shadow DOM of this color picker may contain various buttons and 
 controls to move between months and pick a date.  Treating the entire 
 control as a text field will provide a very poor user experience.

 Ah, I see what you're saying now, thanks for clarifying.

 In this case, the custom element author can add semantic markup inside Shadow 
 DOM just as the browser does for a date picker currently - no assumptions 
 need to be made, since even in the case of type extensions the Shadow DOM is 
 available to the accessibility tree. I don't think it will ever treat the 
 entire control as a text field.

If you're fine with that, why don't you just let authors just put ARIA role in 
buttons' shadow DOM as well?

It would also mean that the author must override the ARIA role implicitly set 
(text field) by UA in this case.  I'd say that's exactly the kind of feature 
that makes the Web platform annoying.

 All the use cases I can think of that let UA can safely make assumptions 
 about the ARIA role of the element involves tweaking the appearance, which 
 is better served by better styling mechanisms for form controls.

 I don't think it's an either/or question between is= and styling mechanisms 
 for form controls. I actually think we need both.

Why?  Having authors use two completely different mechanisms to define 
semantics seems like the worst of the both worlds.

- R. Niwa

Re: Custom Elements: is=

[Alice Boxhall]

On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com wrote:
  I definitely acknowledge is= may not be the ideal solution to the latter
  problem - it definitely has some holes in it, especially when you start
  adding author shadow roots to things - but I think it does have
 potential.
  I'd really like to be convinced that we either have a reasonable
 alternative
  solution, or that it's not worth worrying about.

 I think it is worth worrying about, but I don't think it's worth
 holding up a minimal v1 of Custom Elements for. The way to get
 agreement among all parties is to do less. And then take baby steps
 from.


I can definitely see that logic.

My concerns with this in practice are:

- In the time between v1 and v2 (however long that ends up being) we are
left without any way to solve this problem, assuming we don't come up with
something else for v1. If developers start using custom elements where they
would previously have used a native element, this could well result in a
regression in accessibility for the web as a whole for this period, and we
will be stuck with the legacy of code written during this period for much
longer as well.

- I realise that to some extent developers already aren't using native
elements, in part because of the styling issues we've discussed which also
affect is=. My concern here is that custom elements will further legitimise
this habit, which we've been making some recent progress in changing - we
stand to backslide on that effort. Having is= would allow us to roll it
into the use native elements where possible message rather than diluting
it with unless you're using a custom element in which case here's a
checklist which you're not going to look at of everything it should do
until we come up with an alternative.

- v1 sets the stage for people to develop habits and expectations about how
custom elements work. New features tend to be slowly adopted, by both
browser vendors and (partly as a consequence) developers, so even if we do
come up with something for v2, it will be even longer before it becomes
mainstream (and as I mentioned earlier we will still be stuck with code
written to v1 for much longer again).


 The way I look at this is that currently you have nothing, since only
 Chrome ships this. There's a chance to get three more browsers if you
 make some concessions on the warts. And then hopefully we can iterate
 from there in a more cooperative fashion.


Here's where we differ, because:
- I don't think it's a wart. I've given this a great deal of thought and I
keep ending up back at the current syntax when I try to think of reasonable
alternatives, even assuming we could magically fix all the implementation
issues with any alternative proposal.
- I don't think shipping in one browser is nothing. People (both
framework authors and web page authors) are already writing code using is=.


 (The thread Steve shared about ARIA seemed like an equivalent effort
 by the way, to expose some of the semantics of native elements through
 simple attributes.)


Thanks for the pointer - I followed up on that thread with some thoughts on
that proposal.

Re: Custom Elements: insert/remove callbacks

[Boris Zbarsky]

On 5/9/15 12:40 PM, Anne van Kesteren wrote:

So that seems clearly wrong (in the specification)... Are descendants
notified in tree order?


In Gecko, yes.

Note that running script during these insert/remove notifications is not 
OK, so anything that needs to run script has to do it later (for 
various definitions of later).


-Boris

Re: Custom Elements: insert/remove callbacks

[Anne van Kesteren]

On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 5/8/15 1:42 AM, Elliott Sprehn wrote:
 That actually seems pretty similar to what we have, ours is in the form
 of:

 Node#insertedInto(Node insertionPoint)
 Node#removedFrom(Node insertionPoint)

 To be clear, ours is also in the form of two methods
 (BindToTree/UnbindFromTree) that take various arguments.

The DOM only has insert/remove hooks:

  https://dom.spec.whatwg.org/#concept-node-insert-ext
  https://dom.spec.whatwg.org/#concept-node-remove-ext

So that seems clearly wrong (in the specification)... Are descendants
notified in tree order?

I filed https://github.com/whatwg/dom/issues/34 to track this.


-- 
https://annevankesteren.nl/

Re: Custom Elements: insert/remove callbacks

[Elliott Sprehn]

On May 9, 2015 9:41 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote:
  On 5/8/15 1:42 AM, Elliott Sprehn wrote:
  That actually seems pretty similar to what we have, ours is in the form
  of:
 
  Node#insertedInto(Node insertionPoint)
  Node#removedFrom(Node insertionPoint)
 
  To be clear, ours is also in the form of two methods
  (BindToTree/UnbindFromTree) that take various arguments.

 The DOM only has insert/remove hooks:

   https://dom.spec.whatwg.org/#concept-node-insert-ext
   https://dom.spec.whatwg.org/#concept-node-remove-ext

 So that seems clearly wrong (in the specification)... Are descendants
 notified in tree order?

Yes, and anything that can run script is notified in a second pass. So for
example if you create a script, put it in a subtree, then append the
subtree, the script runs after all insertedInto notifications have been
sent to the subtree.

- E

Re: Custom Elements: insert/remove callbacks

[Adam Klein]

On Thu, May 7, 2015 at 10:56 PM, Elliott Sprehn espr...@chromium.org
wrote:


 On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org
 wrote:
  That actually seems pretty similar to what we have, ours is in the form
 of:
 
  Node#insertedInto(Node insertionPoint)
  Node#removedFrom(Node insertionPoint)
 
  where insertionPoint is the ancestor in the tree where a connection was
  added or removed which may be arbitrarily far up the ancestor chain.
 From
  that you can figure out all the cases Boris is describing.

 Cool. So maybe the DOM specification needs to be updated to have that
 model and we should expose that as low-level hook to web developers.


 We'd consider adding a new MutationObserver type, we'd prefer not to add
 any more tree mutation callbacks. Anything you can do with those you can do
 with an ancestorChanged record type and takeRecords().


We should think hard before adding ancestor information to
MutationObservers; like other DOM-tree-related APIs, they are very much
based around the model of information coming up the tree from below (you
can imagine how odd it would be to add event dispatch that flowed down the
tree towards the leaves).

- Adam

RE: Custom Elements: is=

[Travis Leithead]

The 'is' attribute is only a declarative marker; it's the indicator that the 
native element has a [potential] custom prototype and hierarchy, right?

I don't mean to drudge up past history and decisions already laid to rest, but 
if subclassing native elements is a good compromise until we get to the 
underlying behaviors that make up native HTML elements, why should we limit 
registerElement to hyphenated custom element names?

In other words, why not simplify by:
1. Allow any localName to be used by registerElement. (This would imply the 
HTML namespace by default; we can later add registerElementNS if needed :)
2.  Drop the 'extends' member from the ElementRegistrationOptions dictionary.

With this simplification, serializing elements wouldn't include any sign that 
they are 'customized' in any way (as is done with 'is' today). I don't see this 
as a problem, since web devs today can already do this, but without the help of 
the parser.

It always seemed weird to me that 'prototype' of ElementRegistrationOptions can 
inherit from anything (including null), and be completely disassociated from 
the localName provided in 'extends'.

If we drop support for 'is' in v1, then we can consider later bringing back 
subclassing in v2 without introducing 'extends' in the 
ElementRegistrationOptions or the 'is' attribute.

If we opt to keep the feature, I'd like to see it simplified as described above.

(In general: I'd also like to see a 'constructor' property added automatically 
to the prototype so that you can always get to the native constructor function 
from script even if you don't save the return value of registerElement.)


 On May 6, 2015, at 6:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 Open issues are kept track of here:
 
  https://wiki.whatwg.org/wiki/Custom_Elements
 
 I think we reached rough consensus at the Extensible Web Summit that 
 is= does not do much, even for accessibility. Accessibility is 
 something we need to tackle low-level by figuring out how builtin 
 elements work:
 
  https://github.com/domenic/html-as-custom-elements
 
 And we need to tackle it high-level by making it easier to style 
 builtin elements:
 
  http://dev.w3.org/csswg/css-forms/
 
 And if the parser functionality provided by is= is of great value, 
 we should consider parsing elements with a hyphen in them differently.
 Similar to how script and template are allowed pretty much 
 everywhere.
 
 Therefore, I propose that we move subclassing of builtin elements to 
 v2, remove is= from the specification, and potentially open an issue 
 on HTML parser changes.

We (Apple) support this proposal.

- R. Niwa