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 wrote:
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 `HierarchyReque
On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa wrote:
>
> > On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov
> wrote:
> >
> > FWIW, I think that element upgrade is sort of fundamental to the
> usefulness of custom elements. In a world where most scripts are
> non-blocking (that's hopefully the moder
> On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov wrote:
>
> FWIW, I think that element upgrade is sort of fundamental to the usefulness
> of custom elements. In a world where most scripts are non-blocking (that's
> hopefully the modern world we should aim for), I'll effectively expect to
> wal
On Thu, Jan 15, 2015 at 5:29 PM, Ryosuke Niwa wrote:
>
> The only reason you need to have the two-stage setup is because you want
> to support asynchronous upgrading of elements. As we have repeatedly
> stated in the past, we don't support a design that involves upgrading
> elements after the el
> On Jan 15, 2015, at 3:17 PM, Domenic Denicola wrote:
>
> From: Ryosuke Niwa [mailto:rn...@apple.com]
>
>> If ES6 classes' constructor doesn't fundamentally work with custom elements,
>> then why don't we change the design of ES6 classes.
>
> We would essentially be saying that the design o
On Thu, Jan 15, 2015 at 6:43 PM, Domenic Denicola wrote:
> Steve's concerns are best illustrated with a more complicated element like
> . He did a great pull request to the custom elements spec that
> contrasts all the work you have to do with vs. is="tequila-button">:
>
> https://w3c.github.io
Steve's concerns are best illustrated with a more complicated element like
. He did a great pull request to the custom elements spec that
contrasts all the work you have to do with vs. :
https://w3c.github.io/webcomponents/spec/custom/#custom-tag-example vs.
https://w3c.github.io/webcomponents
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 op
Hi all,
Steve wrote:
>> [I]t also does not address subclassing normal elements. Again, while
>> that seems desirable
>
> Given that subclassing normal elements is the easiest and most robust
> method (for developers) of implementing semantics[1] and interaction
> support necessary for accessibili
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
> On Jan 15, 2015, at 11:28 AM, Domenic Denicola wrote:
>
> From: Dimitri Glazkov [mailto:dglaz...@google.com]
>
>> Why is "Not having identity at creation-time is currently a mismatch with
>> the rest of the platform" a problem? Why does it all have to be consistent
>> across the board? Are
On Thu, Jan 15, 2015 at 12:27 PM, Ryosuke Niwa wrote:
>> On Jan 15, 2015, at 11:47 AM, Brian Kardell wrote:
>> Not to sidetrack the discussion but Steve Faulker made what I think was a
>> valid observation and I haven't seen a response... Did I miss it?
>
> When and in which thread? Could you g
the basis:
<http://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 Jan 15, 2015, at 11:47 AM, Brian Kardell wrote:
>
> Not to sidetrack the discussion but Steve Faulker made what I think was a
> valid observation and I haven't seen a response... Did I miss it?
When and in which thread? Could you give us a pointer?
- R. Niwa
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?
>
>
> > 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
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
On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren wrote:
>
>
> * I think we could iterate towards a v2 that has an aspect of
> upgrading but perhaps works a bit differently from the current setup.
> E.g. a way to include an entire subtree of custom elements with a
> fallback mechanism of sorts. O
On Thu, Jan 15, 2015 at 2:37 AM, Anne van Kesteren wrote:
> On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz 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
No argument that callbacks are also a useful new addition.
:DG<
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 nam
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 worl
>
>
> 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 agre
Thanks, this is very useful!
On Thu Jan 15 2015 at 5:40:02 PM Anne van Kesteren wrote:
> On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
> wrote:
> > Anne, maybe you could write on the wiki what the current Web Components
> > implementation in Chrome is using. That would make it a b
On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
wrote:
> Anne, maybe you could write on the wiki what the current Web Components
> implementation in Chrome is using. That would make it a bit easier to follow
> for people who didn't follow all of the discussion so far.
I updated the pa
Anne, maybe you could write on the wiki what the current Web Components
implementation in Chrome is using. That would make it a bit easier to
follow for people who didn't follow all of the discussion so far.
Kenneth
On Thu Jan 15 2015 at 5:05:35 PM Anne van Kesteren wrote:
> On Wed, Jan 14, 201
On Thu, Jan 15, 2015 at 1:09 AM, Dmitry Lomov wrote:
>
>
> On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz wrote:
>>
>> On Wed, Jan 14, 2015 at 3:47 PM, Domenic Denicola wrote:
>>
>> Isn't this at least a little future-hostile to things like `new
>> MyElement(attrs)`? Is there a way we could get ba
On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov wrote:
> FWIW, I think that element upgrade is sort of fundamental to the usefulness
> of custom elements. In a world where most scripts are non-blocking (that's
> hopefully the modern world we should aim for), I'll effectively expect to
> walk the
On Wed, Jan 14, 2015 at 9:25 PM, Ryosuke Niwa wrote:
>> On Jan 14, 2015, at 6:45 AM, Anne van Kesteren wrote:
>> * Existing lifecycle callbacks plus those agreed (copying, adopting).
>
> Could you give us pointers for a proposed definition of these two callbacks
> if there is any?
I added a sho
On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz 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 well as
the other
31 matches
Mail list logo
