Re: [WebIDL] mixins and [[Prototype]]s (and objects)
Cameron McCormack wrote: * modifying the interface prototype objects for the mixins does not change the mixin prototype object (e.g. if you added a new property it would not be visible); True. (We could make the prototype objects for the mixing interfaces special, such that e.g. doing ‘EventTarget.prototype.a = 1’ would cause a property ‘a’ to be created on the relevant mixin prototype objects.) OK, but this could potentially change the (unspecified) resolution order if it isn't implemented carefully. What happens if we [[Delete]] a member on the mixin prototype object? (That might be a somewhat academic question as you should not be able to access it, but Gecko based browsers give you a __proto__ property.) … * if you could access the mixin prototype object, and it was shared between two interfaces, modifying it would change both interfaces Right. But that’s the same as if you modify Node.prototype, then you are changing Elements, Texts, Comments, etc. OK, but it is awkward to implement. Is it not possible to simply change how [[Get]] (and friends) works on the interface prototype object so it attempts to look up properties on all of the relevant interface prototype objects? This could be specified in a recursive manner to produce a depth first search of the interface hierarchy, or it could be written using a more complex approach such as C3 ordering which seems to have become fashionable recently. Something similar to this, but without the C3 ordering (which David Andersson suggested at one point), was in an earlier draft: http://www.w3.org/TR/2008/WD-WebIDL-20080829/#interface-prototype-object IIRC there were concerns raised about breaking the explicit prototype chain and it being more of a burden to walk this inheritance tree for property lookups. I had seen the email that is linked to by that edition of the spec, and agree that without a sensible MRO it was broken. I don't see that breaking the explicit prototype chain is more of a problem than making [[Put]] cause the property to be created on more than one object though. Were there any mailing list threads that I could look at so I could understand why this was a problem? I've implemented the scheme I proposed since writing my last mail, and I haven't found any significant problems (currently testing), but I guess how easy this is to do depends on how inheritance is currently implemented. … It also makes it much simpler to deal with object elements - if we load an nsplugin (we may change which nsplugin is used of the lifetime of the object) we can just add the object created by the npruntime API as another parent of the HTMLObjectElement host object. How would you implement sensible behavior using the method described in the WebIDL specification? I haven’t been taking the use case of allowing the set of interfaces an object implements to change into account. Is treating the JS interface that NS plugins expose as an IDL interface that the HTMLObjectElement must then also implement the way to think about it? Without looking at any code to see how it’s currently done, I would probably just change [[Get]], etc. on HTMLObjectElement such that it takes the plugin’s interface into account. Admittedly that would violate the requirement that the [[Get]] of a host object operate in a particular way. I'm not sure how the major vendors handle the nsruntime object, the documentation doesn't seem clear. I guess it is possible to handle it in the way you suggested. This (ab)use of [[Get]] seems similar to how the WindowProxy object works in HTML5, so it wouldn't be the first time its been done (and we change the prototype objects rather than actually implementing the HTML5 behavior here). CE-HTML allows audio and video to be embedded using object, and gives interfaces for these cases. The implication seems to be that there should be interface prototype objects for these. I *believe* Opera has support for CE-HTML (but perhaps not on the standard versions, a quick google shows that someone has spotted one in a User-Agent header), so it would be interesting to find out how that behaves. -- Andrew Oakley
RE: [Widget URI] Internationalization, widget IRI?
Hi Robin, Thanks for your comments. I believe the terminology could be clarified once the IRI/URI issue from PC gets solved in I18N, hopefully together with HREF and all related stuff. +1 for simplification. Thanks, 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: Robin Berjon [mailto:ro...@berjon.com] Sent: Wednesday, September 02, 2009 11:17 PM To: Marcin Hanclik Cc: public-webapps WG Subject: Re: [Widget URI] Internationalization, widget IRI? Hi Marcin, On Jul 24, 2009, at 18:36 , Marcin Hanclik wrote: Why is the Widgets 1.0: URI Scheme about URI and not IRI? Because it was written quickly :) And also because I'm sick and tired of the level of terminology needed to address (no pun intended) what should be a simple field - I'd like to just say URI and since this isn't a legacy context obviously it means IRI with the added advantage that it doesn't hurt the brains of the majority of readers... Anyway, no point in ranting over spilt beer I guess. Based on the follow-up discussion what I've done is that I've used IRI throughout the specification except when discussing URI schemes. I've also updated the reference to be to RFC 3987 and the syntax to reference iauthority, iquery, and ifragment - which is indeed more correct. Thanks! -- Robin Berjon - http://berjon.com/ 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: DnD vs CnP (was Copy/Paste Events)
On Mon, 31 Aug 2009, Paul Libbrecht wrote: Le 31-ao�t-09 � 04:44, Ian Hickson a �crit : Honestly, I find the whole DnD and CnP treatment in HTML5 quite much ad-hoc. It's welcome to have such an addition but it makes too many arrangements and still is hard to read. Yes, it's a horrible model. It's one that had been implemented multiple times before the spec existed, and implementations trump pretty much everything except security problems when it comes to deciding what the spec should say. could I request a pointer to implementations or, even better, test-cases ? This is where I'd like my test cases to be: http://hixie.ch/tests/adhoc/dom/web-apps/drag-and-drop/ ...but I have very few so far. Currently, Safari and IE support this API to some extent in their respective shipping products, and Firefox either supports it in the shipping version or in the next version, I don't recall (it's in the nightlies, either way). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[webdatabase] Minor Clarification Needed in Processing Model
Hi, In step 10 of the processing model, it states: Queue a task to invoke the error callback, if it is not null, with a newly constructed SQLError object that represents the last error to have occurred in this transaction. Rollback the transaction. Any still-pending statements in the transaction are discarded. Can you clarify this statement so that it's clearer that it's referring to the transaction's error callback, and not a statement error callback in executeSql. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: (no subject)
Hi Robin, Here is a pre-publication review of Widgets 1.0: Widget URIs 08 September 2009. My main beef is that this spec does not clearly tell me how to construct a WURI UA... all the bits are there, however, just need a few editorial changes, IMHO. Widgets 1.0: Widget URIs W3C Working Draft 08 September 2009 Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply. Abstract Many specifications in the Web stack depend on a context being defined that includes a current IRI. 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. I don't like the above. Why are you starting this as an argument? Such a limitation has a number of implications which this document intends to address. Just say what the tech is, IMO. Requirements section covers this better. Besides, once the spec is out, then the above is not a problem any more, so it's a tautology to have this line of reasoning here. Status of This Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. This document was published by the Web Applications WG as a Last Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives). The Last Call period ends 10 November 2009. All feedback is welcome. This LC period is too long. Make it 10th of October or mid October. This is to facilitate two LCs. snip 1. Introduction This section is non-normative. This specification defines the widget URI scheme that is used to address resources inside a widget [WIDGETS]. change to inside a widget package 2. Conformance As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119]. 3. Not in this specification This section is non-normative. There are many different efforts that have specified URI schemes to access the content of Zip archives, or endeavour to do so. While these endeavour endeavor efforts have merit, and while W3C Widgets rely on Zip as a packaging format, the use cases that this specification addresses are radically different. radically is unnecessary. You make grand statements, but then don't back them. What is so radical about what we are doing? Don't tell me (I know how awesome we are!), put in the spec :) In fact, it is possible that both this scheme and another defined to access Zip archive content would be used jointly, with little or no overlap in functionality. The scheme defined in this specification could be used to implement inter-widget communication, but that is outside the scope of this current document. This is not proven. I would just say that cross-widget is out of scope and, may be future work, but not that it could be used for that. 4. Requirements All this should be moved to the widgets requirements doc. This section is non-normative. Must allow addressing resources inside a widget The scheme must be able to address Zip relative paths as defined in the Widgets: Packaging and Configuration [WIDGETS] specification. yep Must allow resolving relative URL references inside a widget It must be possible for a document inside a widget to use a relative reference to another without any specific knowledge of the scheme being used. For instance, if a document located at dahuts/dextrogyrous.html features a link to levrogyrous.html that link must resolve to dahuts/levrogyrous.html. yep Must not allow addressing resources outside a widget There is no requirement on how widgets are stored and potentially unpacked within a given user agent, but irrespective of how that is performed, including for instance by storing the unpacked widget on the local file system, it must be impossible to address resources outside of the widget using this scheme. yep Must provide an origin IRI for widget-contained documents Many mechanisms in widgets (e.g. cookies, local storage, XMLHttpRequest) key off the IRI or part thereof from which they are used. Since widgets are for all intents and purposes local applications that do not have an origin, this scheme must provide integration with these mechanisms. double yep! 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
[widgets] Draft Minutes for 3 September 2009 Voice Conference
The draft minutes from the September 3 Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/09/03-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 10 September 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 03 Sep 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/0935.html See also: [3]IRC log [3] http://www.w3.org/2009/09/03-wam-irc Attendees Present Marcin, Art, Marcos, Arve, Steven, Bryan, Benoit Regrets Robin, AndyB, Frederick Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]PC spec: comments from PFWG 4. [8]PC spec: IRI/URI normalization 5. [9]PC spec: Conformance Checker (CC) requirements 6. [10]Introduction by Steven Pemberton 7. [11]widget Interface spec: storage 8. [12]WARP spec: LC comments from Marcin Hanclik 9. [13]Widget URIs spec: proposal to publish LCWD 10. [14]View Modes spec: status 11. [15]AOB * [16]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date 3 September 2009 Review and tweak agenda AB: the draft agenda was posted on September 2 ( [17]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/09 35.html ). I propose adding View Modes before AOB. Any objections to that? ... any change requests? [17] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/0935.html [ None ] Announcements AB: Reminders on upcoming deadlines: 1) Sep 14 is deadline to register for Widgets Testing event ( [18]http://www.w3.org/2008/webapps/wiki/TestWorkshop2009 ); 2) Sep 15 comment deadline for APIs and Events LCWD; 3) Sep 20 comment deadline for WARP LCWD ... Does anyone have any other short announcements? [18] http://www.w3.org/2008/webapps/wiki/TestWorkshop2009 [ None ] PC spec: comments from PFWG AB: on August 27, WAI's Protocols and Formats WG submitted comments against the PC LCWD ( [19]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/08 43.html ). Although these comments are late, we should still respond to them. Note these comments have been added to the PC post-LCWD comment tracker ( [20]http://www.w3.org/2008/webapps/wiki/Widgets/PandC-LCWD-28May2009 ). ... Marcos, have you had a chance to review these? [19] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/0843.html [20] http://www.w3.org/2008/webapps/wiki/Widgets/PandC- LCWD-28May2009 MC: just briefly ... most related to Conformance Checker AB: let's make sure we respond MC: OK, will do scribe ACTION: caceres respond to PFWG's comments on the P+C LCWD [recorded in [21]http://www.w3.org/2009/09/03-wam-minutes.html#action01] trackbot Created ACTION-399 - Respond to PFWG's comments on the P+C LCWD [on Marcos Caceres - due 2009-09-10]. AB: ok thanks Marcos; I don't consider this urgent arve sorry for late IRC arrival PC spec: IRI/URI normalization AB: this topic is continued from our 27 August Voice Conf ( [22]http://www.w3.org/2009/08/27-wam-minutes.html#item03 ). Has anyone received feedback from the I18N WG on this issue ( [23]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/06 44.html )? ... I checked their public mail list and it appears they did not meet on Sept 2 ... but I don't know if they meet weekly or not [22] http://www.w3.org/2009/08/27-wam-minutes.html#item03 [23] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/0644.html MH: they meet later in the day, Europe time AB: Marcos, Marcin - have you received any feedback from them? MC: no MH: no AB: OK, I'll ping Addison scribe ACTION: barstow follow-up with Addisson and Richard and I18N Core WG re the URI/IRI normalization issue for the P+C spec [recorded in [24]http://www.w3.org/2009/09/03-wam-minutes.html#action02] trackbot Created ACTION-400 - Follow-up with Addisson and Richard and I18N Core WG re the URI/IRI normalization issue for the P+C spec [on Arthur Barstow - due 2009-09-10]. AB: anything else on that topic today? [ No ] PC spec: Conformance Checker (CC) requirements AB: on IRC yesterday, Marcos raised the question What are we going to do if no one implements the Conformance Checker (CC) requirements?. MC: a question is how to we progress the spec if no one implements
Re: [widgets] WURI Review pre-LC review
(additional typo found, at bottom of email) On Thu, Sep 3, 2009 at 2:25 PM, Marcos Caceresmarc...@opera.com wrote: (Apologies for sending this twice, screwed up the subject on the last one... email is hard!:) ) Hi Robin, Here is a pre-publication review of Widgets 1.0: Widget URIs 08 September 2009. My main beef is that this spec does not clearly tell me how to construct a WURI UA... all the bits are there, however, just need a few editorial changes, IMHO. Widgets 1.0: Widget URIs W3C Working Draft 08 September 2009 Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply. Abstract Many specifications in the Web stack depend on a context being defined that includes a current IRI. 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. I don't like the above. Why are you starting this as an argument? Such a limitation has a number of implications which this document intends to address. Just say what the tech is, IMO. Requirements section covers this better. Besides, once the spec is out, then the above is not a problem any more, so it's a tautology to have this line of reasoning here. Status of This Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. This document was published by the Web Applications WG as a Last Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives). The Last Call period ends 10 November 2009. All feedback is welcome. This LC period is too long. Make it 10th of October or mid October. This is to facilitate two LCs. snip 1. Introduction This section is non-normative. This specification defines the widget URI scheme that is used to address resources inside a widget [WIDGETS]. change to inside a widget package 2. Conformance As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119]. 3. Not in this specification This section is non-normative. There are many different efforts that have specified URI schemes to access the content of Zip archives, or endeavour to do so. While these endeavour endeavor efforts have merit, and while W3C Widgets rely on Zip as a packaging format, the use cases that this specification addresses are radically different. radically is unnecessary. You make grand statements, but then don't back them. What is so radical about what we are doing? Don't tell me (I know how awesome we are!), put in the spec :) In fact, it is possible that both this scheme and another defined to access Zip archive content would be used jointly, with little or no overlap in functionality. The scheme defined in this specification could be used to implement inter-widget communication, but that is outside the scope of this current document. This is not proven. I would just say that cross-widget is out of scope and, may be future work, but not that it could be used for that. 4. Requirements All this should be moved to the widgets requirements doc. This section is non-normative. Must allow addressing resources inside a widget The scheme must be able to address Zip relative paths as defined in the Widgets: Packaging and Configuration [WIDGETS] specification. yep Must allow resolving relative URL references inside a widget It must be possible for a document inside a widget to use a relative reference to another without any specific knowledge of the scheme being used. For instance, if a document located at dahuts/dextrogyrous.html features a link to levrogyrous.html that link must resolve to dahuts/levrogyrous.html. yep Must not allow addressing resources outside a widget There is no requirement on how widgets are stored and potentially unpacked within a given user agent, but irrespective of how that is performed, including for instance by storing the unpacked widget on the local file system, it must be impossible to address resources outside of the widget using this scheme. yep Must provide an origin IRI for widget-contained documents Many mechanisms in widgets (e.g. cookies, local storage, XMLHttpRequest) key off the IRI or part thereof from which they are used. Since widgets are for all intents and purposes local applications
RE: to publish the First Public Working Draft of Web Database spec; deadline 7 September
I support this. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Monday, August 31, 2009 11:01 AM To: public-webapps Subject: CfC: to publish the First Public Working Draft of Web Database spec; deadline 7 September This is a Call for Consensus (CfC) to publish the First Public Working Draft (FPWD) of the Web Database spec: http://dev.w3.org/html5/webdatabase/ Note that at one point in time, the Web Database spec's functionality was included in the Web Storage spec. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is September 7. -Regards, Art Barstow
Re: DnD vs CnP (was Copy/Paste Events)
On Thu, 3 Sep 2009, Paul Libbrecht wrote: Which of them supports to transfer arbitrary flavours? Generic image formats along of markup? I do not recall off-hand. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[web databases] changeVersion error reporting
Hi! Database.changeVersion expects oldVersion and newVersion arguments. The Database also specifies a version attribute. The transaction steps tell to fail the transaction due to the failed preflight condition if oldVersion does not match the current database version. Meanwhile, the callbacks have been made optional, and rightly so. So: - if the author does not use the callbacks, there no error reporting that the preflight condition failed - the version check can be done synchronously when changeVersion is called because the Database object has immediate access to that value, and it's much more convenient for the author to just get an exception (like INVALID_STATE_ERR) than to have to go through the entire callback process just to realize later that the transaction failed due to the mismatched version. It also spares the user agent from creating and executing a transaction that WILL fail. To solve these issues, I would suggest doing immediate synchronous validation of the version when changeVersion is called, throwing an exception on error, and drop that step from the preflight operations. Thank you.
Re: [web databases] changeVersion error reporting
If the version is stored in the database file itself, as is with webkit's impl for example, the database object does not have immediate access to that value. On Thu, Sep 3, 2009 at 5:57 PM, João Eiras jo...@opera.com wrote: Hi! Database.changeVersion expects oldVersion and newVersion arguments. The Database also specifies a version attribute. The transaction steps tell to fail the transaction due to the failed preflight condition if oldVersion does not match the current database version. Meanwhile, the callbacks have been made optional, and rightly so. So: - if the author does not use the callbacks, there no error reporting that the preflight condition failed - the version check can be done synchronously when changeVersion is called because the Database object has immediate access to that value, and it's much more convenient for the author to just get an exception (like INVALID_STATE_ERR) than to have to go through the entire callback process just to realize later that the transaction failed due to the mismatched version. It also spares the user agent from creating and executing a transaction that WILL fail. To solve these issues, I would suggest doing immediate synchronous validation of the version when changeVersion is called, throwing an exception on error, and drop that step from the preflight operations. Thank you.
Re: [web databases] changeVersion error reporting
So that was one of the motives to add the creation callback on openDatabase I presume. In either case, before the script gets a Database object, a version check needs to be made during openDatabase, so the value can be cached inside the Database object, to be used for changeVersion, the version property and subsequent transactions. On Fri, 04 Sep 2009 03:06:37 +0200, Michael Nordman micha...@google.com wrote: If the version is stored in the database file itself, as is with webkit's impl for example, the database object does not have immediate access to that value. On Thu, Sep 3, 2009 at 5:57 PM, João Eiras jo...@opera.com wrote: Hi! Database.changeVersion expects oldVersion and newVersion arguments. The Database also specifies a version attribute. The transaction steps tell to fail the transaction due to the failed preflight condition if oldVersion does not match the current database version. Meanwhile, the callbacks have been made optional, and rightly so. So: - if the author does not use the callbacks, there no error reporting that the preflight condition failed - the version check can be done synchronously when changeVersion is called because the Database object has immediate access to that value, and it's much more convenient for the author to just get an exception (like INVALID_STATE_ERR) than to have to go through the entire callback process just to realize later that the transaction failed due to the mismatched version. It also spares the user agent from creating and executing a transaction that WILL fail. To solve these issues, I would suggest doing immediate synchronous validation of the version when changeVersion is called, throwing an exception on error, and drop that step from the preflight operations. Thank you.
