Re: Writing spec algorithms in ES6?

2015-06-11 Thread Erik Arvidsson
Dare I say ecma-speak? (Maybe I got stockholm-syndrome?) On Thu, Jun 11, 2015 at 4:47 PM, Adam Klein ad...@chromium.org wrote: On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov dglaz...@google.com wrote: Folks, Many specs nowadays opt for a more imperative method of expressing normative

Re: Custom element design with ES6 classes and Element constructors

2015-01-15 Thread Erik Arvidsson
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

Re: Custom element design with ES6 classes and Element constructors

2015-01-12 Thread Erik Arvidsson
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

Re: Why can't we just use constructor instead of createdCallback?

2014-02-18 Thread Erik Arvidsson
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

Re: Why can't we just use constructor instead of createdCallback?

2014-02-18 Thread Erik Arvidsson
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,

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-14 Thread Erik Arvidsson
On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 13, 2014, at 4:01 PM, Alex Russell slightly...@google.com wrote: A closure is an iron-clad isolation mechanism for object ownership with regards to the closing-over function object. There's absolutely no

Re: Why can't we just use constructor instead of createdCallback?

2014-02-14 Thread Erik Arvidsson
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

Re: [webcomponents] Copying and Pasting a Web Component

2014-02-06 Thread Erik Arvidsson
All good points. One issue that we should track... On Thu, Feb 6, 2014 at 5:20 PM, Hajime Morrita morr...@google.com wrote: This seems related to discussion around selection [1]. My claim there was that the selection shouldn't cross shadow boundary, at least from the boundary crossing

Re: Why can't we just use constructor instead of createdCallback?

2014-01-10 Thread Erik Arvidsson
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

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

2013-12-10 Thread Erik Arvidsson
On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren ann...@annevk.nlwrote: I think Ryosuke has a point here though. ES6 brings subclassing to the platform, but are not even close to reimagining the platform in terms of that. ES6 does not bring sub classing to the table. It has been there

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

2013-12-10 Thread Erik Arvidsson
On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren ann...@annevk.nlwrote: On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an

Re: [webcomponents] Auto-creating shadow DOM for custom elements

2013-12-07 Thread Erik Arvidsson
Better APIs are better. What I think you (and Ryosuke) are trying to do is bundling. If shadow dom works without custom elements it should be its own spec. If template element works without shadow dom it should be its own spec. If custom elements work without shadow dom and templates don't bundle

Re: Why can't we just use constructor instead of createdCallback?

2013-12-06 Thread Erik Arvidsson
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

Re: Why can't we just use constructor instead of createdCallback?

2013-12-06 Thread Erik Arvidsson
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

Re: [HTML Imports]: what scope to run in

2013-11-19 Thread Erik Arvidsson
There seems to be some idea that HTML imports are supposed to do everything. The primary use case for HTML imports is a way to import DOM trees. Since HTML already have ways to embed CSS and script, HTML imports can act as a container format. But do not let perfect be the enemy of good. Lets not

Re: [webcomponents]: Declarative Custom Elements Take Umpteen, The Karate Kid Edition

2013-05-15 Thread Erik Arvidsson
Walking the ancestors from document.currentScript is a start. Is that sufficient or should we add a document.currentElement? On Wed, May 15, 2013 at 2:34 PM, Scott Miles sjmi...@google.com wrote: As long as there is a way to access the element from the script, I'm good. On Wed, May 15,

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

2013-04-30 Thread Erik Arvidsson
The thing about reprojection is that it makes implementers life harder but it makes developers life easy. I'd rather have us do the hard work here. For the record, we have two independent implementations of the Shadow DOM spec so that should debunk some of the myths that this is too hard to

Re: [webcomponents]: Re-imagining shadow root as Element

2013-04-16 Thread Erik Arvidsson
On Mon, Apr 15, 2013 at 11:05 PM, Dominic Cooney domin...@google.com wrote: On Thu, Apr 11, 2013 at 5:53 AM, Erik Arvidsson a...@chromium.org wrote: For the record I'm opposed to what you are proposoing. I don't like that you lose the symmetry between innerHTML and outerHTML. Sorry

Re: [webcomponents]: Platonic form of custom elements declarative syntax

2013-04-11 Thread Erik Arvidsson
Hi Allen, Fortunately the state of this is pretty close to what you are suggesting. We started of with the imperative solution and then went to look at a declarative version. At this point, the discussion got a bit side tracked. Lets back up and see what we have for the imperative version: class

Re: [webcomponents]: Re-imagining shadow root as Element

2013-04-10 Thread Erik Arvidsson
Maybe I'm missing something but we clearly don't want to include shadowroot in the general innerHTML getter case. If I implement input[type=range] using custom elements + shadow DOM I don't want innerHTML to show the internal guts. On Wed, Apr 10, 2013 at 2:30 PM, Scott Miles sjmi...@google.com

Re: [webcomponents]: Re-imagining shadow root as Element

2013-04-10 Thread Erik Arvidsson
put it there (as opposed to Shadow DOM intrinsic to a particular element type). With this inner/outer rule, all serialization cases I can think of work in a sane fashion, no lossiness. Scott On Wed, Apr 10, 2013 at 12:05 PM, Erik Arvidsson a...@chromium.org wrote: Maybe I'm missing

Re: [webcomponents]: Re-imagining shadow root as Element

2013-04-10 Thread Erik Arvidsson
of thumb is this: 'node.outerHTML' should produce markup that parses back into 'node' (assuming all dependencies exist). On Wed, Apr 10, 2013 at 12:15 PM, Erik Arvidsson a...@chromium.orgwrote: Once again, how would this work for input/video? Are you suggesting that `createShadowRoot` behaves

Re: [webcomponents]: Platonic form of custom elements declarative syntax

2013-04-10 Thread Erik Arvidsson
On Wed, Apr 10, 2013 at 4:43 PM, Rick Waldron waldron.r...@gmail.comwrote: A bigger issue with proposal is that the global object appears to be the element's instance object itself, which isn't going to work +1 I'm not sure that `this` was supposed to be the [[Global]] object? But agree with

Re: [webcomponents]: Invocation order of custom element readyCallback

2013-03-22 Thread Erik Arvidsson
On Fri, Mar 22, 2013 at 8:42 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Mar 22, 2013 at 6:27 AM, Hajime Morrita morr...@google.com wrote: So what about (B): Call x-child first and x-parent second? This solves the unreadified x-child problem. And you will have a parent that is not

Re: [webcomponents]: Making link rel=components produce DocumentFragments

2013-03-13 Thread Erik Arvidsson
Also, how would you resolve URLs. Can I use base? On Mar 12, 2013 10:22 PM, Dominic Cooney domin...@google.com wrote: On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov dglaz...@google.comwrote: Hi folks! Just had a quick discussion with Elliott and he suggested that instead of building

Re: [webcomponents]: HTMLElementElement missing a primitive

2013-03-08 Thread Erik Arvidsson
If you have a tag name it is easy to get the prototype. var tmp = elementElement.ownerDocument.createElement(tagName); var prototype = Object.getPrototypeOf(tmp); On Fri, Mar 8, 2013 at 12:16 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Mar 7, 2013 at 2:35 PM, Scott Miles

Re: [webcomponents]: HTMLElementElement missing a primitive

2013-03-08 Thread Erik Arvidsson
to do your own prototype marshaling, then won't this feature be missed in declarative form? I'm wary of defanging the declarative form completely. But I guess I want to break it down first before we build it up, if that makes any sense. Scott On Fri, Mar 8, 2013 at 9:55 AM, Erik Arvidsson

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

2013-03-06 Thread Erik Arvidsson
Inline On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita morr...@google.com wrote: One consequence is that it will become harder to cache (including negative cache) these values. We need to traverse the prototype chain in C++, which is typically slower than doing it in JS, on every lifecycle

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2013-02-26 Thread Erik Arvidsson
Also, if shadows are public by default the API to access the shadow is well defined. If shadows are private by default and components decide to expose the shadow ad hoc then there is no standardized API. On Feb 26, 2013 1:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Feb 26, 2013 at

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Erik Arvidsson
Yeah, this post does not really talk about syntax. It comes after a discussion how we could use ES6 class syntax. The ES6 classes have the same semantics as provided in this thread using ES5. On Thu, Feb 14, 2013 at 5:10 PM, Rick Waldron waldron.r...@gmail.comwrote: On Thu, Feb 14, 2013 at

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Erik Arvidsson
, 2013 at 2:21 PM, Rick Waldron waldron.r...@gmail.comwrote: On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson a...@chromium.orgwrote: Yeah, this post does not really talk about syntax. It comes after a discussion how we could use ES6 class syntax. The ES6 classes have the same semantics

Re: document.register and ES6

2013-02-08 Thread Erik Arvidsson
On Thu, Feb 7, 2013 at 11:51 PM, Scott Miles sjmi...@google.com wrote: P.P.S. Arv, do you have a preference from my three versions (or none of the above)? I prefer number 2. This is what we want for ES6 anyway. Both 1 and 3 makes me have to repeat myself. -- erik

