Re: [Uri-review] Review request: widget URI scheme
On 25.02.2010 11:54, Robin Berjon wrote: Hi, on behalf of the W3C WebApps Working Group I would like to request review for the registration of the widget URI scheme. The filled out registration template can be found at: http://dev.w3.org/2006/waf/widgets-uri/registration.txt And the specification at: http://dev.w3.org/2006/waf/widgets-uri/ There is one specific aspect on which we would like to particularly solicit your guidance. While the fact that implementations are shipping presently has produced the need to define this URI scheme, we believe that we may update it at a later date to take into account use cases not yet addressed by our technology stack (the W3C Widgets family of specifications). As such, we would like to know if it is best registered as provisional (the scheme is intended to evolve) or permanent (the technology it is a part of is intended to become a permanent part of the landscape). We are happy with either option, we mostly ask because it is unclear to us from RFC4395 what the guiding principles should be in electing one over the other. Thanking you in advance for your review, A few things that I stumbled upon on a quick read: - The registration does not include a reference to the spec that actually defines the URI scheme - Neither the registration nor the spec actually define the syntax (I couldn't see an ABNF...). You probably can re-use the grammar in RFC 3986, but you really should state that. - It appears that the spec tries to define things in terms of IRIs; my understanding is that what you need to define are URIs (plain ASCII, as per RFC 3986), and then optionally include additional information about how to map from/to IRIs. Best regards, Julian
Re: Notifications
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 10, 2010, at 20:35, John Gregg wrote: I agree that this is a good distinction, but I think even considering ambient notifications there is a question of how much interaction should be supported. NotifyOSD, for example, does not allow the user to take any action in response to a notification. Being able to acknowledge an ambient notification could be an optional feature that isn't supported on Ubuntu as long as NotifyOSD doesn't support acknowledging notifications. (If it's a problem to make acknowledgement optional, I think making HTML notification optional is going to be a bigger problem...) FWIW, Microsoft explicitly says notifications must be ignorable and don't persist. Notifications aren't modal and don't require user interaction, so users can freely ignore them. In Windows Vista® and later, notifications are displayed for a fixed duration of 9 seconds. http://msdn.microsoft.com/en-us/library/aa511497.aspx As such, it's always unsafe to design UI in a way that expects the users to be able to acknowledge a given notification. FWIW, the mentioned document is full of examples of Notifications that have text like Click here to ... on them. So Microsoft apparently differentiates between requires user dismissal and can be clicked for furhter action. Also, the absence of any hints that their notifications are actually clickable makes them have this text everywhere, which is unfortunate, IMO. Dmitry
[widgets] dir and span elements
Hi i18n WG, I've added the dir attribute and span elements to the Widgets PC Specification, as well as a bunch of examples (which are wrong, so I would really appreciate some help with these!). The dir attribute is specified here: http://dev.w3.org/2006/waf/widgets/#global-attributes The span element is specified here: http://dev.w3.org/2006/waf/widgets/#the-span-element The processing step that defers to the yet to be written [WIDGET-BIDI] specification is defined here: http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content The specification makes it mandatory that a user agent implement the WIDGET-BIDI spec: A user agent is an implementation of this specification that also supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS-BIDI], and [ZIP]... We would appreciate your review and any assistance you can provide. In particular, we would appreciate your guidance into what would go into the Widgets Bidi specification (i.e., how processing is done for dir and span). At the moment, we only have the following text for such a specification (based on HTML5's bdo element): [[ If an element has the dir attribute set to the exact value ltr, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. If the element has the dir attribute set to the exact value rtl, then for the purposes of the bidi algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the element. The requirements on handling the span element for the bidi algorithm may be implemented indirectly through the style layer. ]] Thanks again for all your time and help! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: FormData questions
Horray for FormData! My $0.02 * UTF8 always * Sending initiates the POST of a snapshot of the FormData at the time send is called, subsequent modifications to the FormData don't affect what is asyncly being sent, but do affect subsequent sends of the modified FormData. * XHR.send(formData) always sets the response Content-Type including the boundary tag used for the multipart encoding, overwriting any previously set value. Hmmm... perhaps send() should throw an exception if there is a previously set header value to make it more clear that callers shouldn't be setting the Content-Type when sending() this class of object. On Sun, Feb 14, 2010 at 7:32 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Feb 14, 2010 at 6:04 PM, Dmitry Titov dim...@chromium.org wrote: On Sat, Feb 13, 2010 at 6:44 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Feb 13, 2010 at 6:02 PM, Dmitry Titov dim...@chromium.org wrote: On Fri, Feb 12, 2010 at 5:32 PM, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps fans! Working on implementing FormData and ran into a couple of questions. First of all, I assume that it is intended that a FromData object can be submitted several times. I.e. that the following code is ok: fd = new FormData; fd.append(name1, foo); xhr1 = new XMLHttpRequest; xhr1.open(...); xhr1.send(fd); fd.append(name2, bar); xhr2 = new XMLHttpRequest; xhr2.open(...); xhr2.send(fd); where the first XHR will send 1 name/value pair, and the second XHR will send 2. I do think this should be allowed, but I wanted to make sure others agreed. What can be a reason to disallow this? FormData is just a collection of data objects. So assuming those XHR objects are sync, the code should work as you described. It complicates implementation a tiny amount, but IMHO not enough to disallow it. Interesting question though - what happens if XHR is async and the content of FormData changes while async operation is in progress. By analogy with scenario when underlying file of Blob object changes while async reading operation is in progress, would it be reasonable to fail the send and return 'error' ProgressEvent? I don't think raising an 'error' event should be correct, no. In my example above I think the two requests should succeed successfully, and the first one should submit one name/value pairs, and the second should submit two. Does it mean that implementation should basically produce actual form data synchronously (do a deep copy) at the moment of xhr.send() even if the xhr is asynchronous? In case FormData includes Blobs backed by files on the disk it may be prohibitive. I believe the text (non-Blob) data should be synchronously copied, yes. The Blob data needs no special handling beyond what you already have to do. The way we implement this in Firefox is that we create a multiplex data stream which consists of textual data mixed with Blob-backed data. So we create a stream implementation that will alternately read from in memory textual data, alternately from one or more Blobs. The object we create synchronously upon the call to send() just contains the text data and pointers to various Blobs. While this object is created synchronously, no data is read from the Blob. Once the network code reads from the stream, data is asynchronously read from the Blob. Don't know what setup you have for normal form submissions, so I'm not sure if you can duplicate this behavior exactly. Another way to look at it is that for the following code: fd = new FormData; fd.append(foo, bar); fd.append(name, myFile); This synchronously creates a FormData object that contains enough information to submit both textual data and a Blob. And since you can create that information synchronously, you should for the following code xhr.send(fd); be able to synchronously create a clone of the fd that similarly contains enough information to submit both textual and Blob data, and then set up to transmit that clone. / Jonas
