Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On 28/04/10 23:28, Garrett Smith wrote: On Wed, Apr 28, 2010 at 2:12 AM, James Grahamjgra...@opera.com wrote: On 04/28/2010 10:27 AM, David Bruant wrote: When I started this thread, my point was to define a normalized way (through ECMAScript binding) to add array extras to array-like objects in the scope of HTML5 (HTMLCollection and inheriting interfaces). I don't see any reason yet to try to find a solution to problems that are in current web browsers. Of course, if/when a proposal emerges from this thread and some user agent accept to implement it, a workaround (probably, feature detection) will have to be found to use the feature in user agents that implement it and doing something equivalent in web browsers that don't. To be clear the proposals in this thread are pure syntactic sugar; they don't allow you do do anything that you can't already do like: Array.prototype.whatever.call(html_collection, arg1, arg2, ...) where whatever is the array method you are interested in. - and from that you can expect errors in Internet Explorer up to and including version 8. Adding a toArray operation (for example) won't work in IE up to and including version 8 though either. There's no point in adding a toArray operation for the pure reason that they currently don't implement another part of the spec (through the WebIDL references) currently. toArray adds no extra usefulness once they implement other parts of the spec. Of course there is nothing wrong with making the syntax more natural if it can be done in a suitably web-compatible way. However it seems more sensible to do this at a lower level e.g. as part of Web DOM Core. Sadly that spec is in need of an editor. The problem that has been well established is that Internet Explorer's implementation of host object collections or dhtml collection[1] objects is incompatible with JScript implementation of Array generics. The result of attempting to supply an Internet Explorer dhtml collection to an Array generic method, e.g. slice, as the `this` value, results in a jscript runtimer error: JScript object expected. IE8: [].slice.call(document.styleSheets); Result: Error: JScript object expected. In IE8 document.styleSheets.toArray().slice(0, 1); also throws an error. How does adding toArray help for IE8, which you're giving as the reason for adding it? Travis Leithead and IE Team: Can you release Internet Explorer 9 with all dhtml collections implemented as native EcmaScript objects? As far as I am aware, none of them are on this list. -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On Thu, Apr 29, 2010 at 6:59 AM, Geoffrey Sneddon gsned...@opera.com wrote: On 28/04/10 23:28, Garrett Smith wrote: On Wed, Apr 28, 2010 at 2:12 AM, James Grahamjgra...@opera.com wrote: On 04/28/2010 10:27 AM, David Bruant wrote: When I started this thread, my point was to define a normalized way (through ECMAScript binding) to add array extras to array-like objects in the scope of HTML5 (HTMLCollection and inheriting interfaces). I don't see any reason yet to try to find a solution to problems that are in current web browsers. Of course, if/when a proposal emerges from this thread and some user agent accept to implement it, a workaround (probably, feature detection) will have to be found to use the feature in user agents that implement it and doing something equivalent in web browsers that don't. To be clear the proposals in this thread are pure syntactic sugar; they don't allow you do do anything that you can't already do like: Array.prototype.whatever.call(html_collection, arg1, arg2, ...) where whatever is the array method you are interested in. - and from that you can expect errors in Internet Explorer up to and including version 8. Adding a toArray operation (for example) won't work in IE up to and including version 8 though either. There's no point in adding a toArray operation for the pure reason that they currently don't implement another part of the spec (through the WebIDL references) currently. toArray adds no extra usefulness once they implement other parts of the spec. It's pretty hard to make out what you're getting at here. You the spec to refer to something here that they don't implement. It was also hard to understand your meaning in: | To be clear the proposals in this thread are pure syntactic sugar; | they don't allow you do do anything that you can't already do like: | | Array.prototype.whatever.call(html_collection, arg1, arg2, ...) Array.prototype.slice.call(html_collection) is not something that one cannot already do; it *is* something that can be done, however one cannot expect an Array to be returned from that operation in IE = 8. Whatever it is you meant to convey in that paragraph was lost. If IE dhtml collections are implemented as native ECMAScript objects in IE9, the case for the toArray proposal is weak. The fact that IE implements dhtml collections as unwieldy error-throwing objects poses an obstacle at a fundamental level. That problem needs to be addressed by Microsoft. [...] In IE8 document.styleSheets.toArray().slice(0, 1); also throws an error. How does adding toArray help for IE8, which you're giving as the reason for adding it? What lead you to the assumption that I proposed toArray to address problems in IE8? I would not publish something so ludicrous. Travis Leithead and IE Team: Can you release Internet Explorer 9 with all dhtml collections implemented as native EcmaScript objects? As far as I am aware, none of them are on this list. He subscribes to the w3c-censored lists (dog-and-pony shows), but now that you mention it, I don't see his name showing up here much.
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On Mon, Apr 26, 2010 at 10:04 AM, David Flanagan da...@davidflanagan.com wrote: Erik Arvidsson wrote: [snip] Rather that trying to make DOM collections feel like arrays, how about just giving them a toArray() method? This makes it clear that a collection is not an array, but clearly defines a way to obtain an array. Clever implementors might even be able to optimize common uses-cases using some kind of copy-on-write strategy so that toArray() doesn't involve memory allocation and copying. That would solve the OP's problem, but what about other collections like NodeList, StyleSheetList, and CSSStyleDeclaration? An interface that has a toArray() method might be more suitable, as it could be added arbitrarily to other interfaces mentioned already. In any case, the problem is not going to go away in IE6. Nor IE7. Nor IE8. IE9 might change to implement Host object collections as native ECMAScript objects, but even then, then the problems will still need to be addressed in all versions of IE prior. MSIE's implementation of Host objects WRT Array generics is a fundamental and significant and important problem that needs to be addressed. If Internet Explorer's problems with Host objects cannot be fixed, then it would be a nice feature to have a way to get an array from a collection. However, Microsoft should release an IE9 where host object collections are implemented as native ECMAscript objects. If they can do that, the problems would not be an issue. What do you say, Travis Leithead and IE Team? Will you release IE9 with host object implemented as native EcmaScript objects? Garrett
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
Le 28/04/2010 00:03, Garrett Smith a écrit : On Mon, Apr 26, 2010 at 10:04 AM, David Flanagan da...@davidflanagan.com wrote: Erik Arvidsson wrote: [snip] Rather that trying to make DOM collections feel like arrays, how about just giving them a toArray() method? This makes it clear that a collection is not an array, but clearly defines a way to obtain an array. Clever implementors might even be able to optimize common uses-cases using some kind of copy-on-write strategy so that toArray() doesn't involve memory allocation and copying. That would solve the OP's problem, but what about other collections like NodeList, StyleSheetList, and CSSStyleDeclaration? I am sorry, I don't know what OP stands for. An interface that has a toArray() method might be more suitable, as it could be added arbitrarily to other interfaces mentioned already. I agree with this idea and proposed something in that direction recently : http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/026057.html In any case, the problem is not going to go away in IE6. Nor IE7. Nor IE8. IE9 might change to implement Host object collections as native ECMAScript objects, but even then, then the problems will still need to be addressed in all versions of IE prior. In this case, what do you refer as the problem ? When I started this thread, my point was to define a normalized way (through ECMAScript binding) to add array extras to array-like objects in the scope of HTML5 (HTMLCollection and inheriting interfaces). I don't see any reason yet to try to find a solution to problems that are in current web browsers. Of course, if/when a proposal emerges from this thread and some user agent accept to implement it, a workaround (probably, feature detection) will have to be found to use the feature in user agents that implement it and doing something equivalent in web browsers that don't. MSIE's implementation of Host objects WRT Array generics is a fundamental and significant and important problem that needs to be addressed. If Internet Explorer's problems with Host objects cannot be fixed, then it would be a nice feature to have a way to get an array from a collection. The idea of getting an Array from a collection came out without IE in mind. If we want to have it in a specification, it has to be a good idea regardless browsers specificities. However, Microsoft should release an IE9 where host object collections are implemented as native ECMAscript objects. If they can do that, the problems would not be an issue. What do you say, Travis Leithead and IE Team? Will you release IE9 with host object implemented as native EcmaScript objects? I have not seen any Travis Leithead or IE Team in the recipients. Is that normal ? David
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On 04/28/2010 10:27 AM, David Bruant wrote: When I started this thread, my point was to define a normalized way (through ECMAScript binding) to add array extras to array-like objects in the scope of HTML5 (HTMLCollection and inheriting interfaces). I don't see any reason yet to try to find a solution to problems that are in current web browsers. Of course, if/when a proposal emerges from this thread and some user agent accept to implement it, a workaround (probably, feature detection) will have to be found to use the feature in user agents that implement it and doing something equivalent in web browsers that don't. To be clear the proposals in this thread are pure syntactic sugar; they don't allow you do do anything that you can't already do like: Array.prototype.whatever.call(html_collection, arg1, arg2, ...) where whatever is the array method you are interested in. Of course there is nothing wrong with making the syntax more natural if it can be done in a suitably web-compatible way. However it seems more sensible to do this at a lower level e.g. as part of Web DOM Core. Sadly that spec is in need of an editor.
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On Wed, Apr 28, 2010 at 2:12 AM, James Graham jgra...@opera.com wrote: On 04/28/2010 10:27 AM, David Bruant wrote: When I started this thread, my point was to define a normalized way (through ECMAScript binding) to add array extras to array-like objects in the scope of HTML5 (HTMLCollection and inheriting interfaces). I don't see any reason yet to try to find a solution to problems that are in current web browsers. Of course, if/when a proposal emerges from this thread and some user agent accept to implement it, a workaround (probably, feature detection) will have to be found to use the feature in user agents that implement it and doing something equivalent in web browsers that don't. To be clear the proposals in this thread are pure syntactic sugar; they don't allow you do do anything that you can't already do like: Array.prototype.whatever.call(html_collection, arg1, arg2, ...) where whatever is the array method you are interested in. - and from that you can expect errors in Internet Explorer up to and including version 8. Of course there is nothing wrong with making the syntax more natural if it can be done in a suitably web-compatible way. However it seems more sensible to do this at a lower level e.g. as part of Web DOM Core. Sadly that spec is in need of an editor. The problem that has been well established is that Internet Explorer's implementation of host object collections or dhtml collection[1] objects is incompatible with JScript implementation of Array generics. The result of attempting to supply an Internet Explorer dhtml collection to an Array generic method, e.g. slice, as the `this` value, results in a jscript runtimer error: JScript object expected. IE8: [].slice.call(document.styleSheets); Result: Error: JScript object expected. No other 21st century browsers exhibit such problems, to my knowledge. The problem is with Internet Explorer. A program cannot safely use such constructs without at least feature testing with a try-catch. If Microsoft will release Internet Explorer 9 with dhtml collections implemented as native EcmaScript objects, then your proposal would not be needed and would only add more complexity to the overly complicated WebIDL (which should have been scrapped and restarted). The example would do what is obviously wanted of it and create an array from the StyleSheetList object. I am asking for Microsoft to not Internet Explorer 9 with dhtml collections as unwieldy error-throwing objects. I am asking Microsoft to instead release Internet Explorer 9 with all dhtml collections implemented as native EcmaScript objects. Travis Leithead and IE Team: Can you release Internet Explorer 9 with all dhtml collections implemented as native EcmaScript objects? http://msdn.microsoft.com/en-us/library/ms533048%28VS.85%29.aspx