Re: document.register and ES6

2013-02-08 Thread Erik Arvidsson
On Fri, Feb 8, 2013 at 11:54 AM, Scott Miles sjmi...@google.com wrote: The idea is supposed to be that 1 and 3 are only stopgaps until we get 'what we want'. In the future when you can derive a DOM element directly, both bits of extra code can fall away. Was that clear? Does it change anything

Re: document.register and ES6

2013-02-08 Thread Erik Arvidsson
On Fri, Feb 8, 2013 at 12:18 PM, Scott Miles sjmi...@google.com wrote: Sorry, I'm not quite following. 1. We cannot really extends anything else but HTMLElement/HTMLUnknownElement. 2. We cannot return the correct function object from document.register. I don't see why these are true? 1.

Re: document.register and ES6

2013-02-06 Thread Erik Arvidsson
On Tue, Feb 5, 2013 at 8:26 PM, Daniel Buchner dan...@mozilla.com wrote: I have two questions: Does this affect our ability to polyfill doc.register in current browsers? Good point. This is really important to us as well so we most likely need to tweak this to make sure it will work. Do we

Re: document.register and ES6

2013-02-06 Thread Erik Arvidsson
On Wed, Feb 6, 2013 at 5:27 AM, Boris Zbarsky bzbar...@mit.edu wrote: Note that I'm still checking how feasible this is in SpiderMonkey on any sort of finite timeframe, if we do decide to do this. Functions right now don't have a [[Construct]] member in spidermonkey that's stored on a

Re: document.register and ES6

2013-02-06 Thread Erik Arvidsson
On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles sjmi...@google.com wrote: Instead of passing in functions to document.register we can call methods on the custom element. My understanding is that the 'passing in functions' was a design decision, not a technical one. IOW, Dimitri spec'd it that

Re: document.register and ES6

2013-02-06 Thread Erik Arvidsson
On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles sjmi...@google.com wrote: Sorry, replace MyButton.super() with MyButton.super.call(this); On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles sjmi...@google.com wrote: So, neglecting issues around the syntax of document.register and the privatization of

Re: document.register and ES6

2013-02-06 Thread Erik Arvidsson
6, 2013 at 11:59 AM, Scott Miles sjmi...@google.com wrote: On Wed, Feb 6, 2013 at 11:18 AM, Erik Arvidsson a...@chromium.org wrote: On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles sjmi...@google.com wrote: Sorry, replace MyButton.super() with MyButton.super.call(this); On Wed, Feb 6, 2013

Re: document.register and ES6

2013-02-06 Thread Erik Arvidsson
On Wed, Feb 6, 2013 at 4:27 PM, Daniel Buchner dan...@mozilla.com wrote: So you're directly setting the user-added methods on matched elements in browsers that don't support proto, but what about accessors? If we modified the spec (as previously suggested) to take an *unbaked* prototype

document.register and ES6

2013-02-05 Thread Erik Arvidsson
The way document.register is currently proposed makes it future-hostile to ES6. I've heard several people from different organizations say that this is a blocking issue. Over the last couple of days we (me, Dimitri and others) have worked on some alterations to the current spec proposal. The

Re: document.register and ES6

2013-02-05 Thread Erik Arvidsson
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky bzbar...@mit.edu wrote: So in particular this allows creation of uninitialized instances in some sense, yes? Depends how much logic is put in the constructor vs @@create. For DOM Elements I think we want to put *all* the logic in create. @@create

Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like

2012-11-08 Thread Erik Arvidsson
addShadowRoot seem wrong to me to. Usually add* methods takes an argument of something that is supposed to be added to the context object. If we are going with a factory function I think that createShadowRoot is the right name even though create methods have a lot of bad history in the DOM APIs.

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-10 Thread Erik Arvidsson
On Thu, May 10, 2012 at 3:18 PM, Ian Hickson i...@hixie.ch wrote: Yes, I understand that. But what's the use case? http://code.google.com/p/dart/source/search?q=new%5CsElement%5C.html%5C%28origq=new%5CsElement%5C.html%5C%28btnG=Search+Trunk I'm sure you can find a bunch of jQuery usages too.

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-04-25 Thread Erik Arvidsson
My concern with the proposal is that it currently requires libraries to still do a regexp and special case frameset and html. We should imply the correct context for all tags in HTML5, not matter if we like them or not. I think it is important that any valid HTML with one top level node works and

Re: [webcomponents] HTML Parsing and the template element

