ByteArray
Hi, ECMAScript 4 had a ByteArray feature that the W3C WebApps WG wanted to use for XMLHttpRequest Level 2, to expose the raw response data and also to allow any entity body to be transmitted to the server the author could think of. However, ByteArray is no longer there. HTML5 has a concept called CanvasPixelArray which is effectively a byte array and I suppose we could define something like that as well, but it seems nicer if we can just map it to something part of the ECMAScript. Are there any plans for such a feature? Kind regards, -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/> ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES3.1 Draft: 15 Jan 2009 "MountainView" version available
On Thu, 15 Jan 2009 14:16:04 +0100, Pratap Lakshman (VJ#SDK) wrote: I have uploaded to the wiki (link<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>) the 15 Jan 2009 draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification. Revision history is at the end of the document. This shall be the document to use for review at the upcoming TC39 meeting (28/29 Jan, MountainView, Google). If there are any updates or revisions prior to the meeting, we will post them on the wiki as well as on the discuss lists. FWIW, it seems there is a mismatch between the draft and what Internet Explorer 8 appears to be shipping or maybe I am misunderstanding something. http://annevankesteren.nl/2009/01/ie8-getters-setters That is, section 8.10.5 uses "get" and "set" as keywords where Internet Explorer 8 uses "getter" and "setter" according to its documentation. (Section 11.1.5 pretty much has to use "get" and "set" because of three shipping implementations.) -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/> ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES3.1 Draft: 15 Jan 2009 "MountainView" version available
On Thu, 15 Jan 2009 18:40:29 +0100, Alex Russell wrote: On Jan 15, 2009, at 7:25 AM, Anne van Kesteren wrote: FWIW, it seems there is a mismatch between the draft and what Internet Explorer 8 appears to be shipping or maybe I am misunderstanding something. http://annevankesteren.nl/2009/01/ie8-getters-setters That is, section 8.10.5 uses "get" and "set" as keywords where Internet Explorer 8 uses "getter" and "setter" according to its documentation. (Section 11.1.5 pretty much has to use "get" and "set" because of three shipping implementations.) ES3.1 isn't settled yet, but surely using the terminology from what will be the next JS spec seems best...and in this case that's what MSFT did, I think rightly. It is super annoying that they didn't include the get/set aliases for compat, thought. Your comment confuses me, but it seems the MSDN documentation was wrong and IE8 will use "get" and "set" as per the latest draft, so all is fine. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/> ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: parseInt and implicit octal constants
On Sat, 21 Feb 2009 01:47:45 +0100, Mark S. Miller wrote: Absent further information from the Opera folks, I agree. But if we can, we should postpone committing to a decision until we hear about their experience with this. Opera folks? We have no compatiblity bugs filed regarding parseInt as far as I can tell. -- Anne van Kesteren http://annevankesteren.nl/ ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Fwd: ByteArray
I thought I'd try posting this again. --- Forwarded message --- From: "Anne van Kesteren" To: es-discuss@mozilla.org Cc: Subject: ByteArray Date: Thu, 16 Oct 2008 09:05:30 +0200 Hi, ECMAScript 4 had a ByteArray feature that the W3C WebApps WG wanted to use for XMLHttpRequest Level 2, to expose the raw response data and also to allow any entity body to be transmitted to the server the author could think of. However, ByteArray is no longer there. HTML5 has a concept called CanvasPixelArray which is effectively a byte array and I suppose we could define something like that as well, but it seems nicer if we can just map it to something part of the ECMAScript. Are there any plans for such a feature? Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
On Thu, 24 Sep 2009 14:36:56 +0200, Sam Ruby wrote: The current WebIDL binding to ECMAScript is based on ES3... this needs to more closely track to the evolution of ES, in particular it needs to be updated to ES5 w.r.t the Meta Object Protocol. Is there a more detailed comment on this available somewhere? In the process, we should discuss whether this work continues in the W3C, is done as a joint effort with ECMA, or moves to ECMA entirely. What is the reason for moving it away from W3C? I'd much rather have it there since most consumers are there too. (Another reason would be that the W3C has a more open process.) -- Anne van Kesteren http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby wrote: Meanwhile, what we need is concrete bug reports of specific instances where the existing WebIDL description of key interfaces is done in a way that precludes a pure ECMAScript implementation of the function. Is there even agreement that is a goal? I personally think the catch-all pattern which Brendan mentioned is quite convenient and I do not think it would make sense to suddenly stop using it. Also, the idea of removing the feature from Web IDL so that future specifications cannot use it is something I disagree with since having it in Web IDL simplifies writing specifications for the (legacy) platform and removes room for error. Having Web IDL is a huge help since it clarifies how a bunch of things map to ECMAScript. E.g. how the XMLHttpRequest constructor object is exposed, how you can prototype XMLHttpRequest, that objects implementing XMLHttpRequest also have all the members from EventTarget, etc. I'm fine with fiddling with the details, but rewriting everything from scratch seems like a non-starter. Especially when there is not even a proposal on the table. -- Anne van Kesteren http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
On Fri, 25 Sep 2009 16:26:21 +0200, Mark S. Miller wrote: To clarify, AFAIK, no one on the EcmaScript committee is proposing that WebIDL itself be moved to ECMA, but rather the WebIDL->EcmaScript language binding. That is the most essential part of Web IDL for most consumers though. Maybe one should hope for the best, but I think the WebApps WG is a much better place in terms of transparency and I do not see any reason why the ECMAScript committee cannot simply provide public feedback just like everyone else. Even if a person cannot be on the WG for whatever reason he is still allowed to join the mailing list and participate in discussion. I think it is better in terms of transparency because all the decisions are made on a public list, the draft is in version control (and written in HTML), and it is very easy for people to participate by just emailing public-weba...@w3.org or chatting with the editor on IRC. (Admittedly I also have my reservations on how certain decisions regarding ECMAScript have been made running contrary to deployed implementations. E.g. with regards to the de facto getters and setters standard. I think something like that would be much less likely to happen at the W3C though in the end of course it depends on who is involved.) To answer a concern brought up later in the thread, neither is anyone of the EcmaScript committee proposing that anything be removed from WebIDL, or that the definition of these binding change in ways that create incompatibilities with current pre-HTML5 browser APIs. Whatever problems are created by legacy uses of WebIDL, we all accept that we have to live with these problems for the foreseeable future (essentially forever). Rather, the concern is that new APIs defined using WebIDL should not magnify these problems. I'm not sure I agree they are problems, though it might help if some explicit examples were given. These are two separate points. The second point constitutes only advice from ECMA to W3C, and demonstrates a need for dialog. The EcmaScript committee has been evolving EcmaScript with one of our goals being to close the gap between what DOM objects can do and what EcmaScript objects can emulate. While we were busy trying to close the gap, html5 was busy widening it. This is largely our fault by not having communicated this goal. We seek dialog repair this mistake and to avoid repeating it. Where exactly was the gap widened? The first point may be more contentious, but I think is also clearer. Say Joe creates JoeLang and creates a browser plugin or something that gives JoeLang access to the DOM. Joe should not expect W3C to define the WebIDL->JoeLang binding. As you say, WebIDL is a nominally language-independent formalism. As such, it should serve precisely as the abstraction mechanism needed to allow work on host environment APIs like browsers to proceed loosely coupled to the design on the languages that run in such host environments. While N languages might not be possible doing it for the 2 we care about does make sense I think. The specific language details also influence the design of Web IDL. And especially in case of ECMAScript makes reviewing the draft much easier because you can easily check if it matches what contemporary implementations do. Catchalls are an excellent example issue for both points, in opposite directions. Regarding the second point, yes, we believe that new host APIs should generally seek to avoid requiring catchalls, since new native (i.e., written in EcmaScript) APIs must, and since there are many benefits to being able to emulate more host APIs more easily in EcmaScript (such as the ability to interpose intermediary wrappers). Regarding the first point, since legacy host APIs do require catchalls, EcmaScript must eventually too. The definition of how WebIDL-expressed catchalls map to future EcmaScript should co-evolve with the changes to EcmaScript needed to support this mapping. -- Anne van Kesteren http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Web IDL Garden Hose
On Mon, 28 Sep 2009 17:20:27 +0200, Mark S. Miller wrote: Good point. I was indeed thinking only of HTML5. Other things being equal, it would seem the best way for these other projects to avoid blocking on WebIDL would be for them to rely only on the previous version of WebIDL. Of course, other things are never equal. Why do these other projects need a new version of WebIDL? There is no old version. -- Anne van Kesteren http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss