Copy/Paste Events

Section 7.10.6 "Copy and paste" of the HTML5 spec suggests that "copy-and-paste is a form of drag-and-drop." It mandates that for a copy operation the user agent should act as if the user had initiated a drag on the current selection. L

RE: Window Modes todo

Adding WWW-DOM to widen the audience a bit. >> Having the attributes not be read only and allowing their modification >> before the Event is dispatched seems better to me. But changing this for >> DOM Events in general seems like a larger issue for discussion. Note that this is how it works i

RE: [P&C] utf8-char in Zip-rel-path

Hi, Given the fact that "Rule names are case insensitive." http://tools.ietf.org/html/rfc5234#section-2.1 it could potentially be better to rename the rule from "utf8-char" to something else, since it may get confused with "UTF8-char" rule from http://tools.ietf.org/html/rfc3629#section-4. Ta

RE: [Widget URI] Bugs (1)

Hi again, authority = [ userinfo "@" ] host [ ":" port ] The below 1. could be correct if assumed host is "beefdead". I am not sure, however, whether in the widget-URI rule, we use the authority rule from RFC3986, because it is meant to be opaque as specified here: http://dev.w3.org/2006/waf/w

[Widget URI] Bugs (1)

Hi All, Given the grammar: widget-URI = "widget:" "//" [ authority ] "/" zip-rel-path [ "?" query ] [ "#" fragment ] the following statements in the Widgets 1.0: URI Scheme WD http://www.w3.org/TR/2009/WD-widgets-uri-20090618/ are incorrect: 1. "Example widget URIs could thus be: widget://be

RE: [Widget URI] Internationalization, widget IRI?

>>I wonder if the URI registration process document should specifically >>allow registration forms to describe the URI scheme syntax in terms of >>IRI characters. You mean URI scheme syntax or the whole URI syntax? As for URI scheme syntax, it probably does not matter, since only ALPHA, DIGIT & C

RE: [Widget URI] Internationalization, widget IRI?

Hi Larry, Thanks for your comments. FYI I sent the following emails to webapps: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0373.html http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0376.html There are two topics around widgets 1.0 and IRIs: 1. IRI is P&C 2. zip-r

RE: [Widget URI] Internationalization, widget IRI?

I'm sorry for the confusion, my email was sent by mistake. I have not re-reviewed the "widget" URI scheme since a previous review several months ago. I was only reacting to something in your email. I suppose I should re-review the "widget" URI scheme document itself, but I haven't. My goal at the m

[Widgets] URI Scheme -> URI [+ Scheme]

Hi All, following my email: http://lists.w3.org/Archives/Public/public-iri/2009Jul/0023.html I suggest the following: 1. renaming the Widgets 1.0: URI Scheme specification to Widgets 1.0: URI (or Widgets 1.0: Widget URI or so) 2. adding widget-scheme = "widget" rule 3. modifying the existing rule

RE: [Widget URI] Internationalization, widget IRI?

Hi, This time I seem to have been unclear. It seems that in Widget URI [Scheme] specification we should have: widget-scheme = "widget" to define the Widget Scheme. The widget-URI production should then refer to this new component. My questions around UTF-8-encoded or general Unicode characters

RE: [Widget URI] Internationalization, widget IRI?

Hi Larry, Ok, I see. Thanks. The "scheme" part seems clear: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) My initial email was about Widget URI, specifically not about the scheme part, but the further component Zip-rel-path. widget-URI = "widget:" "//" [ authority ] "/" zip-rel-pa

[P&C] utf8-char in Zip-rel-path

Hi Marcos, All, Following my previous email about Zip-rel-path and concluding that utf8-char non-terminal is wrongly specified (i.e. it indicates that Zip-rel-path operates on characters, not bytes, whereas I assume operation on bytes is our target), I wonder whether Zip-rel-path shouldn't refe

RE: [Widget URI] Internationalization, widget IRI?

Hi Larry, Thanks for your prompt comments. >>I'm not sure that the draft makes >>this clear It seems not. When reading the IRI grammar, I derive that "%" is valid there: http://tools.ietf.org/html/rfc3987#section-2.2 pct-encoded= "%" HEXDIG HEXDIG ipchar = iunreserved / pct-encoded