http://jsfiddle.net/aNHZH/7/
Actually less code overall using your (D.B.'s) idea for IE compat.
Of course, I ignored some edge cases and there are unknown unknows, but it
seems promising.
On Wed, Feb 6, 2013 at 2:52 PM, Daniel Buchner wrote:
> Yeah, that isn't so bad - I forgot I would only h
Yeah, that isn't so bad - I forgot I would only have to rebuild the naked
property descriptor object once at the time of registration.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Wed, Feb 6, 2013 at 2:49 PM, Scott Miles wrote:
> Now with IE support:
>
> http:/
Now with IE support:
http://jsfiddle.net/aNHZH/5/
On Wed, Feb 6, 2013 at 2:44 PM, Scott Miles wrote:
> If that works, then what's the problem? It only need be done once per
> component.
>
> I'm still confused, because it seems to me that 'unbaked object allowance
> route' == components only wo
If that works, then what's the problem? It only need be done once per
component.
I'm still confused, because it seems to me that 'unbaked object allowance
route' == components only work in IE if specified using tortured syntax.
That's no bueno IMO.
On Wed, Feb 6, 2013 at 2:41 PM, Daniel Buchner
Short of running Object.getOwnPropertyNames on the existing node > then
iterating over each to grab the property descriptor with
Object.getOwnPropertyDescriptor to rebuild an unbaked object > and finally
setting the properties with Object.setProperties, I am unaware of how to do
so - is there an ea
Seems like you decided that descriptor syntax is *necessary* for IE
compatibility. I'm 80% sure it is not.
S
On Wed, Feb 6, 2013 at 2:10 PM, Daniel Buchner 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
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 property value to detect whether it was baked > cache the unbaked
prototype > then pass a baked one to the native method.
Of course this me
Remember where we started: absurdly clean ES6 class syntax.
Requiring class definition class using property descriptors is a radical
march in the other direction.
I'm hardcore about syntactical tidiness. The reason I'm not freaking out
about defineProperties is IMO because I can avoid it when I d
I just made sure it worked, and it does. As for developers freaking out, I
really don't believe they would. If that was the case,
Object.defineProperties should be causing a global pandemic of
whopperdeveloper freakouts (
http://www.youtube.com/watch?v=IhF6Kr4ITNQ).
This would give us easy IE comp
On Wed, Feb 6, 2013 at 4:27 PM, Daniel Buchner 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 object, we could po
On Wed, Feb 6, 2013 at 1:27 PM, Daniel Buchner wrote:
> So you're directly setting the user-added methods on matched elements in
> browsers that don't support proto, but what about accessors?
>
I believe those can be forwarded too, I just didn't bother in my fiddle.
> Equipped with the unbaked
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 object, we could polyfill all property types:
var myButton = document.register('x-
Well, this (non-robust quicky test) works in IE:
http://jsfiddle.net/zUzCx/1/
On Wed, Feb 6, 2013 at 12:59 PM, Scott Miles wrote:
> Afaik, the 'generated constructor' is technical debt we are stuck with
> until we can actually invoke DOM constructors from JS. If there is a better
> way around
Afaik, the 'generated constructor' is technical debt we are stuck with
until we can actually invoke DOM constructors from JS. If there is a better
way around it, I'm all ears!
polyfilling without __proto__: I don't know if it's possible, which is a
good point. I was basically ignoring that problem
If we are willing to return a new constructor function I think we have
no problems. I was concerned that it would lead to people using the
wrong function but it does solve the issues.
class MyButtonImpl extends HTMLButtonElement {
}
let MyButton = document.register('my-button', {
class: MyButton
Arg, I messed up the link there. Corrected: http://jsfiddle.net/cEmZq/1/
On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles wrote:
> Sorry for the flood, but here is another version that shows inheriting
> from custom elements (Webkit/FF only).
>
> http://jsfiddle.net/cEmZq/
>
>
> On Wed, Feb 6, 2013
Sorry for the flood, but here is another version that shows inheriting from
custom elements (Webkit/FF only).
http://jsfiddle.net/cEmZq/
On Wed, Feb 6, 2013 at 12:43 PM, Scott Miles wrote:
> Yes, it's not intended to work in IE ... I used __proto__.
>
>
> On Wed, Feb 6, 2013 at 12:41 PM, Danie
Yes, it's not intended to work in IE ... I used __proto__.
On Wed, Feb 6, 2013 at 12:41 PM, Daniel Buchner 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
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 wrote:
> There were several errors in my pseudo-code, her
There were several errors in my pseudo-code, here is a working version:
http://jsfiddle.net/yNbnL/1/
S
On Wed, Feb 6, 2013 at 12:01 PM, Scott Miles wrote:
> Errata:
> makePrototypeTwiddlingConstructorForDomNodes needs to know the extendee
>
> var ctor = makePrototypeTwiddlingConstructorForD
Errata:
makePrototypeTwiddlingConstructorForDomNodes needs to know the extendee
var ctor = makePrototypeTwiddlingConstructorForDomNodes(inExtends, inClass);
On Wed, Feb 6, 2013 at 11:59 AM, Scott Miles wrote:
> On Wed, Feb 6, 2013 at 11:18 AM, Erik Arvidsson wrote:
>
>> On Wed, Feb 6, 2013 a
On Wed, Feb 6, 2013 at 11:18 AM, Erik Arvidsson wrote:
> On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles wrote:
> > Sorry, replace MyButton.super() with MyButton.super.call(this);
> >
> >
> > On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles wrote:
> >>
> >> So, neglecting issues around the syntax of do
Greetings WebApps WG!
Review on the File API is encouraged:
http://dev.w3.org/2006/webapi/FileAPI/
A few substantial changes that might need particular attention before we
initiate a call for LCWD or something comparably official:
1. autoRevoke behavior of Blob URIs has changed. Previous draf
On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles wrote:
> Sorry, replace MyButton.super() with MyButton.super.call(this);
>
>
> On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles wrote:
>>
>> So, neglecting issues around the syntax of document.register and the
>> privatization of callbacks, is it fair to sa
Greetings Victor!
>
>
> On Dec 10, 2012, at 12:02 PM, Victor Costan wrote:
>
> > Dear Web Applications WG,
> >
> > 1) Please add a File constructor.
>
>
> This has cropped up a few times :) I've logged a spec bug for this
> feature: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20887
>
> Could y
Sorry, replace MyButton.super() with MyButton.super.call(this);
On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles wrote:
> So, neglecting issues around the syntax of document.register and the
> privatization of callbacks, is it fair to say the following is the intended
> future:
>
> class MyButton e
To be clear, the actual current spec is only:
var MyButton = document.register('my-button', {
prototype: aPROTOTYPE
});
So, while Arv has included non-spec 'created' and 'attributeChanged', you
have completely omitted 'prototype'.
Also, wrt "call methods on the custom element", I believe all A
So, neglecting issues around the syntax of document.register and the
privatization of callbacks, is it fair to say the following is the intended
future:
class MyButton extends HTMLButtonElement {
constructor() {
super();
// make root, etc.
}
}
document.register('x-button', MyButton);
>> 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 way so these (private)
lifecycle methods aren't just sitting there on the n
On Wed, Feb 6, 2013 at 9:03 AM, Erik Arvidsson wrote:
Do we need to be able to do "new MyButton" or is
> document.createElement/innerHTML/parser sufficient? If we need to be
> able to do "new" in the polyfill I think we either need to tweak
> document.register or get the developer to cooperate (
On Tue, Feb 5, 2013 at 5:43 PM, Daniel Buchner wrote:
> So we're removing the async nature of the API? How is this a good trade? I
> thought this was one of the benefits? Is polyfilling still possible in a
> sane way that adheres to the specified behavior?
>
I don't think anyone answered the syn
On Wed, Feb 6, 2013 at 9:56 AM, Erik Arvidsson wrote:
> On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles 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
> dec
Greetings Victor!
On Dec 10, 2012, at 12:02 PM, Victor Costan wrote:
> Dear Web Applications WG,
>
> 1) Please add a File constructor.
This has cropped up a few times :) I've logged a spec bug for this feature:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20887
Could you flesh out your o
On Wed, Feb 6, 2013 at 9:03 AM, Erik Arvidsson wrote:
> On Tue, Feb 5, 2013 at 8:26 PM, Daniel Buchner 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
>
On 2/6/13 5:07 PM, Erik Arvidsson wrote:
This refactoring is needed for ES6 anyway so it might be worth looking
into no matter what.
Well, yes, but it's a matter of timeframes. It's incredibly unlikely
that a complete refactoring of how functions are implemented (which is
what I was given to
On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles 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 way so these
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20887
Bug ID: 20887
Summary: Add a File constructor
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
On Wed, Feb 6, 2013 at 5:27 AM, Boris Zbarsky 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
> function directly; i
On Tue, Feb 5, 2013 at 8:26 PM, Daniel Buchner 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 need to be able to
Something is better than nothing, and both the iPhone and Android systems
are better than not asking the user at all. The principle of security in
depth is that you don't rely on a single security feature that may be
flawed, but have a multi layered approach to security.
I think that giving a user
On 06/02/2013 08:36 , Keean Schupke wrote:
I don't think you can say either an up front dialog or popups do not
work. There are clear examples of both working, Android and iPhone
respectively. Each has a different set of trade-offs and is better in
some circumstances, worse in others.
If by "wo
On 2/6/13 10:46 AM, Boris Zbarsky wrote:
There is no "exposed function". In Erik's proposal the function is
provided by the script and then the script keeps using it; the caller is
expected to mutate the [[Construct]]
I meant the _callee_ of course. ;)
-Boris
On 2/6/13 10:36 AM, David Bruant wrote:
As a band-aid short-term type of solution, the exposed function could be
a proxy to the actual function with a specific construct trap
There is no "exposed function". In Erik's proposal the function is
provided by the script and then the script keeps us
Le 06/02/2013 11:27, Boris Zbarsky a écrit :
On 2/5/13 10:28 PM, Boris Zbarsky wrote:
And the point is that document.register changes the [[Construct]] of
MyButton but does nothing else with it?
Note that I'm still checking how feasible this is in SpiderMonkey on
any sort of finite timeframe,
On Wed, Feb 6, 2013 at 2:09 AM, Charles McCathie Nevile <
cha...@yandex-team.ru> wrote:
> **
> This may be true. But pointer-lock is an example of something that needs
> the entire UX to be thought through. simply switching from one to the other
> without the user knowing is also poor UX, since it
On 2/5/13 10:28 PM, Boris Zbarsky wrote:
And the point is that document.register changes the [[Construct]] of
MyButton but does nothing else with it?
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
46 matches
Mail list logo
