On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote:
What I mean is that for nodes that doesn't have a constructor, and
whose parent doesn't have a constructor, no need to add them to the
above arrays. Just insert them into their parent. That means that when
that the
On Tue, Feb 18, 2014 at 1:35 PM, Dimitri Glazkov dglaz...@google.comwrote:
Here's an alternative proposal:
1) The Web developers are already aware of the fact that you can create
new instances of JS objects without running their constructors with
Object.create
These are not the instances
On Tue, Feb 18, 2014 at 11:24 AM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Feb 18, 2014 at 1:35 PM, Dimitri Glazkov dglaz...@google.comwrote:
Here's an alternative proposal:
1) The Web developers are already aware of the fact that you can create
new instances of JS objects without
On Feb 18, 2014, at 10:35 AM, Dimitri Glazkov dglaz...@google.com wrote:
On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote:
What I mean is that for nodes that doesn't have a constructor, and
whose parent doesn't have a constructor, no need to add them to the
above arrays.
On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov dglaz...@google.com wrote:
On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote:
What I mean is that for nodes that doesn't have a constructor, and
whose parent doesn't have a constructor, no need to add them to the
above
On Tue, Feb 18, 2014 at 5:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov dglaz...@google.com
wrote:
On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote:
What I mean is that for nodes that doesn't have a constructor,
On Tue, Feb 18, 2014 at 2:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov dglaz...@google.com
wrote:
On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote:
What I mean is that for nodes that doesn't have a constructor,
On Tue, Feb 18, 2014 at 3:26 PM, Dimitri Glazkov dglaz...@google.com wrote:
On Tue, Feb 18, 2014 at 2:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov dglaz...@google.com
wrote:
The thing that really bothers me is that this approach is
On Thu, Feb 13, 2014 at 6:50 PM, Jonas Sicking jo...@sicking.cc wrote:
Dimitri, I'd still love to hear feedback from you on the idea above.
Seems like it could fix one of the design issues that a lot of people
have reacted to.
I am not sure I fully understand how this will work. Let me try
On Fri, Feb 14, 2014 at 9:25 AM, Dimitri Glazkov dglaz...@google.com wrote:
On Thu, Feb 13, 2014 at 6:50 PM, Jonas Sicking jo...@sicking.cc wrote:
Dimitri, I'd still love to hear feedback from you on the idea above.
Seems like it could fix one of the design issues that a lot of people
have
On Fri, Feb 14, 2014 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Feb 14, 2014 at 9:25 AM, Dimitri Glazkov dglaz...@google.com
wrote:
On Thu, Feb 13, 2014 at 6:50 PM, Jonas Sicking jo...@sicking.cc wrote:
Dimitri, I'd still love to hear feedback from you on the idea above.
Another alternative is to disallow DOM traversal and DOM mutation inside
these constructors. By disallow I mean throw an error! Here is a rough
outline of what the algorithm might look like.
Let there be a global counter CostomElementConstructionCounter which is
initially set to 0.
1. Parse and
On 2/14/14 2:03 PM, Erik Arvidsson wrote:
Then we need to guard all DOM traversal and DOM mutation methods and
throw if the counter is non zero.
This is a fairly nontrivial whack-a-mole exercise, sadly (starting with
defining traversal).
-Boris
On Fri, Feb 14, 2014 at 10:50 AM, Dimitri Glazkov dglaz...@google.com wrote:
On Fri, Feb 14, 2014 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Feb 14, 2014 at 9:25 AM, Dimitri Glazkov dglaz...@google.com
wrote:
On Thu, Feb 13, 2014 at 6:50 PM, Jonas Sicking jo...@sicking.cc
Dimitri, I'd still love to hear feedback from you on the idea above.
Seems like it could fix one of the design issues that a lot of people
have reacted to.
/ Jonas
On Wed, Jan 22, 2014 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jan 9, 2014 at 9:27 PM, Boris Zbarsky
We (Apple) support this proposal assuming that we can implement the proposed
algorithm efficiently.
We would try to prototype it in WebKit in the coming months and will report
implementation issues, including the feasibility of efficient implementation,
if exists.
- R. Niwa
On Feb 13, 2014,
On Thu, Jan 9, 2014 at 9:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
One idea that came out of our discussion is was to add an additional step
in the parser to call constructors on all “pending” elements before they’re
being constructed into the DOM tree.
Isn't that the bad thing we _don't_
On Thu, Jan 9, 2014 at 10:57 PM, Ryosuke Niwa rn...@apple.com wrote:
1. The parser does not know that it needs to use MyElement.@@create to
create the JS objects when it sees a my-element.
On the other hand, solving this seems to require running some author
scripts at the element creation
On 1/10/14 11:10 AM, Erik Arvidsson wrote:
My hope was that it would be rare to override Symbol.create for Elements
so in most cases we would not need to call user code.
For spec purposes and parser implementation design purposes that doesn't
matter. If user code can be called, the
On Jan 10, 2014, at 8:16 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/10/14 11:10 AM, Erik Arvidsson wrote:
My hope was that it would be rare to override Symbol.create for Elements
so in most cases we would not need to call user code.
For spec purposes and parser implementation design
Jonas, William, Ted, and I had some discussion about this last month. (Sorry
for the delayed response).
On Dec 5, 2013, at 10:58 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/6/13 1:49 AM, Ryosuke Niwa wrote:
Then how do we define a custom element using ES6 classes? Are we going to
not
On 1/9/14 10:57 PM, Ryosuke Niwa wrote:
Given that, we could maybe cheat and in fact do some sort of delayed calling of the
constructor of ES6 subclasses of elements. You'd still be able to observe these objects
in an unconstructed state from the subclass pov, but at least it wouldn't be
a
On Thu, Jan 9, 2014 at 9:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/9/14 10:57 PM, Ryosuke Niwa wrote:
Given that, we could maybe cheat and in fact do some sort of delayed
calling of the constructor of ES6 subclasses of elements. You'd still be
able to observe these objects in an
On 12/6/13 3:28 PM, ext Ryosuke Niwa wrote:
On Dec 6, 2013, at 7:37 AM, Erik Arvidsson a...@chromium.org
mailto:a...@chromium.org wrote:
1. The parser does not know that it needs to use MyElement.@@create
to create the JS objects when it sees a my-element.
2. No callbacks for enteredView,
Art wrote:
For consistency reasons, and to facilitate transparency, it seems like all
new Web Component bugs should be announced on public-webapps. Does anyone
object to that?
I think that's a fine idea.
Ted
The custom element draft does add a new synchronization point. After
setting innerHTML (for example), before returning to the script the
callbacks for the custom elements created by innerHTML are called in tree
order.
This does lead to the possibility to observer objects that have not yet had
On Fri, Dec 6, 2013 at 2:33 AM, Ryosuke Niwa rn...@apple.com wrote:
It appears to me that we should definitely have a good answer for this
question before the specification reaches CR
given that the definition of ES6 classes is pretty stable at this point.
ES6 classes do not introduce any
On Dec 6, 2013, at 7:37 AM, Erik Arvidsson a...@chromium.org wrote:
On Fri, Dec 6, 2013 at 2:33 AM, Ryosuke Niwa rn...@apple.com wrote:
It appears to me that we should definitely have a good answer for this
question before the specification reaches CR
given that the definition of ES6
Could someone point me to a discussion/reasoning behind why we're using
createdCallback as opposed to the constructor
as a way of instantiating a custom element?
It's so awkward to have a separate callback in the world where we have ES6
classes.
- R. Niwa
There were several threads around this in March/April, but the main gist is
that we can't allow running user code when the parser is building the tree,
and thus we would need to decouple the timing of the constructor being
called from the [[Construct]] internal method to make constructors
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
There were several threads around this in March/April, but the main gist is
that we can't allow running user code when the parser is building the tree,
and thus we would need to decouple the timing of the constructor
On Thu, Dec 5, 2013 at 9:03 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
There were several threads around this in March/April, but the main gist
is that we can't allow running user code when the parser is building the
tree,
On Dec 5, 2013, at 9:23 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Thu, Dec 5, 2013 at 9:03 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
There were several threads around this in March/April, but the main gist is
On 12/6/13 12:03 AM, Ryosuke Niwa wrote:
That sounds like an implementation detail of Blink/WebKit.
It seems like a pretty fundamental restriction for all current HTML
parsers. In particular, the HTML parsing algorithm has no provisions
for script mutating the DOM at random points in the
On Dec 5, 2013, at 10:44 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/6/13 12:03 AM, Ryosuke Niwa wrote:
That sounds like an implementation detail of Blink/WebKit.
It seems like a pretty fundamental restriction for all current HTML parsers.
In particular, the HTML parsing algorithm has
On Dec 5, 2013, at 10:58 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/6/13 1:49 AM, Ryosuke Niwa wrote:
Then how do we define a custom element using ES6 classes? Are we going to
not call the constructor?
An excellent question, indeed. I don't have a good answer for you.
It appears to
36 matches
Mail list logo
