Re: [webcomponents]: Platonic form of custom elements declarative syntax
*Shouldn't we prevent such a thing? I can't redefine a button's template. There should be some guarantee I'm getting the same x-foo (API, look and feel) after it's been registered. What's the use case for swapping in a new template?* We've come across various occasions where we have a custom element, let's say it's an x-todo, that has multiple content/view states (not something achievable by a simple class/style change). There may be 200 of these elements in a summary view in the list panel of the page in question. When the user performs an action that requires an x-todo in summary view to display a more complex, detail view, we've found that the easiest way to reuse elements, make the change in the least amount of code, and avoid the cumbersome and repetitive paradigm of creating specific x-todo-summary and x-todo-detail elements for this purpose, is to simply have two different template elements for each view type. The views can be radically different in structure and visual style - yet thanks to our ability to simply swap out the template association on the specific x-todo in question, the whole thing is a snap: myTodoElement.template = 'detail-template'; Does this help clarify a bit? On Wed, Apr 10, 2013 at 10:05 PM, Eric Bidelman ericbidel...@google.comwrote: Have to lean towards Raf and Daniel on this one. Making a element registation a concern of template doesn't feel right. In this case, explicit structure and a few more characters is worth it. On Wed, Apr 10, 2013 at 9:00 PM, Daniel Buchner dan...@mozilla.comwrote: It's incredibly important that we agree that association of a template with element happens on the element side, something like: element template=foo-template (or by placing the template inside element, if that is the API we want). I don't think this part is opinion, but because doing the reverse - marking on the template which element it refers to - hinders a few valid use-cases: - one template from being used by many different elements - changing a template association on a single instance of an element type - say you have an x-foo on the page that you want to switch template associations on, but not for every other x-foo in the document. Wouldn't this case be far more clear cut if you could just query for the element and change some property? For instance: fooElement.template = 'foo-template-2'; Boom! This particular foo element just switched templates. Shouldn't we prevent such a thing? I can't redefine a button's template. There should be some guarantee I'm getting the same x-foo (API, look and feel) after it's been registered. What's the use case for swapping in a new template? - On Wed, Apr 10, 2013 at 8:19 PM, Daniel Buchner dan...@mozilla.comwrote: Here are a few (compelling?) answers/arguments: 1. Style elements had never done this before, yet it rocks socks: style scoped 2. It would be new for script elements, but hardly new for other elements. There are plenty of elements that have various behaviors or visual representations only when placed inside specific elements. Given this is already an advanced web API, I'm not sure a little upfront learning is a huge concern. We could even allow for this, given the paradigm is already established: script scoped *// could scope 'this' ref to the parentNode* 3. Are you referring to template attachment here? If so, I agree, thus the proposal I submitted allows for both ( https://gist.github.com/csuwldcat/5360471). If you want your template automatically associated with your element, put it inside, if not, you can specify which template a custom element should use by reference to its ID. On Wed, Apr 10, 2013 at 8:00 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Apr 10, 2013 at 6:51 PM, Dimitri Glazkov dglaz...@google.comwrote: On Wed, Apr 10, 2013 at 6:38 PM, Rick Waldron waldron.r...@gmail.com wrote: Everyone's answer to this should be no; changing the expected value of the top level this, in some magical way, simply won't work. Can you explain why you feel this way? 1) Because script has never done this before, so it better be compelling. 2) Because causing |this| to change by moving the script tag in the HTML or adding a layer of elements etc seems likely to cause hard to understand bugs. 3) Forcing the binding based on position is inflexible. To be sure this is implicit-declarative vs explicit-imperative bias, not evidence. Oh, sorry you were asking Rick. jjb
Re: [webcomponents]: de-duping in HTMLImports
I don't believe it's *needed* exactly, but we imagined somebody wanting to import HTML, use it destructively, then import it again. That does sound totally crazy. Can you give an example as to what someone might want to do with this? Maybe it's not totally crazy and I'm just not being creative enough. Then I guess I need this spec'd :) I'd rather de-duping be a nice optimization performed by the user-agent and hidden from me entirely. Although, now I'm really curious about an argument for opting out of de-duping. On Wed, Apr 10, 2013 at 11:56 AM, Scott Miles sjmi...@google.com wrote: Interesting. Why do you need [attribute to opt-out of deduping]? I don't believe it's *needed* exactly, but we imagined somebody wanting to import HTML, use it destructively, then import it again. That may be totally crazy. :) Scott On Wed, Apr 10, 2013 at 11:50 AM, Dimitri Glazkov dglaz...@google.comwrote: On Tue, Apr 9, 2013 at 11:42 AM, Scott Miles sjmi...@google.com wrote: Duplicate fetching is not observable, but duplicate parsing and duplicate copies are observable. Preventing duplicate parsing and duplicate copies allows us to use 'imports' without a secondary packaging mechanism. For example, I can load 100 components that each import 'base.html' without issue. Without this feature, we would need to manage these dependencies somehow; either manually, via some kind of build tool, or with a packaging system. Then I guess I need this spec'd :) If import de-duping is possible, then ideally there would also be an attribute to opt-out. Interesting. Why do you need it? :DG
Re: [webcomponents]: de-duping in HTMLImports
On Thu, Apr 11, 2013 at 12:33 AM, Angelina Fabbro angelinafab...@gmail.comwrote: I don't believe it's *needed* exactly, but we imagined somebody wanting to import HTML, use it destructively, then import it again. That does sound totally crazy. Can you give an example as to what someone might want to do with this? Maybe it's not totally crazy and I'm just not being creative enough. You have to assume some facts not in evidence, but imagine an import that runs script and generates content based on the current time, or some other dynamic. Then imagine a page injects a link tag, based on some event, to import the latest content. Then I guess I need this spec'd :) I'd rather de-duping be a nice optimization performed by the user-agent and hidden from me entirely. Although, now I'm really curious about an argument for opting out of de-duping. If there is no automatic de-duping then the author has to take care to specifically avoid duplication in various cases. Therefore, it cannot be an optimization, in the sense that it's not optional. It has to be required by the spec or you cannot rely on it. On Wed, Apr 10, 2013 at 11:56 AM, Scott Miles sjmi...@google.com wrote: Interesting. Why do you need [attribute to opt-out of deduping]? I don't believe it's *needed* exactly, but we imagined somebody wanting to import HTML, use it destructively, then import it again. That may be totally crazy. :) Scott On Wed, Apr 10, 2013 at 11:50 AM, Dimitri Glazkov dglaz...@google.comwrote: On Tue, Apr 9, 2013 at 11:42 AM, Scott Miles sjmi...@google.com wrote: Duplicate fetching is not observable, but duplicate parsing and duplicate copies are observable. Preventing duplicate parsing and duplicate copies allows us to use 'imports' without a secondary packaging mechanism. For example, I can load 100 components that each import 'base.html' without issue. Without this feature, we would need to manage these dependencies somehow; either manually, via some kind of build tool, or with a packaging system. Then I guess I need this spec'd :) If import de-duping is possible, then ideally there would also be an attribute to opt-out. Interesting. Why do you need it? :DG
What will be the query language for IndexedDb
By all means take away WebSQL the database but you should then add SQL (the query language) to whatever you put in its place Without a standardised query language a data store is, well, just a bucket of bits. Whether it is human readable, key-value paired or not Regards Rob von Nesselrode
Re: [webcomponents]: Platonic form of custom elements declarative syntax
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 MyElement extends HTMLElement {
constructor() {
...
}
insertedCallback() {
// now I'm in document
}
attributeChangedCallback(name, value) {
// ...
}
doFunkyThing() {
// ...
}
}
// And tell the browser about this new shiny element
document.register('my-element, MyElement);
Fast forward...
For the declarative version we want to be able to associate a template
element to be used as the shadow dom for the custom element. We went around
in circles here and this thread was an attempt to start at a different
starting point to see where we would end up.
We initially had (plus/minus irrelevant details)
element name=my-element
template
This is my shadow DOM
content/content
/template
script
class MyElement extends HTMLElement { ... }
// We need a convenient way to register ('my-element, MyElement) here
/script
/element
More inline...
On Thu, Apr 11, 2013 at 2:14 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Apr 10, 2013, at 8:47 PM, Rick Waldron wrote:
cc Allen Wirfs-Brock, Dave Herman
Allen, Dave
Would you mind reading back through the thread to provide some deeper
insight? Thanks
Rick
ECMAScript really has a very simply concept of 'this' out-side of a
function. It is a reference to the global object. In all other cases
'this' occurs within a function body and is bound as part of a function
innovation. It would be a significant change to the ECMAScript semantics
that are applied to 'this' the content of script tags. I'm sure, it
would only cause confusion.
Unfortunately NodeJS broke this invariant already. `this` inside a module
that has been required is a not the [[Global]] object. This has caused me a
lot of personal porting pain so I agree we must not break this invariant on
the web.
I'm not at all up on the details and subtitles of what you are trying to
do with your tempaltes, but regardless, I want to suggest an alternative
approach that I'm pretty sure in the long run would be more natural for
JavaScript programmers.
It seems to me, what you are doing with templates is allowing user to
define new kinds of DOM nodes and that when you stamp out a template you
are instantiating new instances of that kind of node. In programming
language terms, you are enabling markup authors to declarative define new
classes of DOM nodes and to create instance of those classes. The script
behaviors you need to associate with a template are essentially the
methods of the user defined classes. Rather than twisting around the
interpretation of 'this' in template script blocks and inventing other
one-off extensions, it would be much better to recognize this class-based
approach and just let the user define the class.
Using ES6 syntax this could be very easy:
template bindtotagname=my_yay
shadowroot
divYay!/div
/shadowroot
script
class My_yay extends TemplatedNode {
constructor () {
// runs when instances are created, can create per
instance properties
// can be left out if nothing special is required
}
whenBond(...args) {
super(...args); invoke default behavior inherited
from TemplatedNode
// my_yay specific behavior
// in methods 'this' binds to an instance
}
anotherMethods() { // other instance methods, properties
of My_yay.prototype
}
static anotherStaticMethods() { } //properties of My_yay
}
/script
/template
Many details to work out, but I hope the intent is clear. You just define
a JS class corresponding to the template instances. There may be a standard
template interface with methods such as withBond that are support. Defaut
implementations can be provided by a built-in super class.
This can all be expresses, but less clearly and concisely using ES3/5
syntax. But since we are talking about a new HTML feature, I'd recommend
being the first major HTMLfeature to embrace ES6 class syntax. The class
extension in ES6 are quite stable and quite easy to implement. I'm pretty
sure they will begin appearing in browsers sometime in the next 6 months.
If webcomponents takes a dependency upon them, it would probably further
speed up their implementation.
The problem here is how do you register `My_yay` as the class that goes
with the tag name `my_yay`. One option could be to use the completion value
but it seems too magical/unreliable. It also does not scale well. I would
like us to be able to put
Re: [webcomponents]: Platonic form of custom elements declarative syntax
On Thu, Apr 11, 2013 at 7:57 AM, Erik Arvidsson a...@chromium.org wrote:
The problem here is how do you register `My_yay` as the class that goes
with the tag name `my_yay`. One option could be to use the completion
value but it seems too magical/unreliable. It also does not scale well. I
would like us to be able to put all custom component classes in a single
js file:
element name=my-foo
...
/element
element name=my-bar
...
/element
element name=my-baz
...
/element
script src=my-elements.js/script
// my-elements.js
someDocument.querySelector('[name=my-foo]').registerConstructor(MyFoo);
someDocument.querySelector('[name=my-bar]').registerConstructor(MyBar);
someDocument.querySelector('[name=my-baz]').registerConstructor(MyBaz);
This calls out for a less verbose and more DRY API.
To me this seems to defeat modularity. Force me to organize all of MyFoo
JS/HTML/CSS together and separate from MyBar and MyBaz. I already can
create a big messy pile. Help me clean up my room.
jjb
Re: [webcomponents]: Platonic form of custom elements declarative syntax
On 4/11/13 12:23 PM, Allen Wirfs-Brock wrote: So why don't you make register a static method on HTMLElement and then define the element semantics so it automatically does: MyElement.register() This would normally invoke the inherited static method I lost track of something here. Why would it do that? Does MyElement have Element on its proto chain? MyElement.prototype certainly has Element.prototype on _its_ proto chain, but that's a separate concern from what happens with the interface objects... Is this something that ES6 classes define differently from current WebIDL and implementations, and if so, do we need to align the two somehow? -Boris
Re: [webcomponents]: Platonic form of custom elements declarative syntax
On Apr 11, 2013, at 9:32 AM, Boris Zbarsky wrote:
On 4/11/13 12:23 PM, Allen Wirfs-Brock wrote:
So why don't you make register a static method on HTMLElement and then
define the element semantics so it automatically does:
MyElement.register()
This would normally invoke the inherited static method
I lost track of something here. Why would it do that? Does MyElement have
Element on its proto chain? MyElement.prototype certainly has
Element.prototype on _its_ proto chain, but that's a separate concern from
what happens with the interface objects... Is this something that ES6
classes define differently from current WebIDL and implementations, and if
so, do we need to align the two somehow?
Yes ES6 has class-side inheritance. The ES5 equivalent for:
class Sub extends Super {
constructor() {/*constructor body */ }
method1 () {}
static method2 {}
}
is:
function Sub() {/*constructor body */ }
Sub.__proto__ = Super;
Sub.prototype = Object.create(Super.prototype);
Sub.prototype.method1 = function method1() {};
Sub.method2 = function method2 () {};
Sub.foo looks first looks for a own property on Sub, then on Super, etc.
Allen
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On Thu, Apr 11, 2013 at 6:23 PM, Anne van Kesteren ann...@annevk.nl wrote: So how much can we still change fullscreen? It should really use futures. It seems Gecko and Chrome have it prefixed, barring objections I'm going to change fullscreen to use futures. That will be way better. -- http://annevankesteren.nl/
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On 4/11/13 1:29 PM, Anne van Kesteren wrote: On Thu, Apr 11, 2013 at 6:23 PM, Anne van Kesteren ann...@annevk.nl wrote: So how much can we still change fullscreen? It should really use futures. It seems Gecko and Chrome have it prefixed Isn't the thing that matters whether _sites_ have it unprefixed? -Boris
Re: What will be the query language for IndexedDb
On Wed, Apr 10, 2013 at 6:53 PM, Rob VonNesselrode rob_vonnesselr...@sitechcs.com wrote: By all means take away WebSQL the database but you should then add SQL (the query language) to whatever you put in its place Without a standardised query language a data store is, well, just a bucket of bits. Whether it is human readable, key-value paired or not The query language is javascript, along with the tools that IndexedDB gives you like indexes, as Aaron points out. A higher-level query language might be defined in the future, but it's not planned at the moment. ~TJ
Re: [webcomponents]: Platonic form of custom elements declarative syntax
On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote: Yes ES6 has class-side inheritance OK. Should we be doing that with WebIDL interface objects, perhaps? It would certainly make sense to me to do that, as long we we don't run into web compat issues. -Boris
Re: RfC: LCWD of API for Media Resources 1.0; deadline June 3
On Thu, Apr 11, 2013 at 5:21 PM, Arthur Barstow art.bars...@nokia.com wrote: The Media Annotations WG decided to return its API for Media Resources 1.0 spec to LCWD and they have explicitly asked WebApps to review the new LC: http://www.w3.org/TR/2013/WD-mediaont-api-1.0-20130411/ 1) As far as I can tell this an API for extracting EXIF data and such. 2) From the JavaScript examples it looks like the API is pretty horrible. I'm wondering if there's a) implementors that have been following this at all and b) where the other proposals are at. I'm pretty sure I've seen some much simpler API ideas come by. I wonder what happened to those. -- http://annevankesteren.nl/
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On Thu, Apr 11, 2013 at 6:38 PM, Boris Zbarsky bzbar...@mit.edu wrote: Isn't the thing that matters whether _sites_ have it unprefixed? I don't know. I believe the browsers don't match each other exactly either so there's probably some wiggle room. I suspect transitioning at this point to be hard whatever we do, which is probably why it has not happened yet. Also, we dispatch fullscreenchange to more than just the requesting document. We could still get rid of fullscreenerror though and have the simple non-iframe case be much more friendly towards developers. -- http://annevankesteren.nl/
[webcomponents]: Blocking custom elements on ES6, was: Platonic form of custom elements declarative syntax
Hello, TC39 peeps! I am happy to have you and your expertise here. On Wed, Apr 10, 2013 at 11:14 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: This can all be expresses, but less clearly and concisely using ES3/5 syntax. But since we are talking about a new HTML feature, I'd recommend being the first major HTMLfeature to embrace ES6 class syntax. The class extension in ES6 are quite stable and quite easy to implement. I'm pretty sure they will begin appearing in browsers sometime in the next 6 months. If webcomponents takes a dependency upon them, it would probably further speed up their implementation. We simply can't do this :-\ I see the advantages, but the drawbacks of tangled timelines and just plain not being able to polyfill custom elements are overwhelming. Right now, there are at least two thriving polyfills for custom elements (https://github.com/toolkitchen/CustomElements and https://github.com/mozilla/web-components), and they contribute greatly by both informing the spec development and evangelizing the concepts with web developers. To state simply: We must have support both ES3/5 and ES6 for custom elements. :DG
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib sch...@google.com wrote: I argue on that issue that we should not bubble the event and have the handler on document only. Pointer lock doesn't have as much legacy spec churn as fullscreen, but I think we're in a position to have both of them be cleaned up before un-prefixing. So how much can we still change fullscreen? It should really use futures. -- http://annevankesteren.nl/
Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec
On Sat, Mar 16, 2013 at 8:05 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Mar 15, 2013 at 6:57 PM, Vincent Scheib sch...@google.com wrote: I have added onipointerlockchange and onpointerlockerror to the partial document IDL in the pointer lock specification. Webkit currently only defines these event handler attributes on document. Unless a reason is raised to add them elsewhere, I do not plan to add additional attributes elsewhere, for reasons discussed in fullscreen specification primarily regarding the confusing when releasing exiting due to an element being removed from the DOM, and confusion over multiple listener points. https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html https://dvcs.w3.org/hg/pointerlock/diff/86bc101925d8/index.html FWIW, in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20637 Ian argues for Window/body due to their bubbling nature. I argue on that issue that we should not bubble the event and have the handler on document only. Pointer lock doesn't have as much legacy spec churn as fullscreen, but I think we're in a position to have both of them be cleaned up before un-prefixing.
Re: RfC: LCWD of API for Media Resources 1.0; deadline June 3
On 04/11/2013 07:00 PM, Anne van Kesteren wrote: On Thu, Apr 11, 2013 at 5:21 PM, Arthur Barstow art.bars...@nokia.com wrote: The Media Annotations WG decided to return its API for Media Resources 1.0 spec to LCWD and they have explicitly asked WebApps to review the new LC: http://www.w3.org/TR/2013/WD-mediaont-api-1.0-20130411/ 1) As far as I can tell this an API for extracting EXIF data and such. 2) From the JavaScript examples it looks like the API is pretty horrible. I'm wondering if there's a) implementors that have been following this at all and b) where the other proposals are at. I'm pretty sure I've seen some much simpler API ideas come by. I wonder what happened to those. For reference: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jun/0111.html. HTH Ms2ger
Re: [webcomponents]: Blocking custom elements on ES6, was: Platonic form of custom elements declarative syntax
On Apr 11, 2013, at 10:59 AM, Dimitri Glazkov wrote:
Hello, TC39 peeps! I am happy to have you and your expertise here.
On Wed, Apr 10, 2013 at 11:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
This can all be expresses, but less clearly and concisely using ES3/5
syntax. But since we are talking about a new HTML feature, I'd recommend
being the first major HTMLfeature to embrace ES6 class syntax. The class
extension in ES6 are quite stable and quite easy to implement. I'm pretty
sure they will begin appearing in browsers sometime in the next 6 months. If
webcomponents takes a dependency upon them, it would probably further speed
up their implementation.
We simply can't do this :-\ I see the advantages, but the drawbacks of
tangled timelines and just plain not being able to polyfill custom
elements are overwhelming. Right now, there are at least two thriving
polyfills for custom elements
(https://github.com/toolkitchen/CustomElements and
https://github.com/mozilla/web-components), and they contribute
greatly by both informing the spec development and evangelizing the
concepts with web developers.
To state simply: We must have support both ES3/5 and ES6 for custom elements.
:DG
ES6 classes can be pollyfilled:
class Sub extends Super {
constructor() {/*constructor body */ }
method1 () {}
static method2 {}
}
is:
function Sub() {/*constructor body */ }
Sub.__proto__ = Super;
Sub.prototype = Object.create(Super.prototype);
Sub.prototype.method1 = function method1() {};
Sub.method2 = function method2 () {};
Allen
Re: RfC: LCWD of API for Media Resources 1.0; deadline June 3
On Thu, Apr 11, 2013 at 6:13 PM, Ms2ger ms2...@gmail.com wrote: For reference: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jun/0111.html. Which seems to lead to http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/html/nsIDOMHTMLMediaElement.idl#97 which is just exposing whatever data there is, probably as long as the data format is supported. Not really sure what to make out of that. Also, this API is synchronous. -- http://annevankesteren.nl/
Re: [webcomponents]: Blocking custom elements on ES6, was: Platonic form of custom elements declarative syntax
Err...polyfill doesn't mean you can do something via a different route that
produces a similar outcome, it means you back fill the API so that you can
use 1:1 syntax that never needs to know if the evn supports the native
underlying API or not.
I don't mean to disparage ES6 - as a former developer of the MooTools
framework (the most well recognized Class-y JS lib), I have a special
affinity for seeing a great Class abstraction land in JS. However, there's
no reason to hitch our wagon to ES6 and a pseudo-not-quite-fill. If people
want to use ES6 for defining Custom Elements, they can start doing so when
it is available in their target environment.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Thu, Apr 11, 2013 at 11:10 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Apr 11, 2013, at 10:59 AM, Dimitri Glazkov wrote:
Hello, TC39 peeps! I am happy to have you and your expertise here.
On Wed, Apr 10, 2013 at 11:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
This can all be expresses, but less clearly and concisely using ES3/5
syntax. But since we are talking about a new HTML feature, I'd recommend
being the first major HTMLfeature to embrace ES6 class syntax. The class
extension in ES6 are quite stable and quite easy to implement. I'm pretty
sure they will begin appearing in browsers sometime in the next 6 months.
If webcomponents takes a dependency upon them, it would probably further
speed up their implementation.
We simply can't do this :-\ I see the advantages, but the drawbacks of
tangled timelines and just plain not being able to polyfill custom
elements are overwhelming. Right now, there are at least two thriving
polyfills for custom elements
(https://github.com/toolkitchen/CustomElements and
https://github.com/mozilla/web-components), and they contribute
greatly by both informing the spec development and evangelizing the
concepts with web developers.
To state simply: We must have support both ES3/5 and ES6 for custom
elements.
:DG
ES6 classes can be pollyfilled:
class Sub extends Super {
constructor() {/*constructor body */ }
method1 () {}
static method2 {}
}
is:
function Sub() {/*constructor body */ }
Sub.__proto__ = Super;
Sub.prototype = Object.create(Super.prototype);
Sub.prototype.method1 = function method1() {};
Sub.method2 = function method2 () {};
Allen
Re: [webcomponents]: Platonic form of custom elements declarative syntax
On 4/11/13 12:55 PM, Boris Zbarsky wrote: On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote: Yes ES6 has class-side inheritance OK. Should we be doing that with WebIDL interface objects, perhaps? It would certainly make sense to me to do that, as long we we don't run into web compat issues. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=860841 with a patch to do this. The specific behavior I'm implementing is that the prototype of the interface object for interface X is the interface object of the nearest ancestor of X that has one, and Function.prototype if there is no such ancestor. So for example, with that patch Object.getPrototypeOf(HTMLElement) == Element, and Object.getPrototypeOf(XMLHttpRequest) == EventTarget. Note that this doesn't quite match the proto chain, because Object.getPrototypeOf(XMLHttpRequest.prototype) is the prototype object for the XMLHttpRequestEventTarget interface, but that interface is [NoInterfaceObject]. -Boris
Re: [webcomponents]: Platonic form of custom elements declarative syntax
On Apr 11, 2013, at 12:04 PM, Boris Zbarsky wrote: On 4/11/13 12:55 PM, Boris Zbarsky wrote: On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote: Yes ES6 has class-side inheritance OK. Should we be doing that with WebIDL interface objects, perhaps? It would certainly make sense to me to do that, as long we we don't run into web compat issues. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=860841 with a patch to do this. The specific behavior I'm implementing is that the prototype of the interface object for interface X is the interface object of the nearest ancestor of X that has one, and Function.prototype if there is no such ancestor. So for example, with that patch Object.getPrototypeOf(HTMLElement) == Element, and Object.getPrototypeOf(XMLHttpRequest) == EventTarget. Note that this doesn't quite match the proto chain, because Object.getPrototypeOf(XMLHttpRequest.prototype) is the prototype object for the XMLHttpRequestEventTarget interface, but that interface is [NoInterfaceObject]. -Boris That sounds about right. In ES6 you will still be able to wire-up arbitrary [[Prototype]] chains on both the instance and constructor-side using Object.create, __proto__ (now part of the standard), and ossibly crazy things via Proxy. But the most concise way to define class-like abstractions is going to be via class declaration. It seem quite desirable that the normal case for such abstractions specified via WebIDL is that they simply follow the ES6 class pattern. Exceptions are fine for legacy or special circumstances. Allen
