Re: App-to-App interaction APIs - one more time, with feeling

2015-10-21 Thread Daniel Buchner
ction and cursor which protocol handlers do not seem to be ready to perform. However, I believe that copy-and-paste (and drag-and-drop) is part of an app-to-app interaction APIs. Paul Daniel Buchner<mailto:dabuc...@microsoft.com> 20 octobre 2015 18:36 I’m trying to understand exac

RE: App-to-App interaction APIs - one more time, with feeling

2015-10-20 Thread Daniel Buchner
l From: Paul Libbrecht [mailto:p...@hoplahup.net] Sent: Sunday, October 18, 2015 9:38 AM To: Daniel Buchner <dabuc...@microsoft.com> Cc: public-webapps@w3.org Subject: Re: App-to-App interaction APIs - one more time, with feeling Daniel, as far as I can read the post, copy-and-paste-interoperabili

RE: App-to-App interaction APIs - one more time, with feeling

2015-10-15 Thread Daniel Buchner
<art.bars...@gmail.com> Cc: Daniel Buchner <dabuc...@microsoft.com>; public-webapps@w3.org Subject: Re: App-to-App interaction APIs - one more time, with feeling 2015/10/15 下午11:58於 "Arthur Barstow" <art.bars...@gmail.com<mailto:art.bars...@gmail.com>>寫道: > &

Re: [HTML Imports]: Sync, async, -ish?

2013-11-27 Thread Daniel Buchner
Right on Dimitri, I couldn't agree more. It seems like an involved (but highly beneficial) pursuit - but heck, maybe we'll find an answer quickly, let's give it a shot! Alex, I completely agree that declarative features should play a huge role in the solution, and I love the power/granularity

Re: [HTML Imports]: Sync, async, -ish?

2013-11-27 Thread Daniel Buchner
for the rest. A complex declarative solution seems like the worst of both. HTH, jjb On Wed, Nov 27, 2013 at 11:50 AM, Daniel Buchner dan...@mozilla.comwrote: Right on Dimitri, I couldn't agree more. It seems like an involved (but highly beneficial) pursuit - but heck, maybe we'll find an answer quickly

Re: [HTML Imports]: Sync, async, -ish?

2013-11-22 Thread Daniel Buchner
in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's

Re: [HTML Imports]: Sync, async, -ish?

2013-11-22 Thread Daniel Buchner
at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.

Re: [HTML Imports]: Sync, async, -ish?

2013-11-22 Thread Daniel Buchner
, Nov 22, 2013 at 9:05 AM, Jonas Sicking jo...@sicking.cc wrote: On Nov 22, 2013 8:24 AM, Daniel Buchner dan...@mozilla.com wrote: Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync

Re: [HTML Imports]: Sync, async, -ish?

2013-11-21 Thread Daniel Buchner
. If the parser finds custom elements in the page that match user-defined elements tag names, it would block rendering until the associated link import has finished loading and registering the containing custom elements. Thoughts? - Daniel On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner dan

Re: [HTML Imports]: Sync, async, -ish?

2013-11-21 Thread Daniel Buchner
Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.

Re: [HTML Imports]: Sync, async, -ish?

2013-11-21 Thread Daniel Buchner
I don't see this solution scaling at all. Imports are a tree. If you have any import that includes any other import, now the information about what tags to wait for has to be duplicated along every node in that tree. If a library author chooses to make any sort of all-in-one import to

Re: [HTML Imports]: Sync, async, -ish?

2013-11-20 Thread Daniel Buchner
Dimitri: right on. The use of script-after-import is the forcing function in the blocking scenario, not imports. Let's not complicate the new APIs and burden the overwhelming use-case to service folks who intend to use the technology in alternate ways. For my bit, as long as the size of the

Re: [HTML Imports]: Sync, async, -ish?