2012-04-24 Thread Erik Arvidsson
On Tue, Apr 24, 2012 at 06:46, Brian Kardell bkard...@gmail.com wrote: I know of many, many templating systems and I have simply never (aside from MDV) seen it in exactly this light (that is templates actually embedded in others), regardless of whether those are for within the browser for

Re: [webcomponents] HTML Parsing and the template element

2012-04-24 Thread Erik Arvidsson
On Tue, Apr 24, 2012 at 12:00, Scott González scott.gonza...@gmail.com wrote: Are there other use cases that are trying to be solved with template? 3. Inert. You don't want to fetch resources at unresolved URLs. img src=/images/${user}.png 4. Selectors should not match content of the template

Re: [webcomponents] Considering declarative event handlers

2012-02-08 Thread Erik Arvidsson
On Tue Feb 07 11:41:24 GMT-800 2012, Dimitri Glazkov dglaz...@chromium.org wrote: The pros are: * It's declarative and intuitively logical I think this is a cons. Now you need both markup and code where you only had code before. This also does not scale very well and it brings us down the

Re: [webcomponents] HTML Parsing and the template element

2012-02-08 Thread Erik Arvidsson
On Wed, Feb 8, 2012 at 14:10, Adam Barth w...@adambarth.com wrote: ... Do you have a concrete example of where nested template declarations are required? When working with tree like structures it is comment to use recursive templates.

Re: innerHTML in DocumentFragment

2011-11-03 Thread Erik Arvidsson
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033360.html I'm in favor of making DocumentFragment.prototype.set innerHTML do the above. erik

Re: Is BlobBuilder needed?

2011-10-24 Thread Erik Arvidsson
Yeah, this is easily a win for the web platform. Smaller, more concise API. I like it. As Ojan said; Please use rest params here so that there is no need to create the extra array. erik On Mon, Oct 24, 2011 at 16:07, Rick Waldron waldron.r...@gmail.com wrote: From a real-world developer

Re: Is BlobBuilder needed?

