Re: Steps to creating a browser standard for the moz-icon:// scheme
Hi Pierre, On 21/03/10 10:15 PM, Pierre-Antoine LaFayette wrote: Thank you Marcos for your feedback. You are correct; I did not make it clear that the calls to getImageData and toDataURL should raise the standard exception that occurs when attempting to access data of a tainted canvas. I've updated the document to make it more explicit: An Image object with an icon URI as its src attribute MUST NOT be considered as same-origin as any other origin. If an Image with an icon URI src is drawn to a canvas, the canvas MUST be considered tainted and have its origin-clean flag set to false. As such, if getImageData or toDataURL is called on a canvas that has been tainted by icon URI Image data, the method MUST raise a SECURITY_ERR http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#security_err exception. See Security with canvas elements http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#security-with-canvas-elements in the HTML5 Draft Standard file:///K:/draft-icon-uri-scheme/draft-lafayette-icon-uri-scheme-00.html#HTML5 [HTML5] for further details. Looks good to me :) On 21 March 2010 14:04, Marcos Caceres marc...@opera.com mailto:marc...@opera.com wrote: Hi, On Sun, Mar 21, 2010 at 4:16 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com mailto:pierre.lafaye...@gmail.com wrote: Hi everyone! Sorry I've let this thread go a bit stale. I've been tied up with more pressing matters for a while now :( From the all the great feedback in this thread, I've been able to determine that there really should be 2 parts to this proposal: The specification of an icon URI scheme that resolves platform icons by filetype The extension of the File object interface to include methods to retrieve its icon data or perhaps an icon URI that doesn't taint the canvas The first part is a reduction of the original scope of the icon URI scheme to the essential functionality that everyone seemed (if I'm not mistaken) to be okay with. I'm sure further functionality could be added in the future if needed. Everyone seemed to agree that #2 is a good idea --albeit not mine; credit to Maciej for this one. So for the first part, I've put together a draft document that I'd really like everyone to comment on before I even consider sending it out to uri-rev...@ietf.org mailto:uri-rev...@ietf.org. It is located here: http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html. Just had a quick read... overall, the document reads quite well. However, I think the following might be a little bit underspecified: Applications MUST NOT allow the getImageData and toDataURL methods to access to the Image data of platform icons drawn to the canvas. I agree with the rationale of the security consideration, but perhaps it would be nice to throw an appropriate DOM exception here... might help developers know programmatically why they are not allowed to access these things. Without some kind of indication, it might leave people thinking that there is a bug in the browser or that they've done something wrong. I hope it correctly interprets the issues we've discussed. For the second part, I'm not exactly sure what the correct procedure is. I imagine it would involve making an addendum to the existing File interface specification. So if anyone has any guidance on this, it would be greatly appreciated. Once again; thanks for everyone's help and patience in this process. -- Pierre. -- Marcos Caceres http://datadriven.com.au -- Pierre. -- Marcos Caceres Opera Software
Re: [IndexedDB] IDBRequest Interface Questions
On 3/22/2010 10:05 AM, Jeremy Orlow wrote: I also can't seem to figure out what the success event is supposed to be for just about anything. Am I just missing something, or is this not yet specified? When onsuccess fires, you can then start the next request. Sorry, I guess I'm not being totally clear in what I'm asking. In the Events [1] section, only IDBDatabaseError is specified. I'm not sure what a success message should look like, and that's what I'm asking to be clarified. Do you have anything to say regarding a callback based API vs. event one that inherits from EventTarget? By callback you mean passing a callback function into the API calls, correct? Assuming that, I prefer the event based API, but I think the current spec could you some modifications to address some concerns that were brought up. As I recall, the issue with the current event-based model is that you can only have one request in flight at a time. I think we could solve this problem by having the asynchronous methods return an IDBRequest object instead of having a global one for a given context (not completely sure how to describe all the places where we have a request attribute but that is what I am talking about). I'm not 100% sure yet if we'd need the request attribute on all of these things after doing this, or what it would be in each instance. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [widgets] Span example
On Mon, Mar 22, 2010 at 1:02 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: All, I think the span and dir models work well. I've implemented the new algorithms in Wookie for License, Name, Author and Description, and they seem to work nicely[1]. I'll add the same functionality to the Widget root element as the next step. Great to hear! When the test cases have documentation I'll add them to our test suite and see if we can pass them. I'll try to make these ASAP. If I can assume the UA supports BIDI (I think all modern browsers do at the HTML rendering level), then I can just put HTML equiv. of each test into a HTML file. Otherwise, I need make images out of every test, which will take a little time. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [IndexedDB] IDBRequest Interface Questions
On Mon, Mar 22, 2010 at 5:17 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 3/22/2010 10:05 AM, Jeremy Orlow wrote: I also can't seem to figure out what the success event is supposed to be for just about anything. Am I just missing something, or is this not yet specified? When onsuccess fires, you can then start the next request. Sorry, I guess I'm not being totally clear in what I'm asking. In the Events [1] section, only IDBDatabaseError is specified. I'm not sure what a success message should look like, and that's what I'm asking to be clarified. Do you have anything to say regarding a callback based API vs. event one that inherits from EventTarget? By callback you mean passing a callback function into the API calls, correct? Assuming that, I prefer the event based API, but I think the current spec could you some modifications to address some concerns that were brought up. As I recall, the issue with the current event-based model is that you can only have one request in flight at a time. I think we could solve this problem by having the asynchronous methods return an IDBRequest object instead of having a global one for a given context (not completely sure how to describe all the places where we have a request attribute but that is what I am talking about). I'm not 100% sure yet if we'd need the request attribute on all of these things after doing this, or what it would be in each instance. I'm not an expert on JS performance, but I wonder if this would be a bottleneck in a highly optimized implementation. Then again, maybe it's not that much worse than simply passing callback functions into the API calls. Btw, this is one of the things I mentioned on a thread in the last week or two. It'd be really nice if you and anyone else could weigh in on the recent threads about this stuff. At this point, I really don't care. I just want to get all of this settled on so I don't have to re-write my bindings in a couple weeks. J
Re: FormData with sliced Blob
What about using a filename that is unique with repect to files sent in that FormData (but it is up to the UA)? For example, a UA may choose to do Blob1, Blob2, etc. For the content-type, application/octet-string seems most fitting. Here's the result applied to your example: --SomeBoundary... Content-Disposition: form-data; name=file; filename=Blob1 Content-Type: application/octet-string dave On Fri, Mar 19, 2010 at 6:25 PM, Jian Li jia...@google.com wrote: Hi, I have questions regarding sending FormData with sliced files. When we send a FormData with a regular file, we send out the multipart data for this file, like the following: --SomeBoundary... Content-Disposition: form-data; name=file; filename=test.js Content-Type: application/x-javascript ... However, when it is sliced into a blob, it does not have the file name and type information any more. I am wondering what we should send. Should we just not provide the filename and Content-Type information? Thanks, Jian
Re: [widgets] Span example
On Fri, Mar 19, 2010 at 12:49 PM, Arthur Barstow art.bars...@nokia.com wrote: Richard, Addison, Felix, All, Based on my conversations with Marcos and reading this thread, it is my understanding that you support: a) the new span element and dir attribute model Marcos added to the Widget PC spec [PC-ED] and consequently, b) the removal of the ITS references that were in the December CR [PC-CR]. Would you please confirm this or if my understanding is not correct, please elaborate on any remaining issues? Also, if you have any feedback on the 60 related test cases Marcos created, please reply to the thread he used to announce those test cases: [widgets] dir and span tests http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0845.html Just a minor thing, but I consolidated my original tests down to around 19 tests (I originally had auto-generated tests, but this was just too thorough and would be annoying for human testers). The reason the current tests are all in a single file is to make them easy to review. Once I get the OK from i18n, I'll convert them to proper widgets. -- Marcos Caceres http://datadriven.com.au
Re: FormData with sliced Blob
To be safe, probably UA can choose to create the unique name from the GUID, like blob-5597cb2e-74fb-479a-81e8-10679c523118. On Mon, Mar 22, 2010 at 4:43 PM, David Levin le...@google.com wrote: What about using a filename that is unique with repect to files sent in that FormData (but it is up to the UA)? For example, a UA may choose to do Blob1, Blob2, etc. For the content-type, application/octet-string seems most fitting. Here's the result applied to your example: --SomeBoundary... Content-Disposition: form-data; name=file; filename=Blob1 Content-Type: application/octet-string dave On Fri, Mar 19, 2010 at 6:25 PM, Jian Li jia...@google.com wrote: Hi, I have questions regarding sending FormData with sliced files. When we send a FormData with a regular file, we send out the multipart data for this file, like the following: --SomeBoundary... Content-Disposition: form-data; name=file; filename=test.js Content-Type: application/x-javascript ... However, when it is sliced into a blob, it does not have the file name and type information any more. I am wondering what we should send. Should we just not provide the filename and Content-Type information? Thanks, Jian
Re: FormData with sliced Blob
To be even safer, I'd remove dashes from it... I never knew why GUIDs have those dashes - to make them easier to memorize? :-) Seriously though, it would be nice to have XHR2 spec to have these details spelled out, especially mime type (I think David meant application/octet-stream) Dmitry On Mon, Mar 22, 2010 at 5:26 PM, Jian Li jia...@google.com wrote: To be safe, probably UA can choose to create the unique name from the GUID, like blob-5597cb2e-74fb-479a-81e8-10679c523118. On Mon, Mar 22, 2010 at 4:43 PM, David Levin le...@google.com wrote: What about using a filename that is unique with repect to files sent in that FormData (but it is up to the UA)? For example, a UA may choose to do Blob1, Blob2, etc. For the content-type, application/octet-string seems most fitting. Here's the result applied to your example: --SomeBoundary... Content-Disposition: form-data; name=file; filename=Blob1 Content-Type: application/octet-string dave On Fri, Mar 19, 2010 at 6:25 PM, Jian Li jia...@google.com wrote: Hi, I have questions regarding sending FormData with sliced files. When we send a FormData with a regular file, we send out the multipart data for this file, like the following: --SomeBoundary... Content-Disposition: form-data; name=file; filename=test.js Content-Type: application/x-javascript ... However, when it is sliced into a blob, it does not have the file name and type information any more. I am wondering what we should send. Should we just not provide the filename and Content-Type information? Thanks, Jian
[Notifications] feedback requested on new Editor's Draft
After the extensive discussion several weeks ago, I've been working on a new draft for Web Notifications which is now available at http://dev.w3.org/2006/webapi/WebNotifications/publish/ The most substantial changes are: - Add requirements section. This is derived from the wiki page which Doug Schepers started, but I think it should live inside the spec. It's clear that there is interest in implementing the spec using Growl and other such platform APIs, so I've made it explicit that the spec is required to allow that implementation. At the same time, to achieve platform/device independence and look to the future of more sophisticated notifications, it isn't specified as the only way notifications can be implemented. - Rename HTMLNotification to WebNotification to allow other types of content (e.g. SVG as was in the feedback) and move this to a supplemental interface. - Add a definitions section so that terminology is clear. I look forward to seeing additional feedback. Thanks, -John
Items not listed as new in the draft charter
The following items are not listed as new in the draft charter, although they do not appear in the previous charter and are not an obvious continuation of a previous charter spec: Indexed Database API Programmable HTTP Caching and Serving Uniform Messaging Policy Selectors API Level 2 Widgets Access Request Policy Widgets URI Scheme Widgets View Mode References: http://www.w3.org/2008/webapps/charter/ http://www.w3.org/2010/webapps/charter/ Apologies for not catching this sooner. Regards, Maciej P.S. I know some of these have been published on already despite not being listed in the previous charter, but I don't think that will meet the definition of new that most readers of this charter will have in mind.
Re: [widgets] Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17
While reviewing the new Web Apps WG charter, I noticed that the current (2008) charter does not list this deliverable. It also says: The WebApps WG will not take on new Recommendation-Track Widgets deliverables without new charter review. Could someone point me to the justification for publishing this spec in the current charter: http://www.w3.org/2008/webapps/charter/ Was there charter review for this item? If so, why was the charter not updated? Regards, Maciej On Mar 4, 2010, at 6:59 AM, Arthur Barstow wrote: This is the start of a 2-week pre-LCWD call for comments re the View Modes Media Feature spec: http://dev.w3.org/2006/waf/widgets-vmmf/Overview.html If you have any comments, please send them to public-webapps@w3.org by March 17. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Additionally, a LCWD should be considered feature-complete with all issues resolved. We will explicitly ask the CSS WG (via the www-style mail list) for comments. If there are other groups that should be asked for comments, please forward this email to them or identify the group(s). -Art Barstow Begin forwarded message: From: ext Robin Berjon ro...@berjon.com Date: March 4, 2010 8:13:17 AM EST To: public-webapps WG public-webapps@w3.org Subject: VMMF — new version Archived-At: http://www.w3.org/mid/1da7a886-141b-46ff-9ff7-6baa6cc6e...@berjon.com Hi all, I just produced an update of VMMF to make it ready for publication: http://dev.w3.org/2006/waf/widgets-vmmf/ . Essentially I changed it so that it corresponds to CSS Media Queries. That, plus it being a UI oriented specification, means that there's only one normative assertion and it's a SHOULD. Comments welcome, I think that this baby can ship. -- Robin Berjon - http://berjon.com/
Re: Items not listed as new in the draft charter
On Mar 22, 2010, at 9:12 PM, Doug Schepers wrote: Hi, Maciej- Maciej Stachowiak wrote (on 3/22/10 10:36 PM): The following items are not listed as new in the draft charter, although they do not appear in the previous charter and are not an obvious continuation of a previous charter spec: Indexed Database API Programmable HTTP Caching and Serving Uniform Messaging Policy Selectors API Level 2 Widgets Access Request Policy Widgets URI Scheme Widgets View Mode References: http://www.w3.org/2008/webapps/charter/ http://www.w3.org/2010/webapps/charter/ Apologies for not catching this sooner. P.S. I know some of these have been published on already despite not being listed in the previous charter, but I don't think that will meet the definition of new that most readers of this charter will have in mind. Thanks for mentioning this. You may be right that, even though they grew out of existing deliverables, others may see them as new. I will talk with PLH about what we should do here. I tried to omit items that I knew to be renames or splits of a draft in the old charter. I may have missed some, especially in the case of Widgets where I'm not up to speed on what is in the specs. I believe at least the first three were written from scratch without incorporating text from any previous draft. But now that I think about it, renames should be called to the charter reviewers' attention as well. Here are the splits and renames I am aware of: Web SQL Database -- split from Web Storage File API -- formerly File Upload; the charter mentions this already Widgets Packaging and Configuration -- formerly Widgets 1.0: Packaging and Configuration The Widget Interface -- formerly Widgets 1.0: APIs and Events Widgets Digital Signature -- formerly Widgets 1.0: Digital Signature Widgets Updates -- formerly Widgets 1.0: Updates Even if not included in the charter itself, it would probably be useful to bring this information to the AC's attention (as well as any splits or renames I may have missed). Regards, Maciej
