Boris Zbarsky:
Per the current spec proposal, the GSP lives on the proto chain and
exposes the various id/name stuff as own properties on itself, with the
usual caveats about checking up the proto chain first that DOM named
access has. See
Are we talking just about attributes here, and not operations? So
Window.prototype.open would still exist and there'd be no own open
property on window?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Jonas Sicking:
Webkit also puts attributes on objects for non-globals, but I'm not
promoting that behavior. Nor do I know of any benefits regarding web
compatibility that comes with that behavior.
Brendan Eich:
Ok, that's what I was getting at. It may be that this is just historical
Brendan Eich:
As bz and others point out, the object detection w/ var pattern can
arise for operations, e.g. for requestAnimationFrame, using the same
var requestAnimationFrame = window.mozRequestAnimationFrame || ... ||
window.requestAnimationFrame;
pattern. So WebIDL operations (JS
Kyle Huey:
Can we leave EventTarget's methods on the proto chain and only move the
ones on the Window interface itself? Unlike Window, EventTarget isn't
changing very much.
We could. You're right it's not changing much, but I wouldn't want to
box ourselves in to not being able to extend it
Brendan Eich:
As noted, they started out that way 17 years ago. I think WebIDL and
interface-based method definition made onload, e.g., predefined on
window objects, or more recently on Window.prototype. Was this useful?
Was it intended specifically (for window, not just intended generally
due
Brendan Eich:
To hope to make this sideshow beneficial to all the cc: list, what do
DOM specs use to talk about uint16 units vs. code points?
I say code unit as a shorter way of saying 16 bit unsigned integer
code unit
http://dev.w3.org/2006/webapi/WebIDL/#dfn-code-unit
(which DOM4 also
On 24/09/11 8:35 AM, Allen Wirfs-Brock wrote:
Regarding, WebIDL. It seems to me, that it just needs an extended attribute to
specifies which attributes are instance attributes rather than prototype
attributes.
I think it only makes sense to have IDL attributes correspond to
properties on
On 15/08/11 8:58 PM, Tom Van Cutsem wrote:
So, to future-proof if this strawman is accepted, I think it's best to
let existing |defineProperty| traps |return true;|.
By that do you mean interpret an undefined return value as meaning
don't throw? Sounds reasonable.
On 9/08/11 9:40 AM, Mark S. Miller wrote:
If there are no show-stopping legacy compat constraints forcing us to
specify Reject, I prefer that we specify these to throw a TypeError.
I can't say for sure, but I would be surprised if this didn't cause
problems, given that it introduces exception
message -
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
on a native Array object (or a subclass of one).
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
proxies over this hurdle?
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
, but possible anyway.
True, that would be one way around it.
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
, but requires changes to the Object.prototype.toString definition.
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
[Please follow up to public-script-co...@w3.org, thanks.]
- Forwarded message from Cameron McCormack c...@mcc.id.au -
From: Cameron McCormack c...@mcc.id.au
Date: Wed, 24 Nov 2010 15:54:38 +1300
To: public-script-co...@w3.org
Subject: [WebIDL] summary of topics discussed at TC39 meeting
-script-coord some time over the next few
days with a sumamry of the rest of the Web IDL related discussions we
had.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org
? If not, and if this (Mark’s)
interpretation is meant to be the correct one, then I’d suggest that
note be changed in an erratum to say this explicitly.
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https
and the ones that are currently identified in
the document
* publish a LCWD
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Cameron McCormack:
mapPairs(someObject, { (a, b) = a + '=' + b) });
Maciej Stachowiak:
If you allow multiple arguments with this syntax, either with or
without parens, you're back to unbounded lookahead required for an LL
parser.
Shouldn’t be. Take the parens required option. After
to build on, then yeah
it seems like most things can be done (from Maciej’s quick analysis).
The array like objects do seem like a useful pattern for authors to use,
though.
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss
IDL that exist solely for quirky
compatibility reasons, that would help to discourage their use in other
specs.
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
?
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Cameron McCormack:
Indeed, much of the custom [[Get]] etc. functionality can be turned into
ES5 meta-object stuff. A pertinent question is then: should we change
Web IDL to specify an ES5 binding (and not ES3) at this point, given
that specs depending on it want to advance along the Rec
pretty much just so that
‘in’ and hasOwnProperty return true for array index properties, which is
needed for HTMLCollection and the like.
(Cross-posting to these three lists makes me feel funny, although I
recognise that these issues involve all three groups.)
--
Cameron McCormack ≝ http
for them!
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
that the overload resolution stuff is too convoluted and could
do with some rewriting to be clearer.
I wonder how much is inherent to the complexity of the issue and how
much is just the presentation...
Perhaps a bit of both.
--
Cameron McCormack ≝ http://mcc.id.au
, though it is
defined. If [OverrideBuiltins] is on the interface, then toString is
taken as a a named property; otherwise, it’s the property from the
Storage prototype object. This is handled by the host object [[Get]]
method:
http://dev.w3.org/2006/webapi/WebIDL/#get
--
Cameron McCormack ≝ http
Maciej Stachowiak:
JS numbers are IEEE doubles, not singles (modulo the
indistinguishability of different NaNs and other such details).
Right, my mistake.
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
Hi everyone.
Sam Ruby:
At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.
I'm travelling at the moment, so apologies for the delay in replying.
Unfortunately I
/2008OctDec/0377.html
and an issue has been raised:
http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0384.html
--
Cameron McCormack ≝ http://mcc.id.au/
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
31 matches
Mail list logo
