Re: WebIDL
Thanks for your responses. They are very useful. First of all, the length of this response (and the explanations themselves) speak to the difficulty casual spec readers have in understanding this syntax. More specific responses inline. On Fri, Sep 25, 2009 at 10:29 PM, Cameron McCormack c...@mcc.id.au wrote: Hi Yehuda. Yehuda Katz: 1. There are a number of ECMAScript-specific extensions here that have obscure names and non-obvious behavior. For instance, understanding [Replaceable] readonly is non-trivial. In fact, [Replaceable] readonly has somewhat confusing semantics, in that the attribute is not really readonly at all. The readonly definition is An object that implements the interface on which a read only attribute is defined will not allow assignment to that attribute, while [Replaceable] means If the [Replaceable] extended attribute appears on a read only attribute, it indicates that setting the corresponding property on the host object will result in that property being removed and a new one created that is unrelated to the attribute, and which has the value being assigned. In fact, aren't these properties not readonly at all. Instead, doesn't this idiom mean that the property is linked to some invisible attribute that is also used by other methods? Isn't that a more useful thing to express? In the ES binding, the properties for these [Replaceable] attributes are effectively writable, but assigning to them breaks their link to the original attribute. The assignment doesn’t perform any conversion from the ES value to the IDL type, either. In other language bindings you would want these properties to behave like normal readonly attributes, e.g. in Java by having only a setter method. So this extension effectively converts a readonly attribute to a writable one? Talk about confusing. And this isn't true about the same attribute in non-ES contexts?! Note that, while it may not be clear from the text, section 3 of Web IDL only makes requirements of IDL fragments, not on language bindings for any interfaces. The talk about not allowing assignment to the attribute is a true description of both the ES and the Java bindings: the IDL attribute itself isn’t writable, but [Replaceable] indicates that the ES property that reflects that attribute is writable (and does something non-obvious). It wasn't clear from the text, but now that I understand it, it doesn't help much. An object that implements the interface on which a read only attribute is defined will not allow assignment to that attribute. It is language binding specific whether assignment is simply disallowed by the language, ignored or an exception is thrown. It's unclear to me how this is not specifying a requirement on the language binding. This whole thing is extremely confusing. I wonder if for [Replaceable] and other similar hacks for legacy DOM behaviour we should state that they SHOULD NOT be used. If something is in WebIDL purely as a description for known legacy behavior, it would be helpful if the case(s) in question were called out in the spec, and use of the syntax was disallowed for other cases. 2. Can't we have more useful defaults here? For instance, why can't readonly attribute WindowProxy parent; readonly attribute Element frameElement; WindowProxy open(in optional DOMString url, in optional DOMString target, in optional DOMString features, in optional DOMString replace); be identical to readonly WindowProxy parent; readonly Element frameElement; WindowProxy open(optional DOMString url, optional DOMString target, optional DOMString features, optional DOMString replace); We could make the syntax for attributes less similar to OMG IDL’s by dropping the “attribute” keyword, but given that people are familiar with this syntax (pre-Web IDL) and that implementations use IDL files with this syntax as part of their builds, I’m not sure it’s worth it. I'll put it another way: what's the utility of this additional word. In my opinion, if a word appears in the HTML5 specification, it should be there for a reason. If it is not, it just adds additional confusion for readers of the spec. Although, we did drop the requirement for the “in” keyword: The in keyword used in the declaration of each argument is optional. No other types of arguments (such as out or in-out arguments) can be specified with Web IDL. — http://dev.w3.org/2006/webapi/WebIDL/#idl-operations So there's precedent then! Additionally, isn't this stream of characters somewhat confusing? What about: readonly parent: returns WindowProxy; readonly frameElement: returns Element; open(optional DOMString url, optional DOMString target, optional DOMString features, optional DOMString replace): returns WindowProxy; Similarly, I don’t think moving the return type to the end buys us anything. I think it buys clarity, but I'm not too concerned about it. The specifics here aren't
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
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. 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. This is a problem to fix. No one is arguing that it's not a problem. What's the real topic? 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. The ES spec allows extensions, but it cannot require them without the extensions being no longer extensions in any sense, rather as specified parts of the normative core language. Again I don't know what your point here is. Is this a requirement ECMA is comfortable with? What requirement? Your scenario? I have no idea where it came from, but it doesn't follow from anything you cited (cited again below). If you mean we need to specify multiple globals, split windows, execution model, etc. -- that's what I've been saying on the main thread since the first message, and what Sam's transcription of a private message from me tried to say. Still not sure what your point is, /be -- Yehuda On Thu, Sep 24, 2009 at 3:19 PM, Brendan Eich bren...@mozilla.com wrote: On Sep 24, 2009, at 2:43 PM, Doug Schepers wrote: [much appreciated information snipped -- thanks!] I really don't see how the review process and accountability could be much more open for the development of Web IDL elsewhere, nor is the burden on reviewers that large... it would simply be one more low-traffic mailing list. Are there other barriers you see? I alluded to employers who are not currently paying W3C members not wanting their employees participating, even individually. I'll let one notable example that I know of speak for himself. The mailing list as firehose problem can be solved with enough work, but with two standards groups there is always greater risk of conflict, and just competition for attention. Two lists is simply one more list than one list to keep up with. This is a price of collaboration at wider scale, so don't let me stand in the way, since I've been explicit about being in favor of collaboration. W3C and Ecma both have transparency issues, but I don't expect those to be fixed easily. I mentioned them (People in dark-glass houses ... [should not throw stones]) in reply to Maciej asserting greater openness on one side. Again this is not a barrier I'm trying to take down right now. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
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? [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. 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? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL
On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich bren...@mozilla.com wrote: On Sep 25, 2009, at 11:05 PM, Yehuda Katz wrote: In the ES binding, the properties for these [Replaceable] attributes are effectively writable, but assigning to them breaks their link to the original attribute. The assignment doesn’t perform any conversion from the ES value to the IDL type, either. In other language bindings you would want these properties to behave like normal readonly attributes, e.g. in Java by having only a setter method. So this extension effectively converts a readonly attribute to a writable one? Talk about confusing. And this isn't true about the same attribute in non-ES contexts?! Please hold your fire. [Replaceable] was added in the 90s when Netscape 4 and IE4 tried to evolve the DOM by adding properties to the global (window) object, and found the common names intended were already in use. It's a mistake to try to add common names, but try we did (both Netscape and Microsoft), with the hack of allowing the name to be preempted by content. Only if not replaced would the Netscape code actually reify the new property on demand. I'm not sure how IE did it. Understood. I don't have the benefit of the history here (unfortunately), just the specs as they stand today. This is an ongoing issue. Adding JSON (from json2.js) to ES5 involved some pain, due to other implementations of a JSON codec using the same name but different method names in the top-level JSON object. But it didn't require anything like [Replaceable] to sort out. We're stuck with [Replaceable], although like any sunk cost it is not cost-free and we could reengineer it. But what's the gain? Pointing out the silly way it makes readonly properties low-integrity is not helpful. Yes, you can replace (or preempt, I prefer) such properties with your own vars or functions in content. That was the way it worked in the 4th generation browsers. Why reengineer this minor piece of WebIDL now? 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. I did not single out Replaceable in my efforts to understand. /be -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL
I did not single out Replaceable in my efforts to understand. Sure, but it is certainly odd and I wanted to recount some of the history, just so you'd know not to over-attend to it. ;-) WebIDL comes from OMG IDL, much of the precedent is documented in various online sites, CORBA books, etc. It's not all that strange or bad, just a bit '90s big OOP system in flavor. To understand it all takes a while, and Maciej allowed as how some of it could be cut without harm. Maybe we should start there. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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. - 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. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL
On Fri, Sep 25, 2009 at 11:38 PM, Brendan Eich bren...@mozilla.com wrote: I did not single out Replaceable in my efforts to understand. Sure, but it is certainly odd and I wanted to recount some of the history, just so you'd know not to over-attend to it. ;-) Ha. Maybe it would be worth putting a note in HTML5. [Replaceable] is a quirk of history. Do not over-attend to it. WebIDL comes from OMG IDL, much of the precedent is documented in various online sites, CORBA books, etc. It's not all that strange or bad, just a bit '90s big OOP system in flavor. To understand it all takes a while, and Maciej allowed as how some of it could be cut without harm. Maybe we should start there. 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 with less historical and conceptual baggage be used inline? Or is that too much work? /be -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
On 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: 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL
On Fri, 25 Sep 2009, Yehuda Katz wrote: At the urging of some folks, I've poked around WebIDL and have a few observations. I'll use the Window object from HTML as a prop here (it is reproduced, in full, below) If there are issues you would like fixed in HTML5 (as opposed to WebIDL), please file them as bugs. The easiest way to do that is to use the little text box at the bottom of the browser window when looking at: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL
On Fri, 25 Sep 2009, Yehuda Katz wrote: On Fri, Sep 25, 2009 at 11:38 PM, Brendan Eich bren...@mozilla.com wrote: I did not single out Replaceable in my efforts to understand. Sure, but it is certainly odd and I wanted to recount some of the history, just so you'd know not to over-attend to it. ;-) Ha. Maybe it would be worth putting a note in HTML5. [Replaceable] is a quirk of history. Do not over-attend to it. If we start calling out all the quirks of history in HTML5, we'd probably end up doubling the size of the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
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. 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. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: WebIDL
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. -- Cameron McCormack ≝ http://mcc.id.au/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
Allen Wirfs-Brock: 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. 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. 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? -- Cameron McCormack ≝ http://mcc.id.au/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 3:36 PM, Cameron McCormack wrote: Allen Wirfs-Brock: 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. 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. 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 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. --Oliver -- Cameron McCormack ≝ http://mcc.id.au/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
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. -- Cameron McCormack ≝ http://mcc.id.au/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
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. 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. 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? 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 seems winning since developers want not only sane typeof, but .apply/call/bind. 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 bug on file to fix our built-in functions (Date methods, etc.) to lose [[Construct]] and .prototype. I'm not sure of v8's plans. First-class syntax for defining such non-constructor functions is elusive. ;-) 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. Is there anything specified via WebIDL that must be a constructor but not a callable? 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). 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 Definitely. 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. As an aside, the strawman for 'constructor' makes at least Mark Miller and me want to unify 'class' and 'constructor' -- we don't want both, and Harmony needs something already called class for several reasons, one of them to model built-ins in ES1-5. 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. /be
RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
-Original Message- From: Cameron McCormack [mailto:c...@mcc.id.au] ... 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. 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). 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. 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? 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). Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
