[progress-events] default action suggestion
Hi Anne, All, The latest ED of the Progress Events spec says: [[ http://dev.w3.org/2006/webapi/progress/#suggested-progressevent-types Throughout the web platform the |error|, |abort|, and |load| event types have traditionally not had a default action and did not bubble so it is suggested that for consistency all event types using the |ProgressEvent| interface do not bubble and are not cancelable. ]] The rationale for that recommendation seems reasonable so I'm wondering if, for interop reasons, this text should be prescriptive, as implied in the following; or if this text should be marked as non-normative: [[ http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0026.html * Event types are now suggestions rather than normative. Specifications will have to make the final call. ]] -Art Barstow
Re: [progress-events] default action suggestion
On Thu, 14 Oct 2010 16:17:04 +0200, Arthur Barstow art.bars...@nokia.com wrote: The latest ED of the Progress Events spec says: [[ http://dev.w3.org/2006/webapi/progress/#suggested-progressevent-types Throughout the web platform the |error|, |abort|, and |load| event types have traditionally not had a default action and did not bubble so it is suggested that for consistency all event types using the |ProgressEvent| interface do not bubble and are not cancelable. ]] The rationale for that recommendation seems reasonable so I'm wondering if, for interop reasons, this text should be prescriptive, as implied in the following; or if this text should be marked as non-normative: [[ http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0026.html * Event types are now suggestions rather than normative. Specifications will have to make the final call. ]] I wasn't sure whether to explicitly mark non-normative sections. In part because at least one section is normative but does not use RFC 2119 keywords (section 3.1) as it being normative comes only in to play when referenced with an accompanying conformance requirement. So I was not sure whether that would make sense. If more people feel strongly about this I could explicitly mark section 1, 2.3, 3.2, 3.3, 4, and appendix Acknowledgments non-normative. -- Anne van Kesteren http://annevankesteren.nl/
RE: Comment on Widget Interface...
Hello Art, Marcos, and Webapps, During our teleconference yesterday [1], I was tasked with formally replying to this request on behalf of the Internationalization WG. I would still like to see the 'locale' field restored to the interface. It's important to be able to query which locale the widget is running in (especially in the face of upcoming ECMAScript internationalization changes) so that the caller can match it if necessary. I agree with Marcos's approach to returning the @lang. Marcos concluded with this comment: 3. At runtime, upon getting an attribute from the Widget object (e.g., widget.name), you need to display that properly. The case is: $(#somePElement).innerHTML = widget.name; //in Arabic To display it properly, we need something like the algorithm described in: http://www.iamcal.com/understanding-bidirectional-text/ Most user-agents have implemented the Unicode Bidirectional Algorithm (which is what Cal is describing), so that isn't the issue, so much as the fact that sometimes the algorithm needs a little help. The problem is that the base direction of a string is sometimes necessary to get the correct behavior from strings. For excellent illustrations of this, see [2]. Using Unicode Bidi control characters is one way to manage this, but in a markup context, the 'dir' attribute is really preferable. If you're going to create LocalizedString, it should have both a lang and dir attribute that can be queried. Having @dir in PC will help the Widget engine display the string properly too. I look forward to seeing the resulting spec published. Please let me know if you need any assistance from me in making progress. Thanks, Addison [1] http://www.w3.org/2010/10/13-i18n-minutes.html [2] http://www.w3.org/International/articles/inline-bidi-markup/ Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs) Internationalization is not a feature. It is an architecture.
Re: [progress-events] default action suggestion
On Thu, 14 Oct 2010, Anne van Kesteren wrote: I wasn't sure whether to explicitly mark non-normative sections. In part because at least one section is normative but does not use RFC 2119 keywords (section 3.1) as it being normative comes only in to play when referenced with an accompanying conformance requirement. So I was not sure whether that would make sense. If more people feel strongly about this I could explicitly mark section 1, 2.3, 3.2, 3.3, 4, and appendix Acknowledgments non-normative. FWIW: The purpose of marking a section as non-normative is two-fold: it allows spec lawyers to quickly skip the section when trying to find the normative answer to a question, and it allows spec reviewers to notice when a requirement has been accidentally added to a place where the editor did not intend to have requirements. So for example, in the HTML spec I haven't marked the acks section as non-normative because it's obviously non-normative, and adding it doesn't add anything (no spec lawyer is going to look there anyway, and reviewers will complain if I put a requirement there regardless). But the index sections look suspiciously like they have requirements or definitions in them, so I mark those explicitly non-normative to help readers out and help reviewers warn me if I make a mistake. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Updates to FileAPI
On Tue, Oct 12, 2010 at 10:46 AM, Arun Ranganathan a...@mozilla.com wrote: WebApps WG, There have been some updates to the File API. http://dev.w3.org/2006/webapi/FileAPI/ Notable changes are: 1. Exception codes are no longer harnessed to DOMException's exception codes, per discussion on this listserv. I've updated the exception codes in the FileWriter and FileSystem specs to match, and extended appropriately. Now that we're not tied to the DOMException codes, I was able to add codes that had been requested for some very file-system-specific errors. 2. Metadata attributes creationDate and lastModifiedDate have been added to the File object, per discussion on the WHATWG listserv. 3. Blob no longer has a .url attribute. Instead, Window and WorkerGlobalScope have been extended with methods createBlobURL and revokeBlobURL, per discussion on this listserv. 4. The Blob URI section has undergone changes, per discussion on this listserv. Notably, Blob supports the addition of an HTTP Content-Type, which implementations must return as a response header when Blob URIs are dereferenced. 5. There are (ongoing) fixes to bugs, including incorrect uses of long long (in lieu of unsigned long long), per (ongoing) discussion on the listserv. I've updated the FileWriter and FileSystem specs to use unsigned long long where appropriate as well. Thanks for pointing that out. In off-list discussion, a few points have come up, which I'll summarize below: 1. The emerging HTML5 Device specification [1] includes a section on streams and an affiliated Stream API, which relies normatively on Blob URIs [2] defined in the File API. Since we've eliminated the .url property on Blob, we should also eliminate the .url property on the Stream object. There has been some discussion on renaming the methods createBlobURL and revokeBlobURL to be more generic, so that use cases such as Stream can be accommodated. This is an ongoing discussion. In general, there's consensus around eliminating the .url attribute from Stream. 2. There is ongoing discussion about the addition of Content-Disposition as well (as an attribute on Blob, as a parameter to Blob.slice, and as a response header when dereferencing blob: URIs), to facilitate and optimize downloads. The use of a Content-Disposition header allows URLs (both http:// and blob:) to dereference content straight for download, with the benefit of header-determined processing (e.g. the download doesn't occur first). Another suggestion to address this use case is that instead of supporting Content-Disposition, to allow for an additional URL property on the FileSaver constructor, modulo domain restrictions. This discussion is ongoing. 3. In general, there's ongoing discussion on allowing *even more* HTTP response behavior when dereferencing blob: URIs. I strongly favor a strict subset of HTTP, and only a use-case driven addition of further response headers and response codes. Arguments cited in favor of including all of http:// are that blob: URIs should be completely indistinguishable from HTTP URIs, thus allowing maximum reuse with XHR and other aspects of the platform. Currently, I believe we allow for a great deal of intermingling without reproducing HTTP in its entirety within Blob URIs. -- A* [1] http://dev.w3.org/html5/html-device/ [2] http://dev.w3.org/html5/html-device/#stream-api
