Just to clarify, this argument for symbols is not dependent on modules.
Restated, the comparison is between:
```js
class MyButton extends HTMLElement {
createdCallback() {}
}
```
vs.
```js
class MyButton extends HTMLElement {
[Element.create]() {}
}
```
We're already doing some crude
I'm sympathetic to this but I think it is fine that DOM continues to
define new string based property names. Anytime we add a new property
to an existing class we run into this issue and I don't think we want
to give up on the superior usability of string based property names.
I agree,
No argument that callbacks are also a useful new addition.
:DG
On Thu, Jan 15, 2015 at 2:37 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz wyc...@gmail.com wrote:
Can you say more about why same-identity upgrading is critical to the
design
(as opposed to dom-mutation upgrading)? I asked up-thread but didn't
It's not clear to me that:
import HTMLElement from web/element;
class MyButton extends HTMLElement {
readyCallback() {}
}
is that much more usable than
import HTMLElement, { ready } from web/element;
class MyButton extends HTMLElement {
[ready]() {}
}
In other words, in a modules world,
On Wed, Jan 14, 2015 at 9:25 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 14, 2015, at 6:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
* Existing lifecycle callbacks plus those agreed (copying, adopting).
Could you give us pointers for a proposed definition of these two callbacks
if
Anne, maybe you could write on the wiki what the current Web Components
implementation in Chrome is using. That would make it a bit easier to
follow for people who didn't follow all of the discussion so far.
Kenneth
On Thu Jan 15 2015 at 5:05:35 PM Anne van Kesteren ann...@annevk.nl wrote:
On
On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov dglaz...@google.com wrote:
FWIW, I think that element upgrade is sort of fundamental to the usefulness
of custom elements. In a world where most scripts are non-blocking (that's
hopefully the modern world we should aim for), I'll effectively
On Thu, Jan 15, 2015 at 1:09 AM, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz wyc...@gmail.com wrote:
On Wed, Jan 14, 2015 at 3:47 PM, Domenic Denicola d...@domenic.me wrote:
Isn't this at least a little future-hostile to things like `new
On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
Anne, maybe you could write on the wiki what the current Web Components
implementation in Chrome is using. That would make it a bit easier to follow
for people who didn't follow all of the
Thanks, this is very useful!
On Thu Jan 15 2015 at 5:40:02 PM Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
Anne, maybe you could write on the wiki what the current Web Components
implementation
We're already doing some crude namespacing with *Callback. I'd expect
that as soon as the first iteration of Custom Elements is out, people will
copy the *Callback style in user code.
This is a powerful point that I definitely agree with. I would not be
terribly surprised to find some
From: Dimitri Glazkov [mailto:dglaz...@google.com]
Why is Not having identity at creation-time is currently a mismatch with the
rest of the platform a problem? Why does it all have to be consistent across
the board? Are there any other platform objects that are created by HTML
parser or a
On Thu, Jan 15, 2015 at 12:27 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 15, 2015, at 11:47 AM, Brian Kardell bkard...@gmail.com wrote:
Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?
When and in
On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren ann...@annevk.nl wrote:
* I think we could iterate towards a v2 that has an aspect of
upgrading but perhaps works a bit differently from the current setup.
E.g. a way to include an entire subtree of custom elements with a
fallback mechanism
From: Ryosuke Niwa [mailto:rn...@apple.com]
Unfortunately for developers, native syntax for inheritance in Stink 2.0
cannot be used to subclass views in Odour.
The native syntax for inheritance can definitely be used! You just can't
override the constructor, since constructing a view is a
Steve's concerns are best illustrated with a more complicated element like
button. He did a great pull request to the custom elements spec that
contrasts all the work you have to do with taco-button vs. button
is=tequila-button:
Hi all,
Steve wrote:
[I]t also does not address subclassing normal elements. Again, while
that seems desirable
Given that subclassing normal elements is the easiest and most robust
method (for developers) of implementing semantics[1] and interaction
support necessary for accessibility I
I've updated my element constructors sketch at
https://github.com/domenic/element-constructors/blob/master/element-constructors.js
with a design that means no subclasses of HTMLElement (including the built-in
elements) need to override their constructor or [Symbol.species](). It also
uses an
On Jan 15, 2015, at 11:28 AM, Domenic Denicola d...@domenic.me wrote:
From: Dimitri Glazkov [mailto:dglaz...@google.com]
Why is Not having identity at creation-time is currently a mismatch with
the rest of the platform a problem? Why does it all have to be consistent
across the board?
Currently, for `oldNode.replaceWith(…collection)`, if `collection` is array of
multiple nodes, and `oldNode` is in `collection`, after the mutation method
macro, `oldNode` lives in a doc frag. So in the replace algorithm, `parent` is
the doc frag, `node` is also the doc frag, an
Another way to do this is that in mutation method macro, prevent `oldNode` from
being added to the doc frag, and after that, insert the doc frag before
`oldNode`, finally remove `oldNode`. No recursive finding of next sibling is
needed this way.
On Jan 16, 2015, at 1:37 PM, Glen Huang
Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?
://w3ctag.github.io/packaging-on-the-web/
FYI, this FPWD was published today
http://www.w3.org/TR/2015/WD-web-packaging-20150115/.
Sorry for the delay.
-AB
On Thu, Jan 15, 2015 at 6:43 PM, Domenic Denicola d...@domenic.me wrote:
Steve's concerns are best illustrated with a more complicated element like
button. He did a great pull request to the custom elements spec that
contrasts all the work you have to do with taco-button vs. button
On Jan 15, 2015, at 3:17 PM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
If ES6 classes' constructor doesn't fundamentally work with custom elements,
then why don't we change the design of ES6 classes.
We would essentially be saying that the
On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov dglaz...@google.com wrote:
FWIW, I think that element upgrade is sort of fundamental to the usefulness
of custom elements. In a world where most scripts are non-blocking (that's
hopefully the modern world we should aim for), I'll effectively
On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz wyc...@gmail.com wrote:
Can you say more about why same-identity upgrading is critical to the design
(as opposed to dom-mutation upgrading)? I asked up-thread but didn't get any
takers.
I tried to summarize the various upgrade scenarios here (as
On Jan 15, 2015, at 11:47 AM, Brian Kardell bkard...@gmail.com wrote:
Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?
When and in which thread? Could you give us a pointer?
- R. Niwa
29 matches
Mail list logo
