RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Yehuda Katz Another way to put my earlier concern is: It's impossible to write a conforming JS engine that browsers will want to use by only following the ES spec - since there's additional, un-speced, behavior that isn't in ES that is necessary in order to construct a browser's DOM. Consider the following scenario: I write an ECMAScript engine that is significantly faster than any existing engine by simply following the ECMAScript spec. A browser maker then wishes to use this engine. This would be impossible without adding additional (hidden) features to the engine to support the DOM. There is nothing in the ECMAScript spec that requires the ability (at the very least) to add native extensions with arbitrary behavior to the engine. Is this a requirement ECMA is comfortable with? No we are not. This is exactly the heart of our concern. The WebIDL ECMAScript binding is not simply a mapping of IDL interface onto standard language features (such as is done for the Java binding). While it has some of that it also defines an extended ECMAScrpt language with new semantics. (and I understand this is mostly a reflection of past (present?) practice of browser implementers). Essentially, the semantics of browser ECMAScript has been arbitrarily split into two independently maintained standards. Language design is not primarily about designing individual isolated features. The hard parts of language design involves the interactions among such features and typically requires making design trade-offs and alteration to ensure that all features compose coherently. If the language specification responsibilities are arbitrarily broken into two uncoordinated activities then it is impossible for either to do the global design that is necessary to have a complete and sound language and specification. TC39 has the language design expertise. W3C has Web API design expertise. If there are language design issues that must be addressed in order to fully specify browser ECMAScript (and there are) then those issues need to be addressed by TC39. Perhaps TC309 has been remiss in the past in addressing these browser specific language design issues. If so, it was probably for historic political and competitive reasons that don't necessarily apply today. That is what we want to fix. Allen Wirfs-Brock Microsoft
Re: WebIDL
On Sep 25, 2009, at 11:43 PM, Yehuda Katz wrote: Do we disagree that it is a worthy goal to have a specification that can be understood without having to take a while? I certainly understand the utility in using something with precedent like IDL (for implementors). Perhaps the IDL version could be part of an addendum, and something What something? with less historical and conceptual baggage be used inline? Or is that too much work? Do the work, it's the only way to get to something and make it stick. I don't think we should continue cross-posting like this to three standards groups' lists. Yes, old and layered specs are often complex, even over-complicated. No, we can't fix that complexity in the case of WebIDL by rewriting the extant interface descriptions in ES. As Maciej noted, doing so would cost ~10x the source lines, and beyond verbosity would be incredibly unclear and error-prone. Those who seek to replace WebIDL must first grok what it means, how it is used. To do that, I suggest trimming cross-posts, and even before replying, reading up on the relevant WebIDL docs and list. Once you've braced yourself for this process, and gotten further into it, I am sure that a QA process will work better. You are absolutely correct that the specs are complex and have gaps. Every engineer who has worked on a web-compatible browser has had to learn this the hard way. I don't expect the Web to be done but I do think better specs will close gaps and reduce some of the complexity over time. That's the hope behind this overlong, cross-posted thread, anyway. I'll shut up now. /be
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich bren...@mozilla.com wrote: On Sep 25, 2009, at 11:20 PM, Yehuda Katz wrote: On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich bren...@mozilla.com wrote: On Sep 25, 2009, at 9:38 PM, Yehuda Katz wrote: Another way to put my earlier concern Sorry, what earlier concern? You are replying to my reply to Doug Schepers on a sub-thread where I didn't see a message from you. So confusing! So many messages! No, you just replied off-topic and rehashed an issue that we all agree needs fixing, seemingly as if I had implied that it wasn't an issue. Although the generous citations of my reply to Doug Schepers that you included of course implied nothing of the kind. Why did you do that? I failed? There are about 100 messages on this topic that I'm reading and trying to digest. There's a whole lot of history involved. In the end, I can only speak for myself, and I can say that I'm personally having a lot of trouble trying to piece things together by looking at the specifications. [big snip] My point is that understanding the semantics of the language as implemented by browser vendors is not possible by reading the language spec. These is not some hypothetical extension, but a mandatory way that ECMAScript implemented for the web must behave. Well, duh. We seem to agree, perhaps vehemently :-/. One last time, for the record: it is a bug in ES specs that you can't follow th The whole point of bothering the HTML WG, public-webapps, and es-discuss about collaboration between Ecma and W3C folks has been to fill gaps between specs and reality. We had some false starts in my view (like trying to move ES WebIDL bindings to Ecma up front, or ever). But the issues laid out in Sam's original cross-post were exactly the gaps between ES specs, HTML5 ones, and browser implementations. At last some of the gaps are filled in HTML5 but not in ways that can be injected directly into ES specs. I'm actually being a bit more radical than you are (perhaps naïvely). I am personally finding WebIDL to be a blocker to understanding. That's because it's another spec that interacts with two other (fairly complex) specs in unpredictable and context-sensitive ways. We should fix the ES specs, and make whatever changes follow to the HTML5 specs. And maybe use WebIDL to constrain host objects. All this has been said on the thread already. Were you not reading the messages I was? I think I saw that in the thread ;) Like I said, my problem is that the interaction between the three specs is making it nearly impossible for a casual reader to understand what's going on. I strongly apologize for not being clearer about that; I'm only starting to fully understand the source of my own confusion. /be -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 25, 2009, at 11:32 PM, Brendan Eich wrote: On Sep 25, 2009, at 11:28 PM, Brendan Eich wrote: We seem to agree, perhaps vehemently :-/. One last time, for the record: it is a bug in ES specs that you can't follow th Sorry, rogue cut before send. it's a bug in ES specs that you can't follow them in order to implement a web-compatible JS engine. Although some of web-compatible JS really does belong in W3C specs, not ES specs, it's clear ES1 pretending there is only one global object did no one any favors. Ditto for execution model and (ultimately) split windows, as Hixie pointed out in raising the conflict between HTML5 and ES1-3 (and now ES5). Just wanted to reassure you, since you seemed to think otherwise, that no one views it as a feature that ES specs don't specify enough. HTML4 specs didn't either. We're getting there. That's right. ES3, HTML4 and DOM Level 2 were all missing many things needed to implement Web-compatible behavior, as well as having requirements that were in some cases contrary to real-world compatibility. Writing a new browser engine based on those specs required multiple years of trial and error and reverse engineering after implementing the spec behavior. Take it from me - that's what we had to do to make WebKit (even building on the foundation of KHTML +KJS, which had already done some of the reverse engineering). ES5, HTML5, Web IDL and some of the Web Apps specs (like XMLHttpRequest and DOM3 Events) are huge steps forward on this front. They don't solve every problem, but they are massive improvements in getting the Web platform correctly specified. Regards, Maciej
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
On Sep 26, 2009, at 12:20 AM, David-Sarah Hopwood wrote: Maciej Stachowiak wrote: I think there are two possible perspectives on what constitutes magnify[ing] the problem or widening the gap A) Any new kind of requirement for implementations of object interfaces that can't be implemented in pure ECMAScript expands the scope of the problem. B) Any new interface that isn't implementable in ECMAScript widens the gap, even if it is for a reason that also applies to legacy My view is firmly B, for the reasons given below. My view is A. That's why I pointed to legacy interfaces - if the construct can't go away from APIs in general, but we wish to implement all APIs in ECMAScript, then ultimately it is ECMAScript that must change, so using the same construct again doesn't create a new problem. Yes it does: - In many cases, APIs are partially redundant, in such a way that developers can choose to avoid some of the legacy interfaces without any significant loss of functionality. By doing so, they can avoid the problems caused by clashes between names defined in HTML, and names of ECMAScript methods. If new APIs also use catch-alls, they are less likely to be able to do this. - The potential name clashes created by catch-alls also create a forward compatibility issue: if a new method is added to an interface, it might clash with names used in existing HTML content. In the case of legacy interfaces, it is less likely that we want to add new methods to them, and so this forward compatibility issue is less of a problem. It seems like these first two reasons are pragmatic concerns about fully general property access catchalls, which are independent of anyone's desire to implement the interfaces in ECMAScript. These arguments also do not apply to other kinds of extended host object behavior, such as array-like index access, or the fact that document.all compares as boolean false. - Implementors of subsets in which the DOM APIs are tamed for security reasons can choose not to implement some APIs that are problematic for them to support; but if new APIs are equally problematic, they will be unable to provide access to that functionality. I think trying to tame the DOM APIs is a quixotic task anyway. A common example cited is to embedding a widget via direct DOM embedding in a safe way. Presumably safe means you have toprevent the widget reading or modifying the DOM outside its subtree, prevent executing JS outside the sandbox, and prevent displaying content outside its designated bounds. To achieve this, you have to restrict the behavior of nearly every single DOM method, often in extremely complicated ways that amount to reimplementing major portions of browser functionality. Consider for example the setAttribute method on the Element interface. You have to intercept attempts to set the style attribute, parse the CSS being set, and make sure that the widget is not trying to use CSS positioning or overflow to display outside its bounds. You can't just forbid CSS styling entirely, because that makes it impossible to make a decent-looking widget. previousSibling, nextSibling, ownerDocument all have to be prevented from going outside the tree. Any method to find particular elements has to be essentially rewritten to prevent going outside the tree, even something as basic as document.getElementById(). Attempts to set the id attribute have to be intercepted and the id has to be silently rewritten if it clashes with an id used in the embedding content, so that getElementById() calls by the embedder aren't tricked into manipulating the embedded content. Timers have to be reimplemented to make sure their JavaScript is executed in the sandbox. Setting a href to a javascript: URL has to be prevented, unless you completely override the navigation behavior of a elements. Creating plugins or Java applets has to be prevented, since they can't be made to follow the security constraints. document.write() and innerHTML have to be intercepted, and the contents have to be parsed as HTML to prevent any forbidden constructs in the markup. This is just scratching the surface, and we've already found that CSS parsing, HTML parsing and DOM query methods will have to be reimplemented (from scratch, yet in a way that matches what the browser does) to make this work. Note that none of this complexity is imposed by exotic host object behaviors, it's all intrinsic to the way the Web platform works. Even considering the case of taming LocalStorage, the catchall behavior is the least of your worries. The best way to serve this kind of use case is either an iframe with postMessage, or inventing an entirely new API for embedded content that doesn't even try to look anything like the DOM, and just exposes a carefully selected set of capabilities. I don't think our time is well spent trying to
Re: WebIDL
On Sep 25, 2009, at 11:33 PM, Yehuda Katz wrote: WebIDL, taken as a whole, make it very difficult for someone new to the spec(s) to understand what's going on. I started, like a reasonable person, by looking at the Window object. When looking at it, I encountered a number of somewhat confusing constructs, like this one. It is possible to have a long conversation where all of the details are hashed out, but the reality is that the specs cannot be easily understood without such a hashing. Window probably has more bizarre legacy behavior than any other interface. It's probably not the best starting point for understanding. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote: No we are not. This is exactly the heart of our concern. The WebIDL ECMAScript binding is not simply a mapping of IDL interface onto standard language features (such as is done for the Java binding). While it has some of that it also defines an extended ECMAScrpt language with new semantics. (and I understand this is mostly a reflection of past (present?) practice of browser implementers). Essentially, the semantics of browser ECMAScript has been arbitrarily split into two independently maintained standards. Is there any concrete concern on this front other than property access catchalls? Regards, Maciej
Re: [selectors-api] Scoped Selectors
John Resig wrote: 3. Obtain a collection of elements based on their relation to more than one specified reference elements. e.g. Query to the document to obtain elements matching :scope+span, where :scope is intended to match any of the elements in a specific collection. This would be simpler than iterating all of the nodes in the collection, running the query on each of them and then merging the results. I don't see the purpose of making a distinction between the root node used for the query and the node being used for the scope - they should be one and the same. // Doesn't make sense: document.querySelectorAll(div div, document.body) // Does make sense document.body.querySelectorAll(div div) It does make sense. It just means something slightly different from what you appear to be thinking. In the above, the document.body element wouldn't have any effect because it's not a scoped selector and there is no :scope pseudo-class used. Also, I don't think it's been made clear in the discussion thus far but while cases like handling div are nice - we're mostly concerned about cases like div div (that escape outside the original root of the query). The problems with handling div, +div and div div are exactly the same issue. The only difference is that the first 2 begin with a child combinator and sibling combinator, respectively, and the latter has an implied descendant combinator. They can all be addressed with the same solution. Given this DOM: body div id=one div id=two/div /div /body // All of these should return nothing document.getElementById(one).querySelelctor(div div) document.getElementById(one).querySelelctor(body div) document.getElementById(one).querySelelctor(div #two) The real benefit of the API as I first designed it, is that it elegantly provides ways to address nearly every use case raised and more, using the simple, yet extremely powerful concept of contextual reference elements, which is in fact not so different from the pattern used in JQuery: $(selector, context);. There doesn't need to be scoping for matchesSelector. matchesSelector implies that it it's starting from the specified node and doing a match. Additionally the use case of .matchesSelector( div) doesn't really exist. The use case doesn't really exist when the context node is considered to be the contextual reference element. But allowing reference nodes to be specified, it allows the query to check where it is in relation to another element. So, for example you could more easily check if the parent of element elm is one of the nodes in the collection elms. var elms = [div1, div2, div3]; e.g. elm.matchesSelector(:scope*, elms); Returns true if the elm.parent == div1, elm.parent == div2 or elm.parent == div3. With that in mind, option #3 looks the best to me. It's lame that the API will be longer but we'll be able to use basic object detection to see if it exists. Unfortunately the proper scoping wasn't done the first time the Selectors API was implemented so we kind of have to play the hand we've been dealt. Thus there would be two new methods: queryScopedSelectorAll queryScopedSelector I really didn't want to introduce new methods for this if it could be avoided. I realise one problem with the first draft of the API I posted yesterday was that is was too cumbersome for scripts to create and use scoped selectors, rather than normal selectors. That draft required scripts to do the following: var selector = document.createSelector(+p, true); document.querySelector(selector, elm); I have come up with a significantly simpler, alternative solution that not only abolishes the createSelector() method and the SelectorExpression interfaces, but also avoids introducing additional methods like queryScopedSelector(), or extra parameters. The draft now defines the concept of a *selector string* and a *scoped selector string*. The selector string is just an ordinary selector, as supported by current implementations. A scoped selector string is a string that begins with an exclamation point followed by a the remainder of the selector. The purpose of the exclamation point is to clearly identify the string as a scoped selector that requries an extra pre-processing step to turn it into a valid group of selectors. There are also slightly different requirements for the processing Element.querySelectorAll() when the selector argument is a scoped selector string. This allows for the sibling combinator cases to work. 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. This allows JS libraries to trivially prepend ! to the selector before passing it to the API, rather than requiring any complicated pre-processing. In current browser implementations, the
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sat, Sep 26, 2009 at 3:36 PM, Cameron McCormack c...@mcc.id.au 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? Since ES5 will be officially done well ahead of HTML5, I don't see why not. But I do not know what your Rec track constraints imply. -- Cheers, --MarkM
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sat, Sep 26, 2009 at 3:48 PM, Oliver Hunt oli...@apple.com wrote: I would avoid depending on ES5 until there are multiple realworld implementations at least, especially because the interaction between the es5 meta-object functionality and host objects is less than clear at present. Hi Oliver, it is precisely the need to clarify this interaction, as you pointed out in some of your previous posts to es-discuss, that got us to focus on the need for greater coordination at the last EcmaScript meeting. Since, as you say, this interaction is currently unclear, isn't this exactly the kind of problem our standards bodies should be trying to resolve? -- Cheers, --MarkM
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 3:13 PM, Allen Wirfs-Brock wrote: From: Maciej Stachowiak [mailto:m...@apple.com] On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote: ... Essentially, the semantics of browser ECMAScript has been arbitrarily split into two independently maintained standards. Is there any concrete concern on this front other than property access catchalls? Every place the WebIDL ECMAScript binding overrides an ECMAScript specification internal method is a concern as these are special case extensions to the ECMAScript semantics. As language designers we need to understand if these special cases are exemplars of general deficiencies in the language that should be addressed. We have definitely identified catchall property access as such an area. Are there in fact any others? It's a lot more interesting to look at specific examples than to expound on the general principles. See below where I did some study to find other missing capabilities. In particular now that ES5 is finished, WebIDL has a richer language to bind to then it had with ES3. We need a WebIDL binding that maximizes use of ES5 capabilities rather than inventing non-standard (from an ES perspective) language extensions. Updating WebIDL to use ES5 concepts would definitely be worthwhile. At the time Web IDL was started (early 2007 I think) this wasn't a practical option, but it is now. In particular, interfaces that don't have any unusual behavior could be defined as having getters and setters, and should not need to override internal properties at all. This would better highlight the capabilities that are needed to implement the Web platform, but which can't be expressed in the property descriptor formalism. I expect there are relatiively few such capabilities, and little interest in depending on new ones, and therefore we do not really have a general ongoing problem of language design. From a quick scan of WebIDL, I see the following: 1) Catchall getters, putters, deleters, definer. - Variants that can make the catchall check happen either before or after normal property lookup. - General string-based name access and index-only versions. - Note: I think catchall deleters are used only by Web Storage and not by other new or legacy interfaces. 2) Ability to support being called (via [[Call]]) without being a Function. 3) Ability to support being invoked a constructor (via [[Construct]]) without being a Function. 4) Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement works). 5) Ability to have [[Construct]] do something different than [[Call]] instead of treating it as a [[Call]] with a freshly allocated Object passed as this. Tentatively, I think all other semantics of Web IDL interfaces can be implemented in pure ES5. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 3:58 PM, Cameron McCormack wrote: 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 track? Mark S. Miller: Since ES5 will be officially done well ahead of HTML5, I don't see why not. But I do not know what your Rec track constraints imply. For example, Selectors API is at Last Call and will soon be in Candidate Recommendation. I don’t think it can progress further than that until its dependencies move forward. Selectors can't progress to PR/REC until Web IDL is in at least CR state (only one difference in maturity level is allowed for dependencies). I think Web IDL can enter CR with ES5 as is, but it will be considered final as soon as it is published, which is likely to be before Web IDL is ready for Last Call. ECMA process does not have any states between the equivalent of W3C Working Draft and W3C REC (as far as I know). So I don't think this would create any problems for Selectors advancing, other than the time to do the rewrite. On the substantive issue: I do think it would be good to convert Web IDL from ES3 formalisms to ES5 formalisms. While Oliver is right that ES5 has not yet been proven by interoperable implementations, and that some of its methods as defined have a hard time with host objects, I believe that the basic designs of ES5 property descriptors and ES5 getters/setters are sound. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 4:41 PM, Oliver Hunt wrote: The specific problem is that host objects cannot necessarily match the semantics of ES5, and for that reason the interaction of host objects with the ES5 semantics is unclear. I think mapping Web IDL behavior to ES5 property descriptors would help make this interaction more clear. There are additional concerns -- various es5 features expose the underlying implementation mechanisms of the binding -- for instance using get or set properties on a dom binding would require getOwnPropertyDescriptor to expose that implementation detail. getOwnPropertyDescriptor risks leaking implementation details (or at least implementation differences) in any case. The options for Web IDL are: 1) Leave the results of getOwnPropertyDescriptor completely implementation-defined, so different implementations may return different values. 2) Require getOwnPropertyDescriptor to return specific results that expose host object properties as something other than getters or setters. 3) Require getOwnPropertyDescriptor to return specific results that expose host object properties as getters/setters. I reluctantly conclude that #3 is best. #1 leaves behavior unspecified, this needlessly creates the potential for interop problems. #2 conflicts with the way some implementations implement their DOM bindings (e.g. Gecko), meaning extra work for them, and is outright unimplementable in pure ECMAScript. #3 conflicts with the way some implementations implement their DOM bindings (e.g. WebKit) and would mean extra work for them. #3 seems like it has the weakest disadvantages, even though it means extra work for us. However, if we want to allow implementation variance (i.e. policy #1), we could still use ES5 getters and setters as the formal model, but say that host objects implementations may override [[GetOwnProperty]] to give implementation-defined results for host attributes. This would change Web IDL from saying that host object implementations MUST override internal methods to saying they MAY. Regard, Maciej
Re: WebIDL
On Sep 26, 2009, at 3:30 PM, Cameron McCormack wrote: Yehuda Katz: Ha. Maybe it would be worth putting a note in HTML5. [Replaceable] is a quirk of history. Do not over-attend to it. Ian Hickson: If we start calling out all the quirks of history in HTML5, we'd probably end up doubling the size of the spec. OTOH calling out features in Web IDL that exist solely for quirky compatibility reasons, that would help to discourage their use in other specs. Calling these cases out in Web IDL (as opposed to HTML5) seems like a good idea. Regards, Maciej
RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
-Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] I expect there are relatiively few such capabilities, and little interest in depending on new ones, and therefore we do not really have a general ongoing problem of language design. We have an ongoing problem of language design in that all new language features must integrate with existing features. Combinatory feature interactions is one of the larger challenges of language design. From a quick scan of WebIDL, I see the following: 1) Catchall getters, putters, deleters, definer. - Variants that can make the catchall check happen either before or after normal property lookup. - General string-based name access and index-only versions. No comment, I need to come up to speed on the detailed semantic requirements - 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. 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]] 3) Ability to support being invoked a constructor (via [[Construct]]) without being a Function. Essentially same as 2 although the standard [[Construct]] requires a [[Call]] so this may need some more thought. 4) Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement works). Possibly the specification of the instanceof operator needs to be made extensible 5) Ability to have [[Construct]] do something different than [[Call]] instead of treating it as a [[Call]] with a freshly allocated Object passed as this. Similar to 4 regarding extensibility. At least one recent harmony strawman proposal is moving in a direction that may be relevent to 4 and 5. See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors Tentatively, I think all other semantics of Web IDL interfaces can be implemented in pure ES5. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote: -Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] I expect there are relatiively few such capabilities, and little interest in depending on new ones, and therefore we do not really have a general ongoing problem of language design. We have an ongoing problem of language design in that all new language features must integrate with existing features. Combinatory feature interactions is one of the larger challenges of language design. From a quick scan of WebIDL, I see the following: 1) Catchall getters, putters, deleters, definer. - Variants that can make the catchall check happen either before or after normal property lookup. - General string-based name access and index-only versions. No comment, I need to come up to speed on the detailed semantic requirements They are pretty similar to the way Array overrides [[DefineOwnProperty]] or the way String defines - 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, 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. 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. 3) Ability to support being invoked a constructor (via [[Construct]]) without being a Function. Essentially same as 2 although the standard [[Construct]] requires a [[Call]] so this may need some more thought. 4) Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement works). Possibly the specification of the instanceof operator needs to be made extensible 5) Ability to have [[Construct]] do something different than [[Call]] instead of treating it as a [[Call]] with a freshly allocated Object passed as this. Similar to 4 regarding extensibility. At least one recent harmony strawman proposal is moving in a direction that may be relevent to 4 and 5. See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors Interesting. 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. Regards, Maciej
Re: [selectors-api] Scoped Selectors
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? Have you run this by the CSS working group? 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? -Boris
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
Maciej Stachowiak: - Note: I think catchall deleters are used only by Web Storage and not by other new or legacy interfaces. Allen Wirfs-Brock: Seems like a strong reason to change to the proposed API to eliminate the need for a new ES language extension. When writing Web IDL originally, it didn’t seem at all to me that host objects were a disapproved of mechanism to get functionality that can’t be implemented with native objects. So having a [[Delete]] on a host object be different from the Object [[Delete]] or the Array one seemed fine to me. -- Cameron McCormack ≝ http://mcc.id.au/
