Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
Allen Wirfs-Brock: The internal methods such as [[Delete]] aren't an actual extension mechanism. They are a specification device used to define the semantics of ECMAScript. As such they are subject to change (there are significant changes in the ES5 spec.) and could even completely disappear if some edition of the ES specification chooses to adopt a different specification technique (which has been discussed). OK, that is indeed what I’m hearing from you guys. “Host objects may implement these [internal] methods in any manner unless specified otherwise” in ES3 doesn’t sound like it’s particularly discouraging of the different behaviour that Web IDL prescribes. Another issue with using specification internal methods as if they were an extension mechanism is that the ECMAScript specifications doesn't define any abstract contracts for them. What are the invariants that every [[Delete]] methods must maintain in order for the entire language to remain sound? It isn't currently defined. Or, defined to be “you can do anything”. Which admittedly isn’t useful if you are indeed trying to maintain some invariants. Within the ES spec. this isn't a big problem because most of the internal methods only have one definition within the ES specification and if there are more than one they have been designed with a unified semantics in mind. Why is functionality that isn't available through native objects needed? For web compatibility, really. If it is possible to define Java bindings for WebIDL that don't require extending the Java language why isn't it possible to approach JavaScript in the same manner (for new APIs, I understand the legacy issues). Java really doesn’t have those compatibility issues. Ignoring the legacy issues, assuming we have ES5 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/
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 11:16 PM, Cameron McCormack wrote: OK, that is indeed what I’m hearing from you guys. “Host objects may implement these [internal] methods in any manner unless specified otherwise” in ES3 doesn’t sound like it’s particularly discouraging of the different behaviour that Web IDL prescribes. That is regrettable ES1-era language, written to accommodate the host objects found prominently in IE due to too-low-level COM integration. It should have come with color commentary advising against exploiting the barn-door-sized loopholes. Why is functionality that isn't available through native objects needed? For web compatibility, really. Web Storage is a recent example of something other than web compatibility at work. Imitation of what went before, keystroke- optimization to use the short property reference expression instead of get/put/remove methods, or both, AFAICT. Ignoring the legacy issues, assuming we have ES5 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. Seems like everyone agrees Array-likes are not the issue. /be
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 8:05 PM, Brendan Eich wrote: On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote: - Note: I think catchall deleters are used only by Web Storage and not by other new or legacy interfaces. Seems like a strong reason to change to the proposed API to eliminate the need for a new ES language extension. I previously argued for removing the need for catchall deleters from the Web Storage API (since nothing else requires , but other browser vendors (including Mozilla) were happy with it, (including Mozilla) and happy with it leave out some nuance: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014856.html Robert O'Callahan here wrote If overloading delete is too quirky or too hard to implement, then it seems none of the other shorthands should be allowed either. His message adverted to the better course of methodical access instead of property access to Web Storage keyed values. Alas Rob finally gave up at: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014868.html I think the Web Storage key/value reflection as properties is a mistake. Sorry I wasn't reviewing it in time to say so. But it was obviously not a situation everyone was happy with, even ignoring the issue of delete. I accept your corrections as to nuance. At the time I felt like I was fighting a losing battle. The real issue, though, is what to do going forward. and I think now everyone (including I believe Microsoft) has implemented the spec behavior. See prior discussion thread here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html . At this point, since we have multiple deployed implementations of Web Storage, we'd have to investigate whether it's safe to remove this behavior without breaking content. We could try to remove it -- or (what is more likely to go down easily) we could add methods and let the property reflections wither, and vow to avoid repeating this mistake. There are methods, but I'm not optimistic that they will cause property reflection to wither. If the number of places in the Web platform that require custom delete behavior goes from 1 to 2, that's a lot less bad than going from 0 to 1. So it won't accomplish much. However, I missed a spot and it looks like custom deleters are also used by the DOMStringMap interface, which is used to reflect data-* attributes. http://dev.w3.org/html5/spec/Overview.html#domstringmap-0 I don't think anyone has implemented that yet. I believe we could get rid of custom deleters from the Web platform if Firefox and IE remove support for custom deleters in LocalStorage, refuse to add it back, and refuse to implement it for DOMStringMap. If that happened, I'm sure other browsers and the spec would follow suit. I don't think I can convince my colleagues to remove the behavior from WebKit if Gecko and Trident continue to support it. 2) Ability to support being called (via [[Call]]) without being a Function. Not an issue with the core ES5 semantics. Most ES3/5 section 15 functions have this characteristic. As long as such WebIDL objects are defined similarly to the built-in function they too can have this characteristic. It may well be useful to introduce a mechanism defining such pure functions in the language but it probably isn't necessary to proceed with the WebIDL binding. The important thing to try to avoid is specify a custom [[Call]] I tend to agree that this behavior (and the next 3) are not philosophically problematic, even though they cannot today be implemented in pure ECMAScript. What does typeof say for such a callable object? I think it should probably say object, though that's not compatible with ES3 or current WebKit practice. In what sense are any DOM methods required to be not Functions (native function objects) in the specs? In Netscape of old and Mozilla browsers since 1998, DOM methods are native function objects. This is not an issue for DOM methods. It's an issue for interfaces such as HTMLCollection and HTMLFormElement that support indexing by function call syntax, for legacy compatibility reasons. Constructors like XMLHttpRequest, Option and Image also do not inherit from Function.prototype even though they are callable. This seems winning since developers want not only sane typeof, but .apply/call/bind. It's definitely winning, and it may be possible to apply it to global constructors that are also callable as a future improvement, but it's probably not possible to make HTMLCollection or HTMLFormElement inherit from the Function prototype, and I think it would not be desirable either. We've talked on es-discuss about pure functions (ones without [[Construct]] and .prototype) before: https://mail.mozilla.org/pipermail/es5-discuss/2009-July/002920.html in case you missed the thread. Agreed it's not a big deal. We have a bugzilla.mozilla.org
Re: [selectors-api] Scoped Selectors
Boris Zbarsky wrote:
On 9/26/09 4:36 PM, Lachlan Hunt wrote:
A scoped selector string is a string that begins with an exclamation
point followed by a the remainder of the selector.
This assumes that '!' will never be allowed at the beginning of a CSS
selector, right?
It does, but the workaround would be to insert an extra space at the
beginning.
I'd be willing to pick an alternative character to avoid any possible
clash. Perhaps a comma instead, like ,div div, which can never be
used at the beginning of a conforming group of selectors.
I'm also considering adjusting the idea it so that it will work when the
string simply begins with any combinator ('+', '~', or ''), but we
still need something to use in place of the descendant combinator as the
space won't have the desired effect.
Have you run this by the CSS working group?
Not yet, but will do so after I find out from this group if the
technique is viable.
e.g. The selector em, strong supported by JS libraries can simply be
prefixed with a !, like !em, strong and the implementation will be
able to process it to become :scopeem, :scopestrong. Of course, it
will also work with the other combinators.
That processing still needs to be defined, right?
Yes. It would be useful to get feedback from implementers about how I
should define this.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote: There are methods, but I'm not optimistic that they will cause property reflection to wither. getItem/setItem/removeItem/key/clear methods, plus .length -- not a balanced name-set stylistically, but usable to avoid collisions (my key is named 'key', heh). Agreed it looks nearly hopeless to herd developers toward always using these methods instead of .myKey, etc. If the number of places in the Web platform that require custom delete behavior goes from 1 to 2, that's a lot less bad than going from 0 to 1. So it won't accomplish much. However, I missed a spot and it looks like custom deleters are also used by the DOMStringMap interface, which is used to reflect data-* attributes. http://dev.w3.org/html5/spec/Overview.html#domstringmap-0 I don't think anyone has implemented that yet. Horses still out the barn door and we didn't close it yet, I'm not sure who to blame except us (would be barn-door closers, possibly in charge of those horses -- but perhaps they're not even ours!). I believe we could get rid of custom deleters from the Web platform if Firefox and IE remove support for custom deleters in LocalStorage, refuse to add it back, and refuse to implement it for DOMStringMap. If that happened, I'm sure other browsers and the spec would follow suit. I don't think I can convince my colleagues to remove the behavior from WebKit if Gecko and Trident continue to support it. I'll see what the relevant Mozilla WebAPI hackers think, if they're not reading this thread. At this point I suspect it is too late, in the sense that we'd be taking risks with plaform compatibility we don't accept in our release version/compatibility plan. What does typeof say for such a callable object? I think it should probably say object, though that's not compatible with ES3 or current WebKit practice. ES3 lets host objects choose function or object or any old string (Implementation-dependent). ES5 says: Object (native or host and does implement [[Call]]) - function Object (host and does not implement [[Call]]) - Implementation-defined except may not be undefined, boolean, number, or string. This is not an issue for DOM methods. It's an issue for interfaces such as HTMLCollection and HTMLFormElement that support indexing by function call syntax, for legacy compatibility reasons. Constructors like XMLHttpRequest, Option and Image also do not inherit from Function.prototype even though they are callable. Right, thanks for clarifying that. DOM collection types, even if callable (VBScript was to blame) are not function objects, and DOM constructors, unlike chapter 15 built-in ES constructors, are not generally function objects. This seems winning since developers want not only sane typeof, but .apply/call/bind. It's definitely winning, and it may be possible to apply it to global constructors that are also callable as a future improvement, but it's probably not possible to make HTMLCollection or HTMLFormElement inherit from the Function prototype, and I think it would not be desirable either. Why not for HTMLFormElement? Agree for HTMLCollection. Perhaps it's sufficient to provide an API for altering the [[Call]] and [[Construct]] behavior of an existing object without a first- class syntax, following in the spirit of defineOwnProperty(). Something like foo.defineOperation(construct, funcToCallWhenConstructing). This would address all of points 2 to 5, for ECMAScript implementations that wish to precisely replicate DOM behavior. This approach could also be used for index getters/ setters/has-testers, general catchall getters/setters/has-testers, removing either one of call or construct while retaining the other, making call and construct do different things, and perhaps other useses. And using a method instead of first-class syntax would let scripts feature-test for this capability. See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but note objections there, as well as some alternatives discussed in es-disc...@mozilla.org . A MOP for catchalls that stratifies the hooks into mirage (by analogy to mirror-based reflection) objects may be forthcoming; we'll see (I'll let the experts say more). A dark horse, at this point, but hey, those other horses made it out of the barn ;-). For simple things like non-constructor functions one might prefer a declarative form. As an implementor and a developer, I would -- mutation is a bitch to optimize in a VM, and to contain in one's user code. Also the meta-programming API seems likely to be more verbose than the (still elusive, but stipulate that it must be concise) hypothetical declarative syntax. Ye olde Image and Option, at least, act like most built-in constructors by constructing when called, at least in Gecko and I think IE -- but not in WebKit (I just tested). My
W3C process: was: ECMA TC 39 / W3C HTML and WebApps WG coordination
Yehuda, I have raised the issue[1][2] you outline with Ian Jacobs, the W3C Process working group and others at W3C, It's my particular concern and thesis that authors and end-users, including those requiring alternative affordance are not well represented on W3C working groups. Why is there no W3C UA Games technology or WG? regards Jonathan Chetwynd Honte.eu Jonathan Chetwynd j.chetw...@btinternet.com http://www.openicon.org/ +44 (0) 20 7978 1764 [1] On 24 Sep 2009, at 20:00, Yehuda Katz wrote: I'll think about it. I was mostly hoping to start a discussion about alternatives. I think the bottom line here is that while the spec is well-optimized for implementors, it is not very well optimized for consumers. I suppose it would be possible to say that this stuff is *only* for implementors. I'd prefer if it were also readable for those trying to use the specification. -- Yehuda [2] There are for instance a very large number of published comments raising similar concerns, regarding the technical language of WCAG2 - WAI, W3C.
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 27, 2009, at 12:30 AM, Brendan Eich wrote: On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote: What does typeof say for such a callable object? I think it should probably say object, though that's not compatible with ES3 or current WebKit practice. ES3 lets host objects choose function or object or any old string (Implementation-dependent). ES5 says: Object (native or host and does implement [[Call]]) - function Object (host and does not implement [[Call]]) - Implementation-defined except may not be undefined, boolean, number, or string. I think it may be a compatibility risk for HTMLCollection to report its type as function instead of object. This is not an issue for DOM methods. It's an issue for interfaces such as HTMLCollection and HTMLFormElement that support indexing by function call syntax, for legacy compatibility reasons. Constructors like XMLHttpRequest, Option and Image also do not inherit from Function.prototype even though they are callable. Right, thanks for clarifying that. DOM collection types, even if callable (VBScript was to blame) are not function objects, and DOM constructors, unlike chapter 15 built-in ES constructors, are not generally function objects. This seems winning since developers want not only sane typeof, but .apply/call/bind. It's definitely winning, and it may be possible to apply it to global constructors that are also callable as a future improvement, but it's probably not possible to make HTMLCollection or HTMLFormElement inherit from the Function prototype, and I think it would not be desirable either. Why not for HTMLFormElement? Agree for HTMLCollection. By HTMLFormElement I mean the actual instances that represent the form element in an HTML DOM, not the pseudo-constructor object named HTMLFormElement on the window object. HTML5 gives it callable indexing. It already inherits from HTMLElement (and Element and Node) so it's unclear how to stick Function into its prototype chain. And I don't think we want call(), apply() and bind() methods to start appearing on form elements. Perhaps it's sufficient to provide an API for altering the [[Call]] and [[Construct]] behavior of an existing object without a first- class syntax, following in the spirit of defineOwnProperty(). Something like foo.defineOperation(construct, funcToCallWhenConstructing). This would address all of points 2 to 5, for ECMAScript implementations that wish to precisely replicate DOM behavior. This approach could also be used for index getters/ setters/has-testers, general catchall getters/setters/has-testers, removing either one of call or construct while retaining the other, making call and construct do different things, and perhaps other useses. And using a method instead of first-class syntax would let scripts feature-test for this capability. See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but note objections there, as well as some alternatives discussed in es-disc...@mozilla.org . Thanks for the reference. That does look similar to my suggestion. However, it looks like the invoke and construct methods there are intended for calling a property of the object (or invoking it as a constructor), rather than for applying call or construct to the object itself. A MOP for catchalls that stratifies the hooks into mirage (by analogy to mirror-based reflection) objects may be forthcoming; we'll see (I'll let the experts say more). A dark horse, at this point, but hey, those other horses made it out of the barn ;-). For simple things like non-constructor functions one might prefer a declarative form. As an implementor and a developer, I would -- mutation is a bitch to optimize in a VM, and to contain in one's user code. Also the meta-programming API seems likely to be more verbose than the (still elusive, but stipulate that it must be concise) hypothetical declarative syntax. Sure - one way a MOP approach helps is by moving past debates about the most elegant syntax, by having unapologetically inelegant syntax. Then maybe once the capability is there, someone can invent good syntax later. Ye olde Image and Option, at least, act like most built-in constructors by constructing when called, at least in Gecko and I think IE -- but not in WebKit (I just tested). My testing seems to indicate not in IE. Likewise for XMLHttpRequest. We should probably specify one way or the other whether these are callable and stick to it. I am indifferent as to which behavior we standardize on. Me too, except if I had to do it all over again I would have worked harder to make function-ness orthogonal to prototype, a mixin if you will. I wish functions and constructors were different kinds of things. I'm not sure if that's the same kind of idea you're talking about. At this point,
ISSUE-105 (what is loading?): How should we count progress of things which are not measured in bytes? [Progress Events]
ISSUE-105 (what is loading?): How should we count progress of things which are not measured in bytes? [Progress Events] http://www.w3.org/2008/webapps/track/issues/105 Raised by: Charles McCathieNevile On product: Progress Events HTML 5 wants to count some file transfers using progress events. There are various UI components around that do that already. So should we have a flag or attribute that says what is being counted and keep using the total/loaded attributes, or should we have new atributes for this?
Re: Using progress events for other purposes
On Wed, 19 Aug 2009 07:50:04 +0200, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Aug 2009, Anne van Kesteren wrote: On Tue, 18 Aug 2009 00:38:49 +0200, Ian Hickson i...@hixie.ch wrote: The Application Cache feature in HTML5 uses an event named 'progress' as part of the process, in a manner mostly unrelated to the rest of the progress events feature. It needs two values of context information (number of files being downloaded, number of files obtained so far). Should I just reuse the ProgressEvents interface? It seems that doing so is a violation of the Progress Events specification, but I don't see why it should be. If we extend the ProgressEvent interface in the future we'd have to consider non-byte-length-based uses of it. Is that really a good idea? (I suppose that could be a different interface that extends ProgressEvent, but still.) If implementors would rather I made up a new interface that was nearly identical to ProgressEvent and used that, I can do that too. The alternative is to think now about extending Progress Events to deal with non byte-length progress (e.g. a series of transactions, each of which is very rapid alone but which add up to minutes). My preference would be to create new attributes for this case rather than overload the total/loaded attributes. A third approach would be to have a flag which specifies whether the total/loaded attributes measure bytes, and a related fourth would be to have an attribute that says what the total/loaded attributes are measuring. I have raised ISSUE-105 for this question. Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Using progress events for other purposes
On Sun, 27 Sep 2009, Charles McCathieNevile wrote: The alternative is to think now about extending Progress Events to deal with non byte-length progress (e.g. a series of transactions, each of which is very rapid alone but which add up to minutes). My preference would be to create new attributes for this case rather than overload the total/loaded attributes. A third approach would be to have a flag which specifies whether the total/loaded attributes measure bytes, and a related fourth would be to have an attribute that says what the total/loaded attributes are measuring. I have raised ISSUE-105 for this question. It's not clear to me why the current ProgressEvent interface couldn't be used as-is, other than the Progress Events spec saying so. It's not like the events could be confused with events where bytes are intended, in this particular case. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web IDL Garden Hose
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
This may provide a way to implement some of these behaviors in pure
ECMAScript. The current proposal does allow [[Construct]] without
[[Call]], but not [[Call]] and [[Construct]] that both exist but
with
different behavior.
Date needs the latter.
That can already be done in ES5. As I've previously suggested:
function Date(yearOrValue, month, date, hours, minutes, seconds,
ms) {
use strict;
if (this === undefined) {
return TimeToString(CurrentTime());
}
// constructor behaviour
...
}
Of course, a variation on the idiom.
This is similar to what many implementations do too, rather than the
implementation providing analogues of [[Call]] and [[Construct]]
internal method on a non-function Date object. It works for Boolean,
Number, String, and RegExp too.
But it is just a bit unsightly!
/be
New Progress editor's draft
Hi folks, it took a long time, but here it is: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.31 This attempts to clarify the things that Hixie says he doesn't understand, clean up some things noted by Kats and Garrett, and notes the issue raised by HTML 5's new and currently incompatible usage of progress events in the application cache[1] http://dev.w3.org/html5/spec/Overview.html#event-appcache-progress As always, comments welcome. Particularly, comments that relate to ISSUE-105 which *I think* is the only really unresolved technical issue. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Using progress events for other purposes
On Sun, 27 Sep 2009 20:20:52 +0200, Ian Hickson i...@hixie.ch wrote: On Sun, 27 Sep 2009, Charles McCathieNevile wrote: The alternative is to think now about extending Progress Events to deal with non byte-length progress (e.g. a series of transactions, each of which is very rapid alone but which add up to minutes). My preference would be to create new attributes for this case rather than overload the total/loaded attributes. A third approach would be to have a flag which specifies whether the total/loaded attributes measure bytes, and a related fourth would be to have an attribute that says what the total/loaded attributes are measuring. I have raised ISSUE-105 for this question. It's not clear to me why the current ProgressEvent interface couldn't be used as-is, other than the Progress Events spec saying so. That is indeed the only reason currently (and obviously it didn't stop you putting it into an HTML5 draft, so it doesn't seem to be a strong reason :) ). It's not like the events could be confused with events where bytes are intended, in this particular case. True. The question is whether this particular case is representative - one use case isn't always a great basis for deciding a set of requirements. So in the interest of helping explain my thinking (and making me think further), I am also wondering about the following use case: I want a web application that fetches mail, and it wants to specify progress both in terms of the number of messages transferred, and where a transfer lasts more than a quarter of a second, progress in fetching that message. (This is carefully made up by looking at my current mail client). A simple way to do this would be to fire a progress event at the completion of each message being received, and to fire one every quarter-second during a transfer where the message is big enough or moving slowly enough to hold up progress. But it isn't clear to me how easy it is to distinguish these messages - while I haven't written the code, it seems to me that I want to fire events on basically the same targets. So it isn't clear how I would hook them up to do something useful. A similar question arises for me in application cache itself, where I want some files that are very big, and some that are very small, in a parallel manner. (Very big just means to big to move more or less instantaneously. There are plenty of widgets bigger than 1MB and plenty of networks that make that take real time, and implementations pop up real progress bars now on downloading). This is what leads me to question the approach you have taken so far. A solution may be to look at the targets of the events as the distinguishing feature, but in my head I don't see a clear way to do that. I would therefore appreciate further input. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Web IDL Garden Hose
On 9/27/09 3:30 AM, Brendan Eich wrote: I believe we could get rid of custom deleters from the Web platform if Firefox and IE remove support for custom deleters in LocalStorage, refuse to add it back, and refuse to implement it for DOMStringMap. If that happened, I'm sure other browsers and the spec would follow suit. I don't think I can convince my colleagues to remove the behavior from WebKit if Gecko and Trident continue to support it. I'll see what the relevant Mozilla WebAPI hackers think, if they're not reading this thread. At this point I suspect it is too late, in the sense that we'd be taking risks with plaform compatibility we don't accept in our release version/compatibility plan. Well, that depends on what we mean by remove. Probably not removable in Gecko 1.9.1.x security updates. Probably removable (in my opinion) in Gecko 1.9.3. Possibly in Gecko 1.9.2 if the decision is made soon. What I don't have is data on how much the syntax is used, or how likely Trident is to remove it too. If we remove it and Trident doesn't and that means Webkit keeps shipping it and the spec doesn't change as a result (which sounds to me like what Maciej is saying will be the outcome in this situation; the spec part is my guess based on the .tags experience) then from our point of view it's just wasted effort and web developers being pissed off at us for not implementing The Spec (without understanding that it's an early draft) and then we'd end up just having to put deleters back in but lose a bunch of goodwill. That's a strictly losing proposition for us. If Webkit commits to removing if we remove and the editor commits to removing from the spec in that circumstance, then I think we could make the removal stick no matter what Trident does... -Boris P.S. I _am_ ccing es-discuss on this as on my other mails, but of course that list bounces all mail from me, since I'm not a member. If someone cares about letting that list's membership know that they're missing part of the discussion and is able to do so, please go for it.
Re: Web IDL Garden Hose
On 9/27/09 2:28 AM, Maciej Stachowiak wrote:
This is not an issue for DOM methods. It's an issue for interfaces such
as HTMLCollection and HTMLFormElement that support indexing by function
call syntax, for legacy compatibility reasons.
Huh. Gecko hasn't supported this, and we haven't had problems with it.
Is it really for legacy compat reasons, of just because more than one
vendor happens to support it without really knowing why, like tags() on
HTMLCollection? Did Webkit and Opera have particular compat issues
without implementing this stuff?
For what it's worth, I just tested and it looks like Opera and Webkit
support () on HTMLCollection; the former doesn't support it on the
return value of getElementsByTagName while the latter does. Gecko does
not support either. The spec also has the () thing going on for
HTMLFormControlsCollection; again we've never had any serious compat
problems with this in Gecko.
As for HTMLFormElement, while the spec says what it says, it's not
exactly for compatibility reasons other than IE must be willing to
implement this spec and nothing outside this spec, I assume. Both
Opera and Webkit throw in this testcase:
!DOCTYPE html
body
form name=foo
input name=bar
scripttry {
alert(document.foo(bar));
} catch(e) { alert(e); }
/script
whereas they should return the input, per spec.
I hadn't realizes the spec required this syntax, and I would be somewhat
interested in understanding why it does and whether it's actually
required for compatibility reasons (in the sense that a new UA on the
market would have to implement it to be compatible with existing sites).
-Boris
Re: Cross posting madness must stop.
On Sep 27, 2009, at 12:35 PM, Mark S. Miller wrote: Comparing https://mail.mozilla.org/pipermail/es-discuss/2009-September/ with http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/ and http://lists.w3.org/Archives/Public/public-html/2009Sep/ shows why this cross posting madness must stop. Some messages in this thread are only posted to one side of the W3C / ECMA divide, indicating that some posters only subscribe on one side. These posters are mutually opaque to the posters subscribing only on the other side of the divide, leading to a fragmented conversation. For example, the excellent posts by David-Sarah Hopwood https://mail.mozilla.org/pipermail/es-discuss/2009-September/author.html#9879 have generally gotten responses only from the ECMA side. Some later messages from the W3C side seem to have missed some of his points. Rather than create a list specific to the WebIDL-ES5 language bindings, I suggest an open public list for discussions likely to be of interest to both communities. Are there any territoriality issues one should be aware of before creating such a list? Cross posting isn't great, but a brand new list will be missing many people with an interest in the topic for a while until it ramps up. In the meantime, I think both es-discuss and public-webapps are open for anyone to subscribe to (public-html ironically requires more hoops, since you have to be part of a W3C Member organization or become an invited expert). I'm subscribed to all 3 lists so my only annoyance is getting multiple copies of every email. My point is this: we're having a really fruitful discussion right now, one that was long overdue. While there are some mechanically bad things about the way we're doing it, I'd like to avoid killing the momentum. So let's keep talking this way, as long as we have useful things to say, and until we can create a better mechanism. For the slightly longer term: I think a list for general ECMA/W3C scripting coordination is a good idea. But I'd also like that to be the main list we use for the development of Web IDL, since any discussion about WebIDL is likely to be of cross-functional interest. And I don't want to make people subscribe to two new lists. Whether we call it public-webidl or public-scripting-coordination doesn't matter that much to me. Preference? W3C can probably set up such a list in fairly short order, but likely not until Monday. Regards, Maciej
Re: Web IDL Garden Hose
On Sep 27, 2009, at 11:14 AM, Brendan Eich wrote:
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
This may provide a way to implement some of these behaviors in pure
ECMAScript. The current proposal does allow [[Construct]] without
[[Call]], but not [[Call]] and [[Construct]] that both exist but
with
different behavior.
Date needs the latter.
That can already be done in ES5. As I've previously suggested:
function Date(yearOrValue, month, date, hours, minutes, seconds,
ms) {
use strict;
if (this === undefined) {
return TimeToString(CurrentTime());
}
// constructor behaviour
...
}
Of course, a variation on the idiom.
This is similar to what many implementations do too, rather than the
implementation providing analogues of [[Call]] and [[Construct]]
internal method on a non-function Date object. It works for Boolean,
Number, String, and RegExp too.
But it is just a bit unsightly!
Will this do the right thing if you explicitly bind Date to a this
value, for example, by calling it as window.Date(), or using call,
apply, or function.bind, or by storing Date as the property of another
random object?
Regards,
Maciej
Fwd: Cross posting madness must stop.
-- Forwarded message -- From: David-Sarah Hopwood david-sa...@jacaranda.org Date: Sun, Sep 27, 2009 at 4:05 PM Subject: Re: Cross posting madness must stop. To: es-disc...@mozilla.org Mark S. Miller wrote: Comparing https://mail.mozilla.org/pipermail/es-discuss/2009-September/ with http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ and http://lists.w3.org/Archives/Public/public-html/2009Sep/ shows why this cross posting madness must stop. Some messages in this thread are only posted to one side of the W3C / ECMA divide, indicating that some posters only subscribe on one side. These posters are mutually opaque to the posters subscribing only on the other side of the divide, leading to a fragmented conversation. For example, the excellent posts by David-Sarah Hopwood https://mail.mozilla.org/pipermail/es-discuss/2009-September/author.html#9879 have generally gotten responses only from the ECMA side. Some later messages from the W3C side seem to have missed some of [their] points. Indeed, I hadn't realized that my cc:s to public-webapps and public-html were being dropped *silently*, without any bounce message. If that's due to the configuation of those lists, then it's a rather user-hostile mailing list behaviour, IMHO -- problems with spam notwithstanding. A subsequent attempt to subscribe to public-html as per the instructions at http://www.w3.org/Mail/Request, bounced with error 550 Unrouteable address (state 14). Mark, please forward this. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com ___ es-discuss mailing list es-disc...@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM
Re: Cross posting madness must stop.
On Sun, Sep 27, 2009 at 4:00 PM, Maciej Stachowiak m...@apple.com wrote: Cross posting isn't great, but a brand new list will be missing many people with an interest in the topic for a while until it ramps up. In the meantime, I think both es-discuss and public-webapps are open for anyone to subscribe to (public-html ironically requires more hoops, since you have to be part of a W3C Member organization or become an invited expert). I'm subscribed to all 3 lists so my only annoyance is getting multiple copies of every email. My point is this: we're having a really fruitful discussion right now, one that was long overdue. Enthusiastic +1! While there are some mechanically bad things about the way we're doing it, I'd like to avoid killing the momentum. So let's keep talking this way, as long as we have useful things to say, and until we can create a better mechanism. Agreed. Given what you say about public-html, perhaps we should drop it. In any case, I encourage everyone on any of these three lists who is interested in this discussion to subscribe to both public-webapps and es-discuss so you do not miss any messages by people who aren't, and so that your messages aren't missed. For the slightly longer term: I think a list for general ECMA/W3C scripting coordination is a good idea. But I'd also like that to be the main list we use for the development of Web IDL, since any discussion about WebIDL is likely to be of cross-functional interest. And I don't want to make people subscribe to two new lists. Whether we call it public-webidl or public-scripting-coordination doesn't matter that much to me. Preference? W3C can probably set up such a list in fairly short order, but likely not until Monday. I like the latter except for the length. How about public-scripting? Monday would be great. -- Cheers, --MarkM
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote: On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote: I'm musing a bit here, bear with me. If we only hack incrementally, and preserve backward compatibility with frankly dumb (or merely hasty) design decisions (many mine!) then we'll probably make less progress than if we try to rationalize old and new in a better systematic design. That's a little too abstract for me to tell if I agree or not. Shortest-path evolution can walk uphill only a little bit at a time, and get stuck at local minimal points in a design space, when over the big hill is a much better, richer valley to evolve in. This path dependency problem bits many real-world systems. I experience this point as hard and painful, like concrete -- it' s not abstract. I've been around too long to ignore it, as it's all around us on the web, and it has been since 1994 if not earlier. Compatibility concerns in the form of graceful degradation or progressive enhancement are not unmixed blessings. More coherent stacks from Microsoft, Adobe, and Sun can rightly claim to solve problems more cleanly and simply than the web. Of course these stacks have other problems, mainly from being single-sourced if not proprietary, but also from not progressing compatibly, and for other reasons I won't digress on. But there's no point pretending the Web (ES, DOM, etc.) is an example of a well-designed toolkit for building user-facing distributed apps! But we're not really free to discard compatibility. So I'm not that excited about the exciting opportunities we could have if we did. The Web is a duct tape design but it works. Dropping compatibility would kill one of its biggest advantages. Systems that discard compatibility can also deliver an unusable Second System, especially when designed by committee. I would point to certain W3C specs that chose to break compatibility with existing practice. They are often not only undeployable but also not very compelling on their own terms. I think compatibility constraints, even though they impose messy and illogical quirks, can also act as a healthy counterweight to flights of design fancy. Constraints make for good art. Regards, Maciej
Re: Web IDL Garden Hose
On Sep 27, 2009, at 12:23 PM, Boris Zbarsky wrote: On 9/27/09 3:30 AM, Brendan Eich wrote: I believe we could get rid of custom deleters from the Web platform if Firefox and IE remove support for custom deleters in LocalStorage, refuse to add it back, and refuse to implement it for DOMStringMap. If that happened, I'm sure other browsers and the spec would follow suit. I don't think I can convince my colleagues to remove the behavior from WebKit if Gecko and Trident continue to support it. I'll see what the relevant Mozilla WebAPI hackers think, if they're not reading this thread. At this point I suspect it is too late, in the sense that we'd be taking risks with plaform compatibility we don't accept in our release version/compatibility plan. Well, that depends on what we mean by remove. Probably not removable in Gecko 1.9.1.x security updates. Probably removable (in my opinion) in Gecko 1.9.3. Possibly in Gecko 1.9.2 if the decision is made soon. What I don't have is data on how much the syntax is used, or how likely Trident is to remove it too. If we remove it and Trident doesn't and that means Webkit keeps shipping it and the spec doesn't change as a result (which sounds to me like what Maciej is saying will be the outcome in this situation; the spec part is my guess based on the .tags experience) then from our point of view it's just wasted effort and web developers being pissed off at us for not implementing The Spec (without understanding that it's an early draft) and then we'd end up just having to put deleters back in but lose a bunch of goodwill. That's a strictly losing proposition for us. If Webkit commits to removing if we remove and the editor commits to removing from the spec in that circumstance, then I think we could make the removal stick no matter what Trident does... I could probably go along with that plan, if we are really motivated to do this. It would be good to have Microsoft's input as well. I would also find data about use of this syntax useful, if anyone has any. P.S. I _am_ ccing es-discuss on this as on my other mails, but of course that list bounces all mail from me, since I'm not a member. If someone cares about letting that list's membership know that they're missing part of the discussion and is able to do so, please go for it. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote: On Sep 27, 2009, at 00:36 , Cameron McCormack wrote: 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 track? I would tend to be rather in disfavour of anything that might cause WebIDL to be delayed in any way. I also think that keeping the ES3 binding is useful (in the short term at least) if only because it is familiar, which might point to building the ES5 one separately. If at all possible I'd rather it went to LC ASAP, and if needed that new stuff be done in a branched document. Based on the conversation so far, I expect Web IDL in roughly its current state would not survive Last Call. - Maciej
Re: Web IDL Garden Hose
On Sep 27, 2009, at 12:37 PM, Boris Zbarsky wrote:
On 9/27/09 2:28 AM, Maciej Stachowiak wrote:
This is not an issue for DOM methods. It's an issue for interfaces
such
as HTMLCollection and HTMLFormElement that support indexing by
function
call syntax, for legacy compatibility reasons.
Huh. Gecko hasn't supported this, and we haven't had problems with
it. Is it really for legacy compat reasons, of just because more
than one vendor happens to support it without really knowing why,
like tags() on HTMLCollection? Did Webkit and Opera have particular
compat issues without implementing this stuff?
For what it's worth, I just tested and it looks like Opera and
Webkit support () on HTMLCollection; the former doesn't support it
on the return value of getElementsByTagName while the latter does.
Gecko does not support either. The spec also has the () thing going
on for HTMLFormControlsCollection; again we've never had any serious
compat problems with this in Gecko.
As for HTMLFormElement, while the spec says what it says, it's not
exactly for compatibility reasons other than IE must be willing
to implement this spec and nothing outside this spec, I assume.
Both Opera and Webkit throw in this testcase:
!DOCTYPE html
body
form name=foo
input name=bar
scripttry {
alert(document.foo(bar));
} catch(e) { alert(e); }
/script
whereas they should return the input, per spec.
I hadn't realizes the spec required this syntax, and I would be
somewhat interested in understanding why it does and whether it's
actually required for compatibility reasons (in the sense that a
new UA on the market would have to implement it to be compatible
with existing sites).
I wouldn't be against dropping things that we really think are
useless. Keep in mind though, there is still old content (yes, often
on Intranets, but sometimes publicly accessible) that just assumes IE,
but more or less works if you implement enough IE-isms. That's the
rationale behind undetectable document.all. Callable collections are
based on the same kind of reasoning. Historically, Opera and Safari
(and Konqueror/KHTML before us) have been somewhat more willing to
implement weird IE-isms than Mozilla.
Regards,
Maciej
Re: Cross posting madness must stop.
On Sep 27, 2009, at 4:07 PM, Mark S. Miller wrote: Indeed, I hadn't realized that my cc:s to public-webapps and public- html were being dropped *silently*, without any bounce message. If that's due to the configuation of those lists, then it's a rather user-hostile mailing list behaviour, IMHO -- problems with spam notwithstanding. To clarify, public-webapps and public-html do not silently bounce messages. But they do hold messages from non-subscribers for approval, which usually happens within a business day or two. Regards, Maciej
Let's set up a mailing list for coordination with ECMA and Web IDL discussion
ECMA TC39 (the group responsible for ECMAScript) has expressed a strong interest in having a list for joint discussion with the W3C, and particularly the Web Apps WG. And they are especially interested in review of Web IDL. I suggest we set up public-script...@w3.org (name suggested by Mark Miller) as a list managed by the Web Apps WG for both purposes - discussion of Web IDL, and other scripting-related coordination issues. I think this would be better than the massive cross-posting we've experienced over the past few days. Does this sound like a good idea to everyone? If so, how quickly can we get it done? Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 27, 2009, at 4:15 PM, Maciej Stachowiak wrote: On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote: But there's no point pretending the Web (ES, DOM, etc.) is an example of a well-designed toolkit for building user-facing distributed apps! But we're not really free to discard compatibility. So I'm not that excited about the exciting opportunities we could have if we did. The Web is a duct tape design but it works. Dropping compatibility would kill one of its biggest advantages. Sure. You didn't see me proposing dropping Web compatibility (suicide for browser vendors) -- rather, I'm talking about doing end-to-end design as we go, and meeting in the middle. Too many short hops via a standard body incurs high costs in the spec process (some essential, some not) while tending to enshrine mistakes over time due to compatibility. Whereas taking big hops risks mission creep, or mission cliff-dive into second-system death-beach ;-), or even the old mistake of targeting a market foreseen five years out that never arrives (the real world zigged instead of zagging). We've all seen these problems, I think, over our careers. And it's not as if the proprietary languages and stacks can break compatibility excessively (search for Visual Fred). But they can and do provide new and more coherent API-sets that help deprecate old ones. To avoid proprietary stack examples, consider Python's from __future__ import mechanism: http://www.python.org/dev/peps/pep-0236/ This precedent is attractive if one can push out new versions of the language implementation, with carrots to induce people to upgrade, as well as the stick of unsupported ancient versions. It helps that C- Python is source-as-spec, but let's say that is a non-issue with good- enough ES specs. The carrots instead of sticks idea is more critical from what I have seen, for Python and for JavaScript -- we can't get people to stop doing what worked if there's no new and better way (the recent arguments.callee in strict mode thread highlighted this point). Of course, the web is too big to try to get away with deprecation/ obsolescence cycles on any predictable near-term release schedule. Never mind coordination among browser vendors on their next versions -- IE6 is still Out There. But perhaps once past IE6, though, with modern browsers auto-updating, we'll see the downrev implementations go away faster. There's a chance, anyway, from what I see of IE8 replacing IE7, and of course faster updating for other, fresher browsers ;-). If we do see a world where browser version uptake is faster, and the downrev problem shrinks or becomes more tractable somehow, then we will want shinier duct tape without bits of lint and trash stuck to the edges of the tape roll, over time. Every compatibility constraint costs non-linearly when refracted through the whole-language design process. So part of ECMAScript Harmony is not just ES6, a prematurely- triaged, shortest-path evolutionary jump, but longer-term end to end design that ultimately puts the TC39 committee out of the language- extension business by empowering developers to bootstrap new language versions by themselves. Systems that discard compatibility can also deliver an unusable Second System, especially when designed by committee. I would point to certain W3C specs that chose to break compatibility with existing practice. They are often not only undeployable but also not very compelling on their own terms. Agreed. I think compatibility constraints, even though they impose messy and illogical quirks, can also act as a healthy counterweight to flights of design fancy. Constraints make for good art. We seem to have some unnecessary constraints, which are bad for art and science. Let's try to get rid of the foo(i) for foo[i] or foo.item[i] non-mandatory compatibility cruft and see how that goes. /be
Re: Let's set up a mailing list for coordination with ECMA and Web IDL discussion
On Sep 27, 2009, at 7:33 PM, ext Maciej Stachowiak wrote: ECMA TC39 (the group responsible for ECMAScript) has expressed a strong interest in having a list for joint discussion with the W3C, and particularly the Web Apps WG. And they are especially interested in review of Web IDL. I suggest we set up public-script...@w3.org (name suggested by Mark Miller) as a list managed by the Web Apps WG for both purposes - discussion of Web IDL, and other scripting-related coordination issues. I think this would be better than the massive cross-posting we've experienced over the past few days. Does this sound like a good idea to everyone? The only concern I have is the potential for an input from someone who has not agreed to the W3C's Patent Policy (PP) to be included in one of our specs. In practice, the risk for this scenario for the Web IDL spec appears to be relatively low. However, at least one of the messages in one of these related threads implied there may be an impedance mismatch between ECMA's patent policy and the W3C's PP. I think we should get some input from the W3C Team here but it appears the benefits of this proposed list i.e. increased communication between ECMA and W3C, outweigh the IP risks so you get a tentative Yes from me. FWIW, I think Doug's earlier proposal to name this list public-idl was good but I am mostly indifferent as to the name and could certainly live with public-scripting. Mike, Doug - please pursue creating the list. -Regards, Art Barstow If so, how quickly can we get it done? Regards, Maciej
Re: Let's set up a mailing list for coordination with ECMA and Web IDL discussion
Maciej All, While I am just an independent implementor of WebIDL, if my opinion counts, I'd support the idea to have a separate list for WebIDL discussions. On Sun, Sep 27, 2009 at 7:33 PM, Maciej Stachowiak m...@apple.com wrote: of Web IDL. I suggest we set up public-script...@w3.org (name suggested by Mark Miller) as a list managed by the Web Apps WG for both purposes - discussion of Web IDL, and other scripting-related coordination issues. I [skip] Does this sound like a good idea to everyone? If so, how quickly can we get it done? Thanks -- Dimitry Golubovsky Anywhere on the Web
Re: Let's set up a mailing list for coordination with ECMA and Web IDL discussion
On Sep 27, 2009, at 5:24 PM, Arthur Barstow wrote: On Sep 27, 2009, at 7:33 PM, ext Maciej Stachowiak wrote: ECMA TC39 (the group responsible for ECMAScript) has expressed a strong interest in having a list for joint discussion with the W3C, and particularly the Web Apps WG. And they are especially interested in review of Web IDL. I suggest we set up public-script...@w3.org (name suggested by Mark Miller) as a list managed by the Web Apps WG for both purposes - discussion of Web IDL, and other scripting- related coordination issues. I think this would be better than the massive cross-posting we've experienced over the past few days. Does this sound like a good idea to everyone? The only concern I have is the potential for an input from someone who has not agreed to the W3C's Patent Policy (PP) to be included in one of our specs. In practice, the risk for this scenario for the Web IDL spec appears to be relatively low. However, at least one of the messages in one of these related threads implied there may be an impedance mismatch between ECMA's patent policy and the W3C's PP. There is that risk. However, public-webapps and www-dom are also open to subscription by anyone, as I understand it. In any of these cases anyone giving major technical input should probably be asked to agree to the W3C Patent Policy. I think we should get some input from the W3C Team here but it appears the benefits of this proposed list i.e. increased communication between ECMA and W3C, outweigh the IP risks so you get a tentative Yes from me. FWIW, I think Doug's earlier proposal to name this list public-idl was good but I am mostly indifferent as to the name and could certainly live with public-scripting. Mike, Doug - please pursue creating the list. I thought public-idl was also good, but the more general name might make it a decent place to discuss issues that are not strictly Web IDL, such as the need for a data type for binary data. Regards, Maciej
Re: Let's set up a mailing list for coordination with ECMA and Web IDL discussion
Hi, Folks- I've submitted the request for public-script...@w3.org, and I anticipate that this will be created Monday (tomorrow). Thanks to everyone for the discussion leading up to this... I'm very happy that this coordination is going on. I will announce when the list is ready, with instructions on how folks can subscribe themselves. Art, I understand your concern and will ask the Team to look at the issue of IP risks in this scenario, but in light of public comments in general, I don't anticipate that this will be a major issue... we will have to be careful in how we deal with significant and substantive feature requests, of course. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Arthur Barstow wrote (on 9/27/09 5:24 PM): On Sep 27, 2009, at 7:33 PM, ext Maciej Stachowiak wrote: ECMA TC39 (the group responsible for ECMAScript) has expressed a strong interest in having a list for joint discussion with the W3C, and particularly the Web Apps WG. And they are especially interested in review of Web IDL. I suggest we set up public-script...@w3.org (name suggested by Mark Miller) as a list managed by the Web Apps WG for both purposes - discussion of Web IDL, and other scripting-related coordination issues. I think this would be better than the massive cross-posting we've experienced over the past few days. Does this sound like a good idea to everyone? The only concern I have is the potential for an input from someone who has not agreed to the W3C's Patent Policy (PP) to be included in one of our specs. In practice, the risk for this scenario for the Web IDL spec appears to be relatively low. However, at least one of the messages in one of these related threads implied there may be an impedance mismatch between ECMA's patent policy and the W3C's PP. I think we should get some input from the W3C Team here but it appears the benefits of this proposed list i.e. increased communication between ECMA and W3C, outweigh the IP risks so you get a tentative Yes from me. FWIW, I think Doug's earlier proposal to name this list public-idl was good but I am mostly indifferent as to the name and could certainly live with public-scripting. Mike, Doug - please pursue creating the list. -Regards, Art Barstow If so, how quickly can we get it done? Regards, Maciej