2013-11-20 Thread Daniel Buchner
On Nov 20, 2013 11:07 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com wrote: Dimitri: right on. The use of script-after-import is the forcing function in the blocking scenario, not imports. Yes. Let's

Re: [webcomponents] Per-type ready event for Custom Elements

2013-09-28 Thread Daniel Buchner
WebComponentsReady is an event in the Polymer stack that fires when all known registered custom elements are ready for interaction - X-Tag has similar event (now just a hook into the polyfill's) called DOMComponentsLoaded. Being notified that all elements in source are ready for interaction is

Re: [webcomponents] Per-type ready event for Custom Elements

2013-09-27 Thread Daniel Buchner
I don't see any compelling reason not to provide both. Let's not mistake an appeal for a simple, backwards-compatible allowance, as a slight to Promises ;) On Fri, Sep 27, 2013 at 7:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 27, 2013 at 1:52 AM, Daniel Buchner dan

Re: [webcomponents] Per-type ready event for Custom Elements

2013-09-27 Thread Daniel Buchner
, are not altogether convincing points (which is of course my opinion, I welcome yours). On Fri, Sep 27, 2013 at 8:02 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 27, 2013 at 10:56 AM, Daniel Buchner dan...@mozilla.com wrote: I don't see any compelling reason not to provide both. Twice

[webcomponents] Per-type ready event for Custom Elements

2013-09-26 Thread Daniel Buchner
We're seeing issues with custom element ready state awareness under various common async load patterns like AMD, CommonJS, etc. Essentially, when a developer brings in their definitions via one of these systems, the DOMComponentsLoaded/WebComponentsReady event has already fired, leaving them with

Re: [webcomponents] Per-type ready event for Custom Elements

2013-09-26 Thread Daniel Buchner
after the promise has been fulfilled and then still get called back. That sounds like it would be helpful for those users. I believe the new font load events spec is making good use of them for exactly this purpose. On 27 Sep 2013, at 01:29, Daniel Buchner dan...@mozilla.com wrote

Re: element Needs A Beauty Nap

2013-08-13 Thread Daniel Buchner
I concur. On hold doesn't mean forever, and the imperative API affords us nearly identical feature capability. Nailing the imperative and getting the APIs to market is far more important to developers at this point. On Aug 12, 2013 4:46 PM, Alex Russell slightly...@google.com wrote: As discussed

Re: element Needs A Beauty Nap

2013-08-13 Thread Daniel Buchner
document - let's not throw the baby out with the bath water (maybe this is already the thinking?) - Daniel On Tue, Aug 13, 2013 at 8:06 AM, Brian Kardell bkard...@gmail.com wrote: On Tue, Aug 13, 2013 at 9:15 AM, Daniel Buchner dan...@mozilla.comwrote: I concur. On hold doesn't mean forever

Re: element Needs A Beauty Nap

2013-08-13 Thread Daniel Buchner
Yep. HTML Imports are standing on their own. Dimitri, did I ever tell you you're my hero? (#ProTip: to get the full effect, sing it with that Bette Midler tone) On Tue, Aug 13, 2013 at 10:02 AM, Dimitri Glazkov dglaz...@google.comwrote: On Tue, Aug 13, 2013 at 9:59 AM, Daniel Buchner dan

Re: Web Widgets, Where Art Thou?

2013-07-29 Thread Daniel Buchner
understanding why this proposal is facing such stop energy. On Tue, Jul 23, 2013 at 8:12 AM, Marcos Caceres w...@marcosc.com wrote: On Tuesday, July 23, 2013 at 3:06 PM, Daniel Buchner wrote: On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres w...@marcosc.com(mailto: w...@marcosc.com) wrote

Re: Web Widgets, Where Art Thou?

2013-07-23 Thread Daniel Buchner
On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres w...@marcosc.com wrote: On Monday, July 22, 2013 at 11:54 PM, Daniel Buchner wrote: To clarify, I am proposing that we make a simple app manifest entry the only requirement for widget declaration: widget: { launch_path: ... }. The issue

