Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Fri, Dec 5, 2008 at 3:42 PM, Jonathan Rees [EMAIL PROTECTED] wrote: I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz i'm 99% certain this is in the minutes from the F2F, a WUA needs to be able to instantiate multiple discreet instances of a widget, and needs to be able to distinguish them. the instances need to be distinct. Whether distinct instances should be able to enumerate and connect is not currently decided but for future improvement the scheme shouldn't prohibit this.
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Dec 6, 2008, at 9:58 AM, timeless wrote: On Fri, Dec 5, 2008 at 3:42 PM, Jonathan Rees [EMAIL PROTECTED] wrote: I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz i'm 99% certain this is in the minutes from the F2F, a WUA needs to be able to instantiate multiple discreet instances of a widget, and needs to be able to distinguish them. the instances need to be distinct. Whether distinct instances should be able to enumerate and connect is not currently decided but for future improvement the scheme shouldn't prohibit this. OK, if you need to distinguish the instances, give each a different tag: URI. You could identify the instance using an entropy-generated bit string, and maintain a mapping from bit string to instance. Or, if you have some other way to designate an entity internally, such as process id + index into a table, you could put that information, or a hash of it, into the tag: URI, in combination with entropy or some other hash if you like. I hope it is clear that I'm not specifying a particular way to choose the tag: URI, as I can't because I don't know details of your requirements or architecture (sorry). The question was: Using tag: you can do just about anything you want in the way of exposing and/or hiding information (probably ten or twenty options here depending on what information and entropy feeds in and how/when/ whether it's hashed), so why not use tag: ? In other words, if you think file: and http: have problems, the tag: URI scheme might provide a way out that does not require registering a new URI scheme. You still have a design problem (which you would have regardless), but at least you avoid one source of unpleasantness. Jonathan
Re: Wheel events
On 12/06/2008 02:32 AM, Travis Leithead wrote: Why does a mouse-wheel event need to include information about scrolling? Because OS (OSX at least) generates different kinds of events for different kinds of user interactions. Pixel scrolling when user scrolls only a bit, line scrolling when some larger amount is scrolled. I thought we already have specified a scroll event for this purpose? That happens after something on the page has been scrolled. Mouse wheel events are dispatched when user uses the wheel (for scrolling, or zooming or whatever the webapps want to do with wheel events.) It seems to me that the act of scrolling is merely related to the default action of wheel event (which, according to the wiki, specifies a default action of mousewheel (which itself could cause the default action of dispatching a scroll event). After re-reading the proposal on the Wiki, Wiki doesn't have the version I prefer. I'm convinced that we're making the whole wheelevent much too complicated. It's a wheel. The user rolls it. If the event starts to make too many assumptions about what the intended purpose of the roll is (e.g., pixel scrolling, line scrolling, page scrolling, page navigations, etc.) Pixel scrolling / line scrolling aren't intended purpose. They are describing the data browser gets from the operating system. About collapsing deltaX/Y/Z... one of the reasons we like the three vs. 1 is that together they specify a coordinate in 3-dimensional space; a vector that could be used in the future to cleanly move/pan in 3-dimensional space. If we went with .delta/.detail then the same application would suffer from the jaggies when responding to events sequentially. Good point. So one event which contains .deltaX/Y/Z. -Olli -Travis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olli Pettay Sent: Wednesday, October 01, 2008 4:46 AM To: public-webapps@w3.org Subject: Re: Wheel events Hi all, So version 3 got implemented in Mozilla, but in a bit modified way. There are separate events for line scrolling and pixel scrolling. In Mozilla the old DOMMouseScroll and a new, currently named MozMousePixelScroll, but in this message I call those just lineScroll and pixelScroll: - If there is only pixel scrolling, dispatch a pixelScroll event and scroll the current scrollable area unless .preventDefault() was called. - If there is only line scrolling, dispatch a lineScroll event, and dispatch also a pixel scroll event if it is possible to convert line data to pixel data. Scroll the scrollable area if .preventDefault() wasn't called on either of those events. - If there is both line scrolling and pixel scrolling, dispatch line scroll and pixelScroll and scroll the scrollable are unless preventDefault was called on either of those events. This way applications which want to handle pixel scrolling, can always get those events, and this doesn't break existing applications which only want to handle line scrolling (Google maps etc.). Dispatching only pixel scroll events wouldn't work because many applications don't want to handle small scrolling and there isn't always a good way to convert pixel scroll data to line scroll data. So to help web apps, better to have separate events. Note, currently in Mozilla there are separate wheel events for horizontal and vertical scrolling and events have .axis property. So http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-eventgroupings-wheelevents could be modified a bit. The event name tells whether scrolling is line scrolling or pixel scrolling and it also specifies what .delta means. If we want separate events for different axis, we could remove .deltaX/Y/Z and have just one .delta and use .detail for axis and have constants X_AXIS, Y_AXIS, Z_AXIS. This way we could later, if wanted, add support for pageScrolling and whatever and also add support for any new axis or other features. To make this work with existing implementations which have support for mousewheel event, the spec could say something like: A default action of user agent generated event objects of this type causes implementations to dispatch a mousewheel event iff it supports that event type and WheelEvent.type is lineScroll, WheelEvent.delta is non-zero and WheelEvent.detail is WheelEvent.Y_AXIS. I'm not sure what could be the right names for the events. It is perhaps too easy to confuse 'lineScroll' and 'pixelScroll' with totally different kind of event 'scroll'. Not so much related to the new WheelEvent: Note, if mousewheel event must be defined in DOM 3 Events (as a legacy event, not obligatory to implement), there is still need to define what its .wheelDelta means, because that doesn't tell how many lines or how many pixels to scroll. -Olli Olli Pettay wrote: Hi all, there has been some discussion about how wheel event should work, and what kind of
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hi Jonathan, On Sat, Dec 6, 2008 at 3:21 PM, Jonathan Rees [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 9:58 AM, timeless wrote: On Fri, Dec 5, 2008 at 3:42 PM, Jonathan Rees [EMAIL PROTECTED] wrote: I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz i'm 99% certain this is in the minutes from the F2F, a WUA needs to be able to instantiate multiple discreet instances of a widget, and needs to be able to distinguish them. the instances need to be distinct. Whether distinct instances should be able to enumerate and connect is not currently decided but for future improvement the scheme shouldn't prohibit this. OK, if you need to distinguish the instances, give each a different tag: URI. You could identify the instance using an entropy-generated bit string, and maintain a mapping from bit string to instance. Or, if you have some other way to designate an entity internally, such as process id + index into a table, you could put that information, or a hash of it, into the tag: URI, in combination with entropy or some other hash if you like. I hope it is clear that I'm not specifying a particular way to choose the tag: URI, as I can't because I don't know details of your requirements or architecture (sorry). The question was: Using tag: you can do just about anything you want in the way of exposing and/or hiding information (probably ten or twenty options here depending on what information and entropy feeds in and how/when/whether it's hashed), so why not use tag: ? I certainly seems like a plausible solution, as it does, on the surface, give us all the aspects that we require: 1. per-instance identity. 2. a path to files inside the package. 3. extensibility through using comas in the authority part (with the ability to identify a domain of origin). 4. no conflict with existing implemented schemes in browsers. However, reading [1] there are some outstanding issues wrt compatibility with IRIs. It's unclear if that was resolved or not in rfc4151. In other words, if you think file: and http: have problems, the tag: URI scheme might provide a way out that does not require registering a new URI scheme. You still have a design problem (which you would have regardless), but at least you avoid one source of unpleasantness. Agreed. [1] http://www.taguri.org/ -- Marcos Caceres http://datadriven.com.au
Re: Call for Consensus - Selectors Last Call
Gregory Reimer (the author of reglib) points out that Element.matchesSelector would be useful for event delegation. See http://blogs.sun.com/greimer/entry/opera_10_will_suport_selector It would also neatly tie in with NodeFilter in DOM-Traversal, facilitating something like a live querySelectorAll() during document load. Unfortunately I had assumed it was in the spec. I've looked now and seen that it wasn't considered due to a lack of presented use cases, which seems non-sensical. matchesSelector() is to querySelectorAll() as tagName is to getElementsByTagName(). The only reason for it not to be in the spec is if it is harmful. The only complication I can see is supporting the :scope pseudo-attribute. cheers, Sean Charles McCathieNevile wrote: Hi, Lachy thinks the latest editor's draft[1] is ready for Last Call, after responding to all the comments from last time (and removing the NSResolver). The disposition of comments[2] explains what happened to those comments. So this is a call for Consensus to publish the Editor's Draft [1] of the Selectors API spec as a Last Call. Please respond before Monday November 10. As always, silence is taken as assent but an explicit response is preferred. Opera supports publication of this draft as a Last Call. [1] http://dev.w3.org/2006/webapi/selectors-api/ [2] http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html cheers Chaals
[widgets] the widget spec needs you! Volunteer to help with references
I'm wondering if anyone out there might want to help me out by completing the references section of the widget packaging spec [1]? This would greatly help me to have the spec ready for publication by the 18th. It's not too much work (2 hours max), one would just needs to check that all references are up to date, update a few and add any references that are missing or incomplete. Hope someone will be kind enough to help me out! Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets/ -- Marcos Caceres http://datadriven.com.au
Re: Call for Consensus - Selectors Last Call
Sean Hogan wrote: Gregory Reimer (the author of reglib) points out that Element.matchesSelector would be useful for event delegation. See http://blogs.sun.com/greimer/entry/opera_10_will_suport_selector It would also neatly tie in with NodeFilter in DOM-Traversal, facilitating something like a live querySelectorAll() during document load. It would be useful if you could elaborate upon those use cases. Unfortunately I had assumed it was in the spec. I've looked now and seen that it wasn't considered due to a lack of presented use cases, which seems non-sensical. How is that nonsensical? Without having use cases presented, it's hard to justify the feature and even harder to make sure it's designed in the most optimal way for those use cases. The only reason for it not to be in the spec is if it is harmful. AFAIK, no-one said it was harmful. It is too late for this proposal to be added to this version of the spec, but it will be considered for the next version. The only complication I can see is supporting the :scope pseudo-attribute. Assuming the CSSWG includes the :scope proposal in the next version of Selectors, and if there are use cases for which :scope would be useful in a matchesSelector() function, we can investigate solutions to address the issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[widgets] Comments on reference
Dear, Please find some comments on the following spec : http://dev.w3.org/2006/waf/widgets/ (of the 6 december 2008) It is relative to reference and might be incomplete Regards, Mohamed ZERGAOUI == Reference == [[CSS21]] is now a CR from July 2007 ; please fix the encoding problem in Hakon and Tantek names Fix RFC2119 to [[RFC2119]] Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, S. Bradner. IETF, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt Fix RFC2822 to [[RFC2822]] Internet Message Format, RFC 2822, P. Resnick. IETF, April 2001. Available at http://www.ietf.org/rfc/rfc2822.txt Fix RFC3986 to [[RFC3986]] Uniform Resource Identifier (URI): Generic Syntax, RFC 3986, T. Berners-Lee, R. Fielding, L. Masinter. IETF, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt Fix RFC3987 to [[RFC3987]] Internationalized Resource Identifiers (IRIs), RFC 3987, M. Duerst, M. Suignard. IETF, January 2005. Available at http://www.ietf.org/rfc/rfc3987.txt Fix UUID to [[UUID]] A Universally Unique IDentifier (UUID) URN Namespace, RFC 4122, P. Leach, M. Mealling, R. Salz. IETF, July 2005. Available at http://www.ietf.org/rfc/rfc4122.txt For UUID, also remove the extra space (%20) in the link at the end Fix UTF-8 to [[UTF-8]] UTF-8, a transformation format of ISO 10646, RFC 3629, F. Yergeau. IETF, November 2003. Available at http://www.ietf.org/rfc/rfc3629.txt (and remove the reference to RFC3629) Fix Widgets-Reqs to [[Widgets-Reqs]] Widgets 1.0 Requirements, M. Caceres, Editors. W3C, September 2008. Fix XML to [[XML]] Extensible Markup Language (XML) 1.0 (Fifth Edition). T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau. W3C, November 2008. Fix XMLDsig to [[XMLDsig]] XML-Signature Syntax and Processing (Second Edition). Mark Bartel, John Boyer, Barb Fox, Brian LaMacchia and Ed Simon, authors. Donald Eastlake, Joseph Reagle, David Solo, Frederick Hirsch and Thomas Roessler, editors. W3C, June 2008. Fix XHTML to [XHTML] XHTML 1.0: The Extensible HyperText Markup Language (Second Edition), S. Pemberton et al.. W3C, August 2002. Available at: http://www.w3.org/TR/2002/REC-xhtml1-20020801 -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
[widgets] Typos
Dear, Please find some comments on the following spec : http://dev.w3.org/2006/waf/widgets/ (of the 6 december 2008) Regards, Mohamed ZERGAOUI == Typos == s/Lanaguage-Tag/Language-Tag/ s/expresssion/expression/ s/fobar.png/foobar.png/ s/langauge/language/ -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Re: [widgets] Typos
Hi Mohamed, On Sat, Dec 6, 2008 at 11:53 PM, Innovimax SARL [EMAIL PROTECTED] wrote: Dear, Please find some comments on the following spec : http://dev.w3.org/2006/waf/widgets/ (of the 6 december 2008) Regards, Mohamed ZERGAOUI == Typos == s/Lanaguage-Tag/Language-Tag/ fixed. s/expresssion/expression/ fixed. s/fobar.png/foobar.png/ fixed. s/langauge/language/ fixed. Thanks again. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Unicode Zip Paths (fully decomposed canonical form?)
At 09:31 08/12/06, Marcos Caceres wrote: Hi, I'm trying to put the final touches on the zip section of the widget packaging spec [1] before we go to LC by the 10th and I've run into an i18n problem related to character encodings. I' wondering if anyone would be kind enough to give me some guidance as to what is going on, encoding wise, with in MacOS with regards to the encoding of file names in Zip Files? When I create a zip file with one file entry called nフ\xA5, inside the zip file, the file name gets decomposed to the following (hex) byte sequence: nフ\xA5- 0x6E 0xCC My mailer has problems with UTF-8, but my guess is that you are using n-with-tilde. In UTF-8 and NFD, that would be Ux6E 0xCC 0x83, so one explanation is that some data was dropped (and one way to explain that would be that the implementation was confused about characters vs. bytes). 6E is the letter n in Unicode, so there is obviously some decomposition going on there. But 0xCC in Unicode maps to テ\xB7(LATIN CAPITAL LETTER I WITH GRAVE)? So I'm not sure what encoding the zip file is using. A single 0xCC byte doesn't map to anything in any Unicode encoding form. The reason I ask is because I'm not sure what to put into the widget spec in regards to recommending the use of canonical decomposition for unicode file names. Or even if that is a good idea!? Should I put the following into the spec?: It is recommended that the file name field be encoded using [UTF-8] in fully decomposed canonical form. No. Although the Mac file system(s?) use (a variant of) NFD, for file names, other operating systems (Windows, Linux,...) don't. If you want to specify a normalization form, NFC is closer to what the majority does. OR just: It is recommended that the file name field be encoded using [UTF-8]. Realistically, that's about what you can ask for. And that should be enough if the main concern is to match file names from the same source. If you need to assure that file names from different sources can be matched, then proscribing NFC is the best thing to do, but you may have difficulties to get your developpers following your spec. This seems important for when I go form MacOS to any other platform as file names get all mangled when files are extracted on any other platform. We obviously don't want that to happen so widget engines need to be prepared to deal with these encoding issues. I looked at the Zip spec [2], but I don't see any real guidance with regards to this. However, for those who know more about encoding, it would be helpful if you could also take a look at the Zip spec. It looks to me that you should say that bit 11 should be set and UTF-8 should be used for file name and comment, unless there are a significant number of zip toolkits that don't allow that. The spec contains the following: The 0x0008 Extra Field storage may be used with either setting for general purpose bit 11. Examples of the intended usage for this field is to store whether modified-UTF-8 (JAVA) is used, or UTF-8-MAC. modified-UTF-8 means that surrogates are directly converted into 3-byte UTF-8(-like) sequences instead of converting surrogate pairs into 4-byte UTF-8. UTF-8-MAC is UTF-8, mainly NFD, but NFC for Korean. The specification of the 0x0008 extra field... is extremely vague, not useful at all. Regards,Martin. Any help would be greatly appreciated, Marcos [1] http://dev.w3.org/2006/waf/widgets/#zip-relative [2] http://www.pkware.com/documents/casestudies/APPNOTE.TXT -- Marcos Caceres http://datadriven.com.au #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
