On Thursday, January 15, 2015, Domenic Denicola d...@domenic.me wrote:
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
Agree with this completely.
Yehuda Katz
(ph) 718.877.1325
On Tue, Jan 27, 2015 at 9:32 PM, Domenic Denicola d...@domenic.me wrote:
From: Elliott Sprehn [mailto:espr...@google.com]
Perhaps, but that logically boils down to never use string properties
ever just in case some library conflicts
On Tuesday, January 27, 2015, Domenic Denicola d...@domenic.me wrote:
It does. If a framework says “use clonedCallback and we will implementing
cloning for you,” we cannot add a clonedCallback with our own semantics.
Whereas, if a framework says “use [Framework.cloned] and we will implement
From: Elliott Sprehn [mailto:espr...@google.com]
Perhaps, but that logically boils down to never use string properties ever
just in case some library conflicts with a different meaning. We'd have
$[jQuery.find](...) and so on for plugins.
Nah, it boils down to don't use string properties
I'm also curios why DOM mutation is a problem.
I read arguments like using the nodes as a key in a Map but such code is
already broken as a node can also be replaced with some user code; so such
code should put into account the node replacement.
I also don't understand how the two-tier
On Thu, Jan 15, 2015 at 8:02 PM, Dimitri Glazkov dglaz...@google.com wrote:
Thanks for starting this page! One thing that seems missing is Steve
Faulkner's concern about removing is.
I added a note. It would be interesting to see what developers have
been doing so far. From what I've seen is=
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,
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 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
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
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
I had a chat with Dmitry Lomov (V8 team/TC39, helped shape the new ES6 classes
design, CC'ed). His perspective was helpful. He suggested a way of evolving the
current createdCallback design that I think makes it more palatable, and allows
us to avoid all of the teeth-gnashing we've been doing
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:
I had a chat with Dmitry Lomov (V8 team/TC39, helped shape the new ES6
classes design, CC'ed). His perspective was helpful. He suggested a way of
On Wed, Jan 14, 2015 at 3:47 PM, Domenic Denicola d...@domenic.me wrote:
I had a chat with Dmitry Lomov (V8 team/TC39, helped shape the new ES6
classes design, CC'ed). His perspective was helpful. He suggested a way of
evolving the current createdCallback design that I think makes it more
On 1/14/15 8:28 AM, Anne van Kesteren wrote:
On Wed, Jan 14, 2015 at 2:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Wanting things like custom buttons is _very_ common. What is your proposal
for addressing this use case?
I have no good answer. appearance:button seems to work okayish
I
On Mon, Jan 12, 2015 at 9:11 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/12/15 12:20 PM, Tab Atkins Jr. wrote:
Proto munging isn't even that big of a deal.
That really depends.
For example, dynamically changing __proto__ on something somewhat
permanently deoptimizes that object in at
On 1/14/15 11:52 AM, Dimitri Glazkov wrote:
Would like to point out that we're not talking about a general case
here. The actual proto munging in custom elements spec is minimized to a
pretty small set.
Pretty small set of which? Possible mutations, elements, something else.
Given that most
On Tue, Jan 13, 2015 at 6:50 PM, Domenic Denicola d...@domenic.me wrote:
Agreed. That needs to be done with img is=my-img, IMO.
I would really like to avoid having this is= design. It does not
explain anything about the world today. I would rather we gave up on
subclassing normal elements
On 1/14/15 7:51 AM, Anne van Kesteren wrote:
I would rather we gave up on subclassing normal elements
Wanting things like custom buttons is _very_ common. What is your
proposal for addressing this use case?
-Boris
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Hmm. So given the current direction whereby ES6 constructors may not even be
[[Call]]-able at all, I'm not sure we have any great options here. :(
Basically, ES6 is moving toward coupling allocation and initialization but
the upgrade
On 1/13/15 12:06 PM, Gabor Krizsanits wrote:
I think this part of the spec was largely written before ES6 class stuff
stabilized, fwiw. Which is not hard, since it's still not stabilized. ;)
Isn't there a chance to consider our use-case in ES6 spec. then?
I suspect not in time for ES6.
From: Gabor Krizsanits [mailto:gkrizsan...@mozilla.com]
Isn't there a chance to consider our use-case in ES6 spec. then?
I kind of feel like I and others dropped the ball on this one. Until this
thread I didn't realize how important the dual-stage allocation +
initialization was, for
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Just to be clear, this still didn't allow you to upgrade a my-img to be a
subclass of img, because that required a change in allocation, right?
Agreed. That needs to be done with img is=my-img, IMO. (Assuming the
upgrading design doesn't get
On 1/13/15 12:50 PM, Domenic Denicola wrote:
Agreed. That needs to be done with img is=my-img, IMO. (Assuming the
upgrading design doesn't get switched to DOM mutation, of course.)
Although! Briefly yesterday Arv mentioned that for Blink's DOM implementation there's no real
difference in
I think this part of the spec was largely written before ES6 class stuff
stabilized, fwiw. Which is not hard, since it's still not stabilized. ;)
Isn't there a chance to consider our use-case in ES6 spec. then?
Basically, ES6 is moving toward coupling allocation and
initialization but the
On 1/13/15 12:10 PM, Domenic Denicola wrote:
Hmm. So given the current direction whereby ES6 constructors may not even be
[[Call]]-able at all, I'm not sure we have any great options here. :(
Basically, ES6 is moving toward coupling allocation and initialization but the
upgrade scenario
On Tue, Jan 13, 2015 at 9:50 AM, Domenic Denicola d...@domenic.me wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Just to be clear, this still didn't allow you to upgrade a my-img to
be a subclass of img, because that required a change in allocation, right?
Agreed. That needs to be
On Sun, Jan 11, 2015 at 9:13 PM, Domenic Denicola d...@domenic.me wrote:
However, I don't understand how to make it work for upgraded elements at all
Yes, upgrading is the problem. There's two strategies as far as I can
tell to maintain a sane class design:
1) There is no upgrading. We
In ES6 the constructor does both allocation and initialization. At
upgrade time it is too late to do allocation so we cannot call the
constructor at that time. We would need a callback for this, call it
upgradeCallback for example.
When the parser sees a custom element (any element with a dash in
On Jan 12, 2015, at 5:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jan 11, 2015 at 9:13 PM, Domenic Denicola d...@domenic.me wrote:
However, I don't understand how to make it work for upgraded elements at all
Yes, upgrading is the problem. There's two strategies as far as I
From: Ryosuke Niwa [mailto:rn...@apple.com]
As we have repeatedly stated elsewhere in the mailing list, we support option
1 since authors and frameworks can trivially implement 2 or choose to set
prototype without us baking the feature into the platform.
At first I was sympathetic toward
From: Domenic Denicola [mailto:d...@domenic.me]
In other words, in an ES6 modules world, all custom elements are upgraded
elements.
Should be, In other words, in an ES6 modules world, all custom elements
__that appear in the initially-downloaded .html file__ are upgraded elements.
On Jan 12, 2015, at 2:59 PM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
As we have repeatedly stated elsewhere in the mailing list, we support
option 1 since authors and frameworks can trivially implement 2 or choose to
set prototype without us
On Jan 12, 2015, at 4:24 PM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
In that case, we can either delay the instantiation of those unknown
elements with - in their names until pending module loads are finished
Could you explain this in a bit
From: Ryosuke Niwa [mailto:rn...@apple.com]
In that case, we can either delay the instantiation of those unknown elements
with - in their names until pending module loads are finished
Could you explain this in a bit more detail? I'm hoping there's some brilliant
solution hidden here that I
On 1/12/15 12:20 PM, Tab Atkins Jr. wrote:
Proto munging isn't even that big of a deal.
That really depends.
For example, dynamically changing __proto__ on something somewhat
permanently deoptimizes that object in at least some JS engines.
Whether that's a big deal depends on what you do
On 1/11/15 3:13 PM, Domenic Denicola wrote:
So, at least as a thought experiment: what if we got rid of all the local name checks
in implementations and the spec. I think then `my-q` could work, as long as
it was done *after* `document.registerElement` calls.
Yes.
However, I don't
On 1/12/15 7:24 PM, Domenic Denicola wrote:
One crazy idea for solving B is to make every DOM element (or at least, every one
generated via parsing a hyphenated or is= element) into a proxy whose target
can switch from e.g. `new HTMLUnknownElement()` to `new MyEl()` after upgrading. Like
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Proto munging isn't even that big of a deal. It's the back-end stuff that's
kinda-proto but doesn't munge that's the problem. This is potentially
fixable if we can migrate more elements out into JS space.
It really isn't though, at least,
On Mon, Jan 12, 2015 at 5:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jan 11, 2015 at 9:13 PM, Domenic Denicola d...@domenic.me wrote:
However, I don't understand how to make it work for upgraded elements at all
Yes, upgrading is the problem. There's two strategies as far as I can
Following some old bug links indicates to me this has all been gone over many
times before. In particular:
- https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913 discussion of class
syntax, prototypes, my-el vs. q is=my-qq, and more
- https://www.w3.org/Bugs/Public/show_bug.cgi?id=21063 and
43 matches
Mail list logo