Re: Web Widgets, Where Art Thou?

2013-07-22 Thread Daniel Buchner
In my opinion, the current spec's complexity in relation to its feature goal, is high. This doesn't mean it was a bad spec or deficient, it could be due to a number of factors: different assumptions about what widgets should do, packaging choices that existed before web apps gained steam, or a

Re: Web Widgets, Where Art Thou?

2013-07-22 Thread Daniel Buchner
On Mon, Jul 22, 2013 at 11:55 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Mon, 22 Jul 2013 09:59:33 -0700, Daniel Buchner dan...@mozilla.com wrote: In my opinion, the current spec's complexity in relation to its feature goal, is high. I think it is pretty important

Web Widgets, Where Art Thou?

2013-07-19 Thread Daniel Buchner
As some of you are aware, a widget spec or two ( http://www.w3.org/TR/2012/PR-widgets-apis-20120522/) have been floating around for a while. These were never widely adopted for various reasons - not the least of which was their complexity. Well, hold on to your shorts folks: I would like to

Re: [webcomponents]: element Wars: A New Hope

2013-04-17 Thread Daniel Buchner
*This is just a repackaging of Object.defineProperties( target, PropertyDescriptors ) thats slightly less obvious because the target appears to be a string. * Is another difference that the 'x-foo' doesn't have to be 'known' yet? It seems to be a bit more than a repack of Object.defineProperties

Re: [webcomponents]: element Wars: A New Hope

2013-04-17 Thread Daniel Buchner
Waldron waldron.r...@gmail.comwrote: On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner dan...@mozilla.comwrote: *This is just a repackaging of Object.defineProperties( target, PropertyDescriptors ) thats slightly less obvious because the target appears to be a string. * Is another difference

Re: [webcomponents]: element Wars: A New Hope

2013-04-17 Thread Daniel Buchner
. Rather, at some third quantum of time a combination of those things is constructed, keyed on 'element name'. Most of the rest is syntax, subject to bikeshedding when and if the main idea has taken root. On Wed, Apr 17, 2013 at 4:33 PM, Daniel Buchner dan...@mozilla.comwrote: So let me

Re: [webcomponents]: element Wars: A New Hope

2013-04-17 Thread Daniel Buchner
it - but I guess that's what separates us less-intelligent simpletons from Jedi like yourself. Have a wonderful evening Rick. On Wed, Apr 17, 2013 at 8:46 PM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, Apr 17, 2013 at 7:33 PM, Daniel Buchner dan...@mozilla.comwrote: So let me be *crystal

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-16 Thread Daniel Buchner
*I am going to offer a cop-out option: maybe we simply don't offer imperative syntax as part of the spec? * Why would we do this if the imperative syntax is solid, nicely compatible, and relatively uncontentious? Did you mean to say declarative? Daniel J. Buchner Product Manager, Developer

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-16 Thread Daniel Buchner
that use case for the web of today? On Tue, Apr 16, 2013 at 3:02 PM, Dimitri Glazkov dglaz...@google.comwrote: On Tue, Apr 16, 2013 at 3:00 PM, Daniel Buchner dan...@mozilla.com wrote: I am going to offer a cop-out option: maybe we simply don't offer imperative syntax as part of the spec

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-16 Thread Daniel Buchner
presumably make that association, if it needed to.* On Tue, Apr 16, 2013 at 3:47 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Apr 16, 2013, at 3:13 PM, Dimitri Glazkov wrote: On Tue, Apr 16, 2013 at 3:07 PM, Daniel Buchner dan...@mozilla.com wrote: One thing I've heard from many of our

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-15 Thread Daniel Buchner
*At least somebody explain why this is conceptually wrong. * Nothing is conceptually wrong with what you've stated Scott. I could live with a prototype element that is scoped to the element as long as there was some sort of 'registeredCallback' (as you previously alluded to many posts back) that

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-15 Thread Daniel Buchner
*How, as component author, do I ensure that my imperative set up code runs and modifies my element DOM content before the user sees the un-modified custom element declared in mark-up? (I'm cheating, since this issue isn't specific to your prototype) * When you say ...runs before the user sees the

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-15 Thread Daniel Buchner
* * *Gee, that's not very encouraging: this is the most important kind of issue for a developer, more so than whether the API is inheritance-like or not.* IMO, the not-yet-upgraded case is nothing new, and developers will hardly be surprised. This nit is no different than if devs include a jQuery

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-15 Thread Daniel Buchner
parsing, just wait for them to arrive, then call them. Something else is going on I suppose, so I'm just wasting your time. On Mon, Apr 15, 2013 at 2:42 PM, Daniel Buchner dan...@mozilla.comwrote: * * *Gee, that's not very encouraging: this is the most important kind of issue for a developer

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-14 Thread Daniel Buchner
* Here are four ways to avoid the subclassing problem for custom elements * * 1) Only allow instances of custome dom elements to be instantiated using document.createElement(x-foo). * * * *Wearing web developer hat, I never make elements any other way than createElement (or HTML), so this would

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-12 Thread Daniel Buchner
just replace the global constructor. That might be OK, and we can detect this override to register the class as needed. 2. Prefixing with HTML seems like an anti pattern. On Fri, Apr 12, 2013 at 5:08 PM, Daniel Buchner dan...@mozilla.comwrote: @John - what about what I just sent through

Re: [webcomponents]: Of weird script elements and Benadryl

2013-04-12 Thread Daniel Buchner
On Fri, Apr 12, 2013 at 3:20 PM, Dimitri Glazkov dglaz...@google.comwrote: 2) since we do have to live with generated constructors -- at least for a little while, we have two decoupled operations: a) create prototype b) generate constructor. Is this order required? Can we not generate the

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

2013-04-11 Thread Daniel Buchner
, 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

Re: [webcomponents]: Blocking custom elements on ES6, was: Platonic form of custom elements declarative syntax

2013-04-11 Thread Daniel Buchner
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

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

2013-04-10 Thread Daniel Buchner
I have a counter proposal that takes into a count both the easy-to-declare, 1-to-1 case, as well as the 1-template-to-many-elements case: https://gist.github.com/csuwldcat/5358039 I can explain the advantages a bit more in an hour or so, I just got pulled into a meeting...le sigh. Daniel J.

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

2013-04-10 Thread Daniel Buchner
certainly doesn't exclude that ability/use case (or so I thought - correct if wrong) Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Wed, Apr 10, 2013 at 1:27 PM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner dan

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

2013-04-10 Thread Daniel Buchner
/5358612 ? On Wed, Apr 10, 2013 at 1:43 PM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, Apr 10, 2013 at 4:38 PM, Daniel Buchner dan...@mozilla.comwrote: *What about CSP that forbids inline scripts?https://wiki.mozilla.org/Apps/Security#Default_CSP_policy * Is there any reason

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

2013-04-10 Thread Daniel Buchner
templates. On Wed, Apr 10, 2013 at 8:19 PM, Daniel Buchner dan...@mozilla.com wrote: 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

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

2013-04-10 Thread Daniel Buchner
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

Re: [webcomponents]: What callbacks do custom elements need?

2013-03-12 Thread Daniel Buchner
*Daniel can confirm but in all of the stuff i have seen and played with so far it is...you want a changing a component attribute to have some effect. Internally you would use mutation observers i think.* - We have built quite a few custom elements now, and here's the role/behaviors of

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2013-03-12 Thread Daniel Buchner
What about obscured, opaque, invisible, or restricted? On Tue, Mar 12, 2013 at 3:34 PM, Alan Stearns stea...@adobe.com wrote: On 3/12/13 2:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/12/13 5:19 PM, Dimitri Glazkov wrote: However, to allow developers a degree of enforcing integrity of

