Re: Web IDL syntax
On Fri, 19 Jun 2009, Cameron McCormack wrote:
An alternative would be to reverse the omission of methods, so that
“getter” on an operation would always have both the getter. Then if
you wanted to omit the method if getters are supported you could do
something like:
interface DOMStringMap {
omittable getter DOMString get(in DOMString name);
omittable setter void set(in DOMString name, in DOMString value);
…
};
and getters/setters defined with no operation name would be implicitly
omittable.
I prefer omittable because it would mean I wouldn't have to say and the
setter works like this other method in prose all the time.
If we are breaking syntax, then it seems more compelling to make
“DOMString” be “string”.
Maybe we could drop the “in” keyword. Seems better to stick with
plain “in” arguments, for compatibility across language bindings,
than to also allow “out” and “inout” ones.
I'd vote for not changing these, because we already have a lot of IDL out
there and it would be a pain to fix it all.
Regarding 'implements' (heycam and I talked about this on IRC recently;
I just wanted to get some notes down on the record):
There are three use cases that need covering:
- inheritance (e.g. Node - Element - HTMLElement - HTMLAnchorElement)
- interfaces that are to be implemented by many other objects (e.g.
EventTarget)
- interfaces that are defined across multiple specs (e.g. Window,
WorkerUtils, HTMLBodyElement's attributes and methods being separated
from its deprecated attributes and methods)
The first is handled by ':', the second is handled by 'implements'. I
think we need the third also.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bindings] [[Delete]], hidden operations, missing arguments
This mail slipped my attention. Probably you know that these features were added, but for completeness: Ian Hickson: It would be useful to be able to specify a method to implement [[Delete]] on an interface. You have [NameDeleter] and [IndexDeleter]. It would be useful to be able to define a method that isn't visible to JS, in particular for implementing [NameGetter], [Delete], etc.. Those extended attributes can be placed on the interface. It would be nice for the spec to explicitly say how to handle argument calls that have not enough arguments, both for normal methods and for overloaded methods. (The right answer probably being whatever IE does.) Currently it’s defined to throw a TypeError. I have a feeling something else is required, but it’s been a while since I’ve tested it. I’ll add a note to check this. And finally, please rename the spec Web IDL. :-) That was done a while ago. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [bindings] Regarding the algorithm of 4.2.2. Interface prototype object
Hi David. David Andersson: I think this algorithm as written is severely broken. The reason is that [[HasProperty]] will travel the entire chain for each of the interfaces in order. … I propose a change to instead use the C3 algorithm as used in Dylan, Python 2.3, Perl 6: A while ago I changed the spec to flatten the multple inheritance into a single inheritance prototype chain, so I guess that invalidates your comment. I’d appreciate review of what’s currently specified, though. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: Request for Comments: FPWD of Widgets 1.0: URI Scheme spec
Dear, Very interesting part of the whole Widget Sorcery Here are few comments 1) In the same spirit as WARP, it would be interesting to make HTML5 reference, an informative one 2) Probably the link between authority and opaque-autorithy should be clearer 3) Update reference to Working Draft 28 May 2009 for Widgets-PC 4) s/RFC5234/RFC 5234/ I'm not sure to fully understand this requirement [[ Must be independent of any file system Addressing based on this scheme must only map onto Zip relative paths and remain independent of any file system on which the widget may be stored. ]] Does it mean that, it is case insensitive for example ? Xmlizer On Thu, Jun 18, 2009 at 4:19 PM, Arthur Barstowart.bars...@nokia.com wrote: To: public-webapps@w3.org BCC: www-...@w3.org, public-pkg-uri-sch...@w3.org Reply-to: public-webapps@w3.org On June 18, the Web Applications WG published a First Public Working Draft of the Widgets 1.0: URI Scheme spec: [[ http://www.w3.org/TR/2009/WD-widgets-uri-20090618/ Abstract Many specifications in the Web stack depend on a context being defined that includes a current URI. This is easily provided for documents retrieved over HTTP, or from the local file system, but is currently undefined for documents extracted from within a widget package. Such a limitation has a number of implications which this document intends to address. Introduction This specification defines the widget URI scheme for use inside widgets or other such applications of web technology that do not run on the web. ]] If you have any comments, please send them to public-weba...@w3.org. -Regards, Art Barstow P.S. BCC was used for TAG and PKG-URI mail lists to reduce cross-posting
Re: File API Feedback
On Fri, 19 Jun 2009 01:01:41 +0200, Arun Ranganathan a...@mozilla.com wrote: Ian Hickson wrote: I spoke with the developers of one of these Well-Known Web Applications, and they didn't even _mention_ the styling difficulties of input type=file as one of the reasons for using Flash here. This feedback is extremely useful. I, too, would like the chance to speak with the developers of (that particular application) as well as with other developers. Maciej said that the MobileMe developers gave pretty much the same feedback: http://krijnhoetmer.nl/irc-logs/whatwg/20090619#l-90 Is it really that bad to wait with evaluating this feature until v1 is more widely deployed? -- Anne van Kesteren http://annevankesteren.nl/
Re: Web IDL syntax
On Fri, 19 Jun 2009 06:54:45 +0200, Cameron McCormack c...@mcc.id.au wrote: So if we are happy to extend the IDL syntax, I think any extended attribute that is intended to have some effect across all language bindings should be moved to the syntax proper. Following are my half baked proposals. I haven’t them through much; comments very much welcome. In general this seems fine to me. As long as you help reviewing specifications that use Web IDL :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: File API Feedback
For what concerns the file as URI feature: What about reusing the cid scheme? - It would avoid collisions, as anything can be used as Content-ID, including a progressive number or the name of the input element - It would not be problematic to implement, as cid URIs are already supported by browsers - It would respect theoretical purity, as the identifier actually represents the Content-ID of the file subpart in the multipart/form-data submission - It would bind to the input type=file: changing the file selected automatically changes the reflected content, and the application cannot send or read files the user had selected and then changed (not through this API, at least) For what concerns the file dialog feature: input type=file (or xf:upload) cannot completely replace the FileDialog interface because they cannot: - open FileDialog without user intervention. This can be annoying, but can also be useful, if the FileDialog is the result of a remote server response - do something in between user interaction and opening of the file dialog box (for example checking a database or asking more data from the user with a prompt() dialog) Lastly: a new approach to the file dialog feature is about:fileselection, ie an URI that represents the file dialog box. The difference between this and FileDialog is that it can be used from an iframe, to avoid proliferation of modal dialog boxes. Also, the settings for showModalDialog() would apply to automatic opened file dialogs, without requiring new code and new heuristics to block them. Giovanni
Re: [selectors-api] Transitioning to CR
Hi Lachlan, On Jun 17, 2009, at 14:15 , Lachlan Hunt wrote: *CR Exit Criteria* I propose the following as the CR exit criteria: At least two interoperable implementations of each feature, dependent upon the following conditions: * Each individual test in the test suite must pass in at least two of the reviewed implementations. * Test failures in a given implementation caused by the lack of support for a particular feature of an independent specification are not counted. This does not apply to failures caused by an incorrect implementation of such features. (e.g. IE lacks support for many of the CSS3 selectors tested in the test suite, but to be fair, these failure should be ignored.) * Each implementation reviewed must have at least a 95% pass rate, not counting ignored tests. Out of curiosity, why not make it two interoperable implementations of *all* the tests, except those stemming from a lack of support for CSS? -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
RE: Web IDL syntax
Hi Cameron, I will review your proposal in detail soon. In general this seems fine to me. As long as you help reviewing specifications that use Web IDL :-) +1 Please bear in mind that there are specs that rely on Web IDL. E.g. BONDI (http://bondi.omtp.org/1.0/) defines in Web IDL: 178 methods, 82 constants and 116 attributes over 68 interfaces as summarized here: http://bondi01.obe.access-company.com/1_0_3309_41/stats.html so stability of the Web IDL spec MAY be important. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Anne van Kesteren Sent: Friday, June 19, 2009 10:51 AM To: Cameron McCormack; public-webapps@w3.org Subject: Re: Web IDL syntax On Fri, 19 Jun 2009 06:54:45 +0200, Cameron McCormack c...@mcc.id.au wrote: So if we are happy to extend the IDL syntax, I think any extended attribute that is intended to have some effect across all language bindings should be moved to the syntax proper. Following are my half baked proposals. I haven’t them through much; comments very much welcome. In general this seems fine to me. As long as you help reviewing specifications that use Web IDL :-) -- Anne van Kesteren http://annevankesteren.nl/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: File API, Editor's Draft II
Arun, On Jun 18, 2009, at 23:02 , Arun Ranganathan wrote: - For FileListDataCallback what happens if the user cancels? Do I get an error? A defined but empty FileList? I have a slight preference for the latter, but either way the author should be notified. I should make this clearer, but currently if the user cancels, the FileErrorCallback will be called with FileError (with errorCode SECURITY_ERR). Subsequent suggestions from Anne to NOT match what DOMException does might mean cleaning up my error codes and adding some new ones. That way works, but indeed having a code other than SECURITY_ERR might be more meaningful to the developer. - General note on asynchronous calls: instead of void, should they return an opaque token which can be used to cancel the request (or provide one way or another of doing that, possibly just having cancel() on the object)? That's available on setTimeout/ setInterval, and on XHR — it's generally useful. Having cancel() on *what objects* exactly? Also, WindowTimer may not be the best example. Indeed, WindowTimer might not be emulated. Where cancel() goes depends on the request. In this case, I am guessing it would go on the object that made the request. So for FileDialog, on FileDialog (this is assuming that one would only ever have a single active dialog — this should be defined, along with whatever happens if I call open() several times in a row). For getAs* on File it's somewhat more annoying. Given a slow network mount, you could easily call getAs* several times before anything happened. Would it be expected to return data several times? If the callbacks are different objects it could make sense, but if they're the same possibly not. - How do you propose to handle encoding errors? Say a file is UTF8 and I request it as ASCII? Drop what can't be converted? Use a replacement character? Throw an error? In my opinion, charset conversion shouldn't throw any errors, but should try to honor the call as best as possible. I'll make this clearer. I am fine with that so long as you specify what the algorithm is to handle malformed encodings. Cheers! -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: File API Feedback
On Jun 19, 2009, at 05:30 , Ian Hickson wrote: On Fri, 19 Jun 2009, timeless wrote: On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? so. I have folders with 100-1000mb of pictures in them. If I decide that I want to upload them all (Picasa style), i'd expect it would take a very long time to convert each file name into a base64 url. This is exactly the use case I had in mind, yes. data: URLs are fine for testing and prototyping, but as a practical matter, they don't really scale to real-world needs. For example, imagine a user uploading a local video (~1GB) to YouTube, where the page wants to show the video in a video element as (or immediately before) the user is uploading it (e.g. so the user can set the times where ads should show). A data: URL is clearly not an option here, I think. It also doesn't scale to the (as yet hypothetical, but suggested multiple times) case in which the file input is used to point to a capturing device (e.g. a webcam). You do want to be able to point video at the stream, but I have reservations about a magical Base64 string that would just keep growing :) At the risk of opening one big bad can of worms, the use case for such a synthetic URI scheme seems reasonably close to that for widget URIs (we might have to wiggle around context-dependent semantics, which could get ugly). Perhaps we should mint a single scheme that would cover all runtime operational needs to synthesise a URI and use it across the board. After all, it's about being to reference something without using file:. This of course can get interesting. We've looked at getting such a URI from image and video files and having img and video point to them, and there's no question it'd work fine for audio. I'd expect it to work with HTML files and iframe. What about getting said URI and linking to it with a? -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Web IDL syntax
Hi Cameron, On Jun 19, 2009, at 06:54 , Cameron McCormack wrote: I’m thinking about removing some of the extended attributes in Web IDL and replacing them with non-extension syntax in the language. Originally, I had a goal of keeping compatibility with OMG IDL, which is why many features currently require extended attributes. Not only do I think that compatibility with OMG IDL isn't useful, I also don't think that WebIDL is currently compatible — or at the very that as written it enforces the creation WebIDL documents that are also well-formed OMG IDLs. One example is case-sensitivity: OMG IDL is case-preserving but compares identifiers in a case-insensitive manner (and I forget the scope of the comparison, but I think it's per *module*); that's one of the reasons why some of the SVG IDLs originally claimed conformance to nothing. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [selectors-api] Transitioning to CR
On Jun 19, 2009, at 16:57 , Boris Zbarsky wrote: Robin Berjon wrote: * Test failures in a given implementation caused by the lack of support for a particular feature of an independent specification are not counted. I should note that if we consider WebIDL an independent specification then we're already there. Yeah, I have this Ecmascript implementation that only supports variable declarations (with a few bugs). But I swear it supports the Selectors API! Seriously though, as I explained during the last meeting it's up to the WG to reach consensus on the exit criteria, and then up to the WG to reach consensus on whether they've been reached or not. The point of specifying them in advance is that it informs the community at large about our intentions in terms of how strict we plan to be. Which is to say: it's not a conformance clause. We don't need to be anal about how it is formulated because we won't be writing tests in the future to see if the WG conforms to itself. It's important to say that we're testing the API and not actual CSS support, but we needn't go overboard in delimiting the criteria. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [selectors-api] Transitioning to CR
On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote: Robin Berjon wrote: Out of curiosity, why not make it two interoperable implementations of *all* the tests, except those stemming from a lack of support for CSS? I was advised to set the requirements low so that it would be easier to proceed past CR. With these requirements, we can get past CR relatively quickly. If we need to wait for at least 2 implementations that both get 100%, that will just delay the spec by 6 to 12 months awaiting the browser vendors' next release cycle. I don't have a strong opinion either way, but I am unaware of any external time pressure on this specification. If there aren't any, why not delay it so we can do the hard (and right) thing of only shipping when we have fully demonstrated interoperability? -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [selectors-api] Transitioning to CR
Robin Berjon wrote: Out of curiosity, why not make it two interoperable implementations of *all* the tests, except those stemming from a lack of support for CSS? I was advised to set the requirements low so that it would be easier to proceed past CR. With these requirements, we can get past CR relatively quickly. If we need to wait for at least 2 implementations that both get 100%, that will just delay the spec by 6 to 12 months awaiting the browser vendors' next release cycle. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Transitioning to CR
On Fri, 19 Jun 2009, Robin Berjon wrote: On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote: Robin Berjon wrote: Out of curiosity, why not make it two interoperable implementations of *all* the tests, except those stemming from a lack of support for CSS? I was advised to set the requirements low so that it would be easier to proceed past CR. With these requirements, we can get past CR relatively quickly. If we need to wait for at least 2 implementations that both get 100%, that will just delay the spec by 6 to 12 months awaiting the browser vendors' next release cycle. I don't have a strong opinion either way, but I am unaware of any external time pressure on this specification. If there aren't any, why not delay it so we can do the hard (and right) thing of only shipping when we have fully demonstrated interoperability? That seems wiser to me too. The rush is to get interoperable implementations, not to get RECs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Reminder: Public call for prior art on Widget updates
Reminder: the W3C is seeking input on prior art on Apple's 5,764,992 patent. Details below. -Regards, Art Barstow Begin forwarded message: From: ext Rigo Wenning r...@w3.org Date: June 12, 2009 2:23:08 PM EDT To: public-webapps@w3.org public-webapps@w3.org Cc: widget-pag member-widgets-...@w3.org, public-widgets- p...@w3.org public-widgets-...@w3.org Subject: Public call for prior art on Widget updates Archived-At: http://www.w3.org/mid/200906122023.08963.r...@w3.org http://www.w3.org/2009/03/widgets-pag/cfpa The W3C hereby issues a call for prior art on US patent 5,764,992 [1] that may apply to the Widgets updates specification[2]. Pursuant to its rights under W3C's Patent Policy, Apple Inc. has excluded all claims of the aforementioned patent from the W3C Royalty-Free License commitment. The PAG seeks information about software update systems available before June 1995 that offer a viable solution that may apply to the use of updates in Widgets. People who wish to provide feedback should refer to the call[3] for more information or write back to public-widgets-...@w3.org Please distribute this call for prior art as widely as possible. 1.http://is.gd/101wZ 2.http://www.w3.org/TR/2008/WD-widgets-updates-20081007/ 3.http://www.w3.org/2009/03/widgets-pag/cfpa.html Rigo Wenning Widgets update PAG chair W3C Legal counsel
Input events, checkboxes and radio buttons
The HTML5 spec says to fire the input event when the user changes a radio button or a checkbox. However, the spec says When the input event applies, any time the user causes the element's *value* to change. For input[type=radio] and input[type=checkbox] the input event should be fired any time the user causes the element's *checked* property to change. -- erik
Re: File API Feedback
Robin Berjon wrote: On Jun 19, 2009, at 10:16 , Anne van Kesteren wrote: On Fri, 19 Jun 2009 01:01:41 +0200, Arun Ranganathan a...@mozilla.com wrote: Ian Hickson wrote: I spoke with the developers of one of these Well-Known Web Applications, and they didn't even _mention_ the styling difficulties of input type=file as one of the reasons for using Flash here. This feedback is extremely useful. I, too, would like the chance to speak with the developers of (that particular application) as well as with other developers. Maciej said that the MobileMe developers gave pretty much the same feedback: http://krijnhoetmer.nl/irc-logs/whatwg/20090619#l-90 Is it really that bad to wait with evaluating this feature until v1 is more widely deployed? Given that we're still in WD, how about simply adding a note indicating that this feature is under scrutiny (with pointers to this discussion)? If it is still under scrutiny when we move to LC we can make a call to keep it alive, and if it makes it through LC we can still mark it as at risk That seems sensible. Also, FWIW, in email exchanged on this listserv, Hixie and I refer to ... well known web apps... which seems at best overly cautious. It might be well worth enumerating the *actual web apps* that we are using for some due diligence and use case structuring. To date, we have heard from GMail, MobileMe, and WordPress (via the Mozilla 2009 All Hands). I'd like to follow up a bit more with applications like Flickr, follow-up some discussions with WordPress, etc. Of course, it isn't possible to exhaustively talk to ALL web app developers, but it seems good to have some discussion on this subject. I'd encourage those who are able to post feedback *as developers of such applications* to do so as well. I'm not trying to be difficult; the objections to FileDialog have been really useful. It's good to be thorough :-) -- A*
Re: File API Feedback
On Thu, Jun 18, 2009 at 8:30 PM, Ian Hicksoni...@hixie.ch wrote: On Fri, 19 Jun 2009, timeless wrote: On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? so. I have folders with 100-1000mb of pictures in them. If I decide that I want to upload them all (Picasa style), i'd expect it would take a very long time to convert each file name into a base64 url. This is exactly the use case I had in mind, yes. data: URLs are fine for testing and prototyping, but as a practical matter, they don't really scale to real-world needs. For example, imagine a user uploading a local video (~1GB) to YouTube, where the page wants to show the video in a video element as (or immediately before) the user is uploading it (e.g. so the user can set the times where ads should show). A data: URL is clearly not an option here, I think. As many others have pointed out, I think the data:-url solution only scales so far. Once we start getting into video as well as very high-quality images, we need a better solution. However I'm not convinced that this solution needs to go into this spec, or needs to go into version 1 of this spec. It seems to me that for the case when you have a 1Gb video that is being uploaded to flickr, or 100-1000mb of pictures being uploaded to Picasa, do you really need to get any type of url to it? Sending the file using XMLHttpRequest to the server should simply be a matter of passing the File object to XMLHttpRequest.send. Yes, it would definitely be nice if you could display a preview of the file no matter how big the file was, but it seems like we can get very far without it. That said. If anyone comes up with a suggested draft for scheme:uuid, (including if Arun does so), I'd be all for putting it in the spec. The problems that seems like they need to be solved are security (are these URIs accessible by any domain), and lifetime (how long does the URI work). / Jonas
Re: File API Feedback
On Fri, Jun 19, 2009 at 2:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jun 18, 2009 at 8:30 PM, Ian Hicksoni...@hixie.ch wrote: On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? snip.../snip it would definitely be nice if you could display a preview of the file no matter how big the file was, but it seems like we can get very far without it. What are the URL length limitations imposed by user agents? A quick search does not show any hard limits outside of IE's ~2k limit. Presumably IE could be convinced to increase that for data URLs. If the answer is 2k, then toDataURI is useless in practice and should be dropped from the spec, even if we don't replace it with something else. If the answer is 1GB, then at least it will be useful for the vast majority of use cases (i.e. pictures, youtube-sized videos, etc). Do we have any of this data for Gecko, Opera, WebKit? Ojan
Re: File API Feedback
On Fri, 19 Jun 2009, Jonas Sicking wrote: The problems that seems like they need to be solved are security (are these URIs accessible by any domain), and lifetime (how long does the URI work). The security would be that the origin of these URLs is fixed to be the origin of the script context (the first script in HTML5 terms) that invoked the method that minted the URL. The lifetime... the easiest lifetime is the same lifetime as the Document of the script that was used to get the origin. This can lead to these URLs floating around after they have died, though; e.g. you could take an img, pass it to a script in another doc, and have the Document totally be GC'ed while the other img element still exists, and then the URL suddenly fails if it is used in another img. The most conservative lifetime would be the lifetime of the browser, but that may be overly long. Maybe we should have an API that, given one of these URLs, can return a File object (e.g. maybe the File object has a constructor that takes a URL and then that File can be used to refer to that URL, which might actually be useful in general); if we have that, then anyone who wants the URL to be usable beyond the original lifetime of the Document but that doesn't have access to the original File can just spawn a new one. So my proposal would be to make the lifetime that of the creating script's Document. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webidl] DOMString
Hi Oliver. Oliver Hunt: Conceivably the language could be a relatively simple and broad statement along the lines of: Any type conversions needed for a language binding should occur before an API function is called, if a type conversion fails for any reason the call should be aborted However this doesn't address the issue of callbacks that throw exceptions, or returns incorrect types leading to an exception on type conversion, etc, etc I’ve added wording to cover this, but without using RFC 2119 language; the spec doesn’t define a conformance class for language bindings. http://dev.w3.org/2006/webapi/WebIDL/#callback-attribute-exceptions http://dev.w3.org/2006/webapi/WebIDL/#callback-operation-exceptions http://dev.w3.org/2006/webapi/WebIDL/#type-conversion-exceptions The ECMAScript binding as currently written should follow these guidelines already. I’ve yet to add a section in the Java binding on how “host objects” should deal with “user implemented objects”. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [PrototypeRoot]
Cameron McCormack: Done: The value of the internal [[Class]] property of a host object is determined as follows: * If the host object implements a single interface, then the value of the internal [[Class]] property MUST be the identifier of that interface. Ian Hickson: I think it would make sense to exclude [NoPrototypeObject] interfaces from consideration here. I assume you mean [NoInterfaceObject]? Is the reasoning for this that [NoInterfaceObject] inerfaces are nearly always “mixins”, and so shouldn’t affect the [[Class]]? Cameron McCormack: Note that this still technically does not mean you can guarantee that the NodeList returned by querySelectorAll() has [[Class]] == NodeList, since it could be that that host object implements another interface, which might be required by another spec, or perhaps just because the implementation wants to. Ian Hickson: IMHO this is a problem. I don't think that UA extensions should affect the [[Class]], and I think that other specs should have a way (e.g. [NoPrototypeObject]) of always making sure they don't affect the [[Class]] of existing stuff. Do you still think it would be bad to use [ProtoypeRoot] on interfaces like NodeList, to indicate that it is the “main” interface? That would be the way, currently, to require a particular [[Class]] that could not be overridden by having a second interface be implemented. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