2011-10-24 Thread Erik Arvidsson
On Mon, Oct 24, 2011 at 16:46, Tab Atkins Jr. jackalm...@gmail.com wrote: Easy.  The destructuring stuff proposed for ES lets you easily say things like: function(blobparts..., keywordargs) {  // blobparts is an array of all but the last arg  // keywordargs is the last arg } or even:

Re: Is BlobBuilder needed?

2011-10-24 Thread Erik Arvidsson
On Mon, Oct 24, 2011 at 19:23, Jonas Sicking jo...@sicking.cc wrote: On the topic of getting rid of BlobBuilder, do you have thoughts on losing the ability to back it by an on-disk file? I'm not sure I understand the problem. A Blob can also be backed by a on-disk file. Could you elaborate?

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Erik Arvidsson
On Thu, Oct 20, 2011 at 04:18, Alex Russell slightly...@google.com wrote: No we don't. The fact that there's someone else who has a handle to the list and can mutate it underneath you is a documentation issue, not a question of type...unless the argument is that the slots should be

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Erik Arvidsson
On Thu, Oct 20, 2011 at 04:37, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-10-20 13:18, Alex Russell wrote: On Thu, Oct 20, 2011 at 12:05 PM, Lachlan Huntlachlan.h...@lachy.id.au  wrote: We need NodeList separate from Array where they are live lists. No we don't. The fact that

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Erik Arvidsson
On Thu, Oct 20, 2011 at 04:49, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-10-20 13:35, Sean Hogan wrote: I wonder if anyone is relying on querySelectorAll() returning a StaticNodeList? Only if there are people out there using list.item(n) instead of list[n], or people extending

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Erik Arvidsson
On Thu, Oct 20, 2011 at 09:28, Boris Zbarsky bzbar...@mit.edu wrote: On 10/20/11 12:02 PM, Erik Arvidsson wrote: That is an ES violation. A non configurable, non writable data property is not allowed to change its value. It's not clear what that means in proxy-land; esp. since it's not clear

Re: QSA, the problem with :scope, and naming

2011-10-18 Thread Erik Arvidsson
On Tue, Oct 18, 2011 at 09:42, Alex Russell slightly...@google.com wrote: Ah, but we don't need to care what CSS thinks of our DOM-only API. We can live and let live by building on :scope and specifying find* as syntactic sugar, defined as:  HTMLDocument.prototype.find =  

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-10-11 Thread Erik Arvidsson
dglaz...@chromium.org wrote: On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson a...@chromium.org wrote: Splitting this up into two different things is great. The specific meaning of splitting up is where the things get interesting. As far as I understand Hixie's idea, the component (which

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-10-10 Thread Erik Arvidsson
Splitting this up into two different things is great. Allowing attaching an alternative shadow tree through CSS but disabling any JS to be run seems like the right thing to do. I'm also in favor of the is attribute. Even though I think that x-foo is more readable than div is=foo it is hard to

Re: Notes from a component model pow-wow

2011-09-20 Thread Erik Arvidsson
On Tue, Sep 20, 2011 at 19:47, Boris Zbarsky bzbar...@mit.edu wrote: A comment on use cases that was brought up over here. There's a use case that is not addressed by XBL1 and impossible to quite address in a JS library that goes as follows.  Say you have some data in a table.  Semantically

Re: [DOM4] Remove Node.isSameNode

2011-09-16 Thread Erik Arvidsson
I'm also in favor of removing this. This does more harm than good. Unfortunately I found ~200 uses of this in code search. http://www.google.com/codesearch#search/q=%5C.isSameNode%5C(%20lang:javascripttype=cs erik On Thu, Sep 15, 2011 at 00:33, Anne van Kesteren ann...@opera.com wrote:

Re: HTMLElement.register--giving components tag names

2011-08-31 Thread Erik Arvidsson
On Tue, Aug 30, 2011 at 22:33, Dominic Cooney domin...@chromium.org wrote: You will notice that this says nothing about how prototypes are wired up. It should. Maybe the argument to extend should have an optional second field, proto, that specifies the new methods/getters/setters that

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

2011-08-24 Thread Erik Arvidsson
On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root

Re: Model-driven Views

2011-04-27 Thread Erik Arvidsson
On Wed, Apr 27, 2011 at 08:33, Olli Pettay olli.pet...@helsinki.fi wrote: Not sure why this had some relation with XBL. Unless you are planning to put the template based DOM nodes to anonymous DOM. The relation to XBL is that XBL has a template element and inside it you can bind attributes and

Re: Can we remove forminput and formchange events and related dispatch methods?

2010-10-22 Thread Erik Arvidsson
On Oct 22, 2010 2:00 AM, Anne van Kesteren ann...@opera.com wrote: Yeah, I don't mind moving these features to libraries. Anyone implemented them apart from Opera? Neither WebKit nor Gecko implements it: https://bugs.webkit.org/show_bug.cgi?id=26141

Re: Can we remove forminput and formchange events and related dispatch methods?

2010-10-22 Thread Erik Arvidsson
On Fri, Oct 22, 2010 at 12:09, Jonas Sicking jo...@sicking.cc wrote: This means that we should also remove dispatchFormInput/dispatchFormChange from the HTML5 spec, right? That was my intention and the subject hints at that. Sorry for not including it in the body as well. -- erik

Can we remove forminput and formchange events and related dispatch methods?

2010-10-21 Thread Erik Arvidsson
The forminput and formchange events are dispatched on all resettable elements in a form when any element associated with the form dispatches an input or a change event. Is this case really worth the cost of increasing the size of the API when it can easily be achieved with capturing events? erik

Re: DOM collections index out of bounds and JavaScript.

2010-10-19 Thread Erik Arvidsson
On Tue, Oct 19, 2010 at 09:50, Garrett Smith dhtmlkitc...@gmail.com wrote: ... CSSStyleDeclaration. What about the other collection objects? HTML5 says that collections are now callable and specifies that indexed property access on collections returns null. But what about other APIs such as

DOM collections index out of bounds and JavaScript.

2010-10-18 Thread Erik Arvidsson
When DOM was first spec'ed the collection interfaces all had some kind of item method. These methods sometimes return like null[1] and sometimes other values such as an empty string [2]. The JavaScript bindings for these allows us to use indexed getters instead of calling the item method. The

Re: 'scroll' and 'resize' events

2009-06-24 Thread Erik Arvidsson
On Wed, Jun 17, 2009 at 11:47, William Edneybed...@technicalpursuit.com wrote: Folks - Not sure this is relevant, but I'm tracking/contributing to the following two bugs around 'resize' events: One for Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=227495 and one for Webkit:

Re: 'scroll' and 'resize' events

2009-06-24 Thread Erik Arvidsson
On Wed, Jun 17, 2009 at 11:47, William Edneybed...@technicalpursuit.com wrote: Folks - Not sure this is relevant, but I'm tracking/contributing to the following two bugs around 'resize' events: One for Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=227495 and one for Webkit:

Input events, checkboxes and radio buttons

2009-06-19 Thread Erik Arvidsson
The HTML5 spec says to fire the input event when the user changes a radio button or a checkbox. However, the spec says When the input event applies, any time the user causes the element's *value* to change. For input[type=radio] and input[type=checkbox] the input event should be fired any time the