Re: [webcomponents]: What callbacks do custom elements need?

2013-03-11 Thread Daniel Buchner
Ready/created, inserted, removed, and attributeChanged are the minimum must-havs for developers - we heavily rely on each one of these callbacks in the components we've developed thus far. The usefulness of this API is neutered without these hooks - they're table stakes, plain and simple. Jonas,

Re: [webcomponents]: What callbacks do custom elements need?

2013-03-11 Thread Daniel Buchner
, Mar 11, 2013 at 11:55 AM, Daniel Buchner dan...@mozilla.com wrote: Ready/created, inserted, removed, and attributeChanged are the minimum must-havs for developers - we heavily rely on each one of these callbacks in the components we've developed thus far. The usefulness of this API is neutered

Re: [webcomponents]: What callbacks do custom elements need?

2013-03-11 Thread Daniel Buchner
Just to be clear, these are callbacks (right?), meaning synchronous executions on one specific node. That is a far cry from the old issues with mutation events and nightmarish bubbling scenarios. Where does bubbling come in? - I thought the concern was over the same issues that plagued

Re: [webcomponents]: What callbacks do custom elements need?

2013-03-11 Thread Daniel Buchner
inserted and removed can probably be end of micro task, but attributeChanged definitely needs to be synchronous to model the behavior of input type where changing it from X to Y has an immediate effect on the APIs available (like stepUp). Actually, I disagree. Attribute changes need not be

Re: [webcomponents]: What callbacks do custom elements need?

2013-03-11 Thread Daniel Buchner
have in addressing the case Elliot presents? Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Mon, Mar 11, 2013 at 2:42 PM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Mar 11, 2013 at 2:32 PM, Daniel Buchner dan...@mozilla.comwrote: inserted and removed can

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

2013-02-19 Thread Daniel Buchner
it pathological to make the 'non constructor-returning API' return a constructor? On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote: I agree with your approach on staging the two specs for this, but the last part about returning a constructor in one circumstance and undefined

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

2013-02-19 Thread Daniel Buchner
, but how does the system know what localName to use? I believe the notion was that the localName would be inferred from the prototype, but there are various semantic tags that share prototypes, so it seems ambiguous in these cases. S On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan

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

2013-02-19 Thread Daniel Buchner
(HTMLElement.prototype); Afaict, the 'headerness' cannot be expressed this way. On Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner dan...@mozilla.comwrote: Wait a sec, perhaps I've missed something, but in your example you never extend the actual native header element, was that on purpose? I was under

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

2013-02-18 Thread Daniel Buchner
, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com wrote: I'm not sure I buy the idea that two ways of doing the same thing does not seem like a good approach - the web platform's imperative and declarative duality is, by nature, two-way. Having two methods or an option that takes multiple

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

2013-02-15 Thread Daniel Buchner
I'm not sure I buy the idea that two ways of doing the same thing does not seem like a good approach - the web platform's imperative and declarative duality is, by nature, two-way. Having two methods or an option that takes multiple input types is not an empirical negative, you may argue it is an

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

2013-02-14 Thread Daniel Buchner
I love it, gives the developer control over the addition of sugar (just a spoonful of...) and code preference, while at the same time addressing our requirement set. Ship it! Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Thu, Feb 14, 2013 at 1:48 PM, Dimitri

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

2013-02-14 Thread Daniel Buchner
It seems to me (please correct me if this is inaccurate) that you can't * really* polyfill ES6 extension of existing element constructor inheritance, because afaik, you cannot call the existing native constructors of elements - it throws. So if you can only do a jankified 1/2 fill, why not just

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

2013-02-14 Thread Daniel Buchner
the user has to do is *not* call it, and only call super constructors if they are custom. For that reason, I don't see why this is an issue. Or if you want you can polyfill HTMLButtonElement.call. HTMLButtonElement.call = function() {}; On Thu, Feb 14, 2013 at 2:36 PM, Daniel Buchner dan

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

2013-02-14 Thread Daniel Buchner
The polyfill rabbit hole of half-hearted, faux-ES6 polyfilling of constructor inheritance seems to be far deeper than both conceptually in code-level affect than our simple examples show. Further, what is so sexy about forcing the pattern when we can't, hard stop, no-way, polyfill *class *and

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

2013-02-14 Thread Daniel Buchner
No, I believe this is *precisely *the thing to worry about - these nits and catch-case gotchas are the sort of things developers see in an emerging API/polyfill and say awe, that looks like an fractured, uncertain hassle, I'll just wait until it is native in all browsers -- we must avoid this at

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

2013-02-14 Thread Daniel Buchner
What does it actually profit us to singularly tie document.register to require an ES6-esque syntax before it lands anyway? No one is saying not to use it *when it arrives*, we're offering a way to make sure the polyfill layer isn't needlessly bound to inconsequential externalities. Hell, if you

Re: document.register and ES6

2013-02-07 Thread Daniel Buchner
Scott is right, there isn't a great polyfill answer for this part of the spec, but fortunately it doesn't affect too potential many use-cases. Developers will still go bananas for the functionality we can provide in legacy UA versions. - Daniel On Feb 7, 2013 8:51 PM, Scott Miles

Re: document.register and ES6

2013-02-06 Thread Daniel Buchner
On Wed, Feb 6, 2013 at 9:03 AM, Erik Arvidsson a...@chromium.org wrote: 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

Re: document.register and ES6

2013-02-06 Thread Daniel Buchner
Scott: is this example not intended to work in IE9? It throws, the output object is missing the 'oranginate' method. Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Wed, Feb 6, 2013 at 12:32 PM, Scott Miles sjmi...@google.com wrote: There were several errors in

Re: document.register and ES6

2013-02-06 Thread Daniel Buchner
__proto__. On Wed, Feb 6, 2013 at 12:41 PM, Daniel Buchner dan...@mozilla.com wrote: Scott: is this example not intended to work in IE9? It throws, the output object is missing the 'oranginate' method. Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation

Re: document.register and ES6

2013-02-06 Thread Daniel Buchner
Corporation On Wed, Feb 6, 2013 at 1:34 PM, Scott Miles sjmi...@google.com wrote: On Wed, Feb 6, 2013 at 1: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

Re: document.register and ES6

2013-02-06 Thread Daniel Buchner
. The reason I'm not freaking out about defineProperties is IMO because I can avoid it when I don't need it (which is about 99% of the time). Scott On Wed, Feb 6, 2013 at 1:50 PM, Daniel Buchner dan...@mozilla.com wrote: I just made sure it worked, and it does. As for developers freaking out, I

Re: document.register and ES6

2013-02-06 Thread Daniel Buchner
is *necessary* for IE compatibility. I'm 80% sure it is not. S On Wed, Feb 6, 2013 at 2:10 PM, Daniel Buchner dan...@mozilla.com wrote: I guess it isn't a show stopper for poly-*ish*-fills, I would just wrap the native document.register method where it is present sniff the incoming prototype

Re: document.register and ES6

2013-02-05 Thread Daniel Buchner
I have two questions: 1. Does this affect our ability to polyfill doc.register in current browsers? 2. Are you saying we're going to nix the ability to easily register insertion, removal, and attribute change callbacks from the API? I believe #2 is very important and should not be

Re: document.register and ES6

2013-02-05 Thread Daniel Buchner
* So this won't work?* var MyButton = document.register(‘x-mybutton’, { prototype: Object.create(HTMLButtonElement.prototype, { ... }) }); class MySuperButton extends MyButton { ... }; document.register('x-superbutton', MySuperButton); *But this will?* function MyButton() {