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 information it should expose. The current DOM 3 Events (editor) draft has the legacy mousewheel event and also the new wheel event which has deltaX/Y/Z. The problem is that what delta means (especially in the new wheel event). Operating systems create events which may contain several kinds of information - how many lines to scroll but also how may pixels. Currently Safari seems to support also pixel scrolling, but doesn't dispatch events for events which don't have line scrolling = 1. And that causes problems like http://mozilla.pettay.fi/moztests/pixelscrolling.mov Web applications should be able handle that situation and IMO should know what kind of wheel event just happened. So either deltaX/Y/Z (I'm talking about the new event here, not the legacy event) should be always in pixel units (or fragment of such) or the event should somehow have information about the units. In latter the case there is the problem that same system event may contain both pixel and line information. So either two DOM events should be dispatch or one event should be able to carry information about the different kinds of units. But if the event contains only pixel information, web app can't know how many pixels mean a line-scroll. And that is valuable when trying to make web app to act like a native application. So there are (at least) 5 options 1. only pixel delta - Web app can't know what delta value means a line scroll 2. events with both line and pixel scroll information (maybe also page scroll etc?) - Web apps would get all the needed information in one event, but the event interface would probably look pretty ugly 3. separate events for pixel scrolls and line scrolls - Web app can't know whether user did one or two gestures 4. linked events; if the native event contains both line and pixel data, dispatch one event for line delta and one for pixel data but add some attribute to the event interface which links these events together, something like readonly attribute WheelEvent
Submitted Documents to DOM 3 WIKI
Hi DOM 3 and Web Apps Group: Submitted some documents (tests and catalog file) to the DOM 3 WIKI page. Feel free to comment. Documents are at: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/tests/framework/ Thanks, Carmelo
Re: Some comments on Widgets 1.0: Packaging and Configuration
Hi Dom, On Tue, Sep 16, 2008 at 10:20 AM, Dominique Hazael-Massieux [EMAIL PROTECTED] wrote: As I started looking at the testability of the Widgets 1.0: Packaging and Configuration specification, I spotted a few things that I thought I would mention (based on the CVS editors's draft [1]): * the relax NG schema doesn't include a definition for the update and requires elements; it doesn't include the declaration of the mode attribute on the root element, of the img attribute on the author element, of the width, height and alt attribute on the icon element, of the files attribute on the access element As you know, the schema has now been updated (but will soon be out of date again). However, I don't want to waste David's time continuously updating the schema until the text in the spec has stabilized. * 6.10 When the access element is absent, a widget user agent must deny access to networked resources and to plugins, and presumably to the file system as well; instead of separate boolean attributes, what about having these as a single token-based attribute (e.g. access=network plugins) You raise a good point. We are considering dumping the access element and using feature for everything. So, we would have something like: widget ... feature id=http://www.w3.org/widgets/network; / feature id=http://www.w3.org/widgets/plugins; / /widget We will be debating this model over the next few weeks. * some of the green notes highlight interoperability problems - this sounds like material for conformance requirements rather than just notes. We have debated at length in the past about whether these notes should be normative or not (I'm sorry, I can't provide you with a reference/pointer right now), we reached a resolution that we would leave them as notes for now. If upon building a reference implementation (or the test suite) we find that these in fact are going to cause interop issues, then we can easily change them. * Author requirements probably ought to called Authoring requirements since you're not trying to define conformance for authors but for what they author You are probably right, but we are keeping this consistent with HTML5 (which currently uses Author requirements). * there seems to be well-known filenames that have special semantics attached in the widgets specs (at least config.xml, signature.xml, the locale directories); the list of reserved filenames sounds like something that should be explicitly documented in the packaging spec; in particular, it should probably be recommended not to use 2 and 3 letters names for directories at the root of the archive (trivia: which in the followings is not a language code: cat, bin, bak, iii, inc, lol, map, oss, run, sux, tel?) I have added a section in the spec called Reserved filenames and created a table that lists what names are reserved and for what purpose. I also added a note warning authors about the use of 2 to 3 letter file names. * If the access element is used, a full URI must be given - I don't think the notion of full URI is defined anywhere Yep. I need to go through the whole spec and fix up all the URI related stuff. This is a big job, which I am currently working on. * the references section don't distinguish normative from informative references; fixed. Prefixed References with the word Normative. Will add an Informative References section later if one is needed. * there seems to be a normative reference to HTML 5 in Rules for Identifying the Content Type of a Start File, but HTML 5 is not in the list of references; also, having a normative dependency on HTML5 means the spec won't be able to go to REC until HTML5 does Understood. We will look at ways of minimizing our dependencies on HTML5. However, I personally don't see it as a problem if this spec sits I'm sorry these comments are a bit randomish, but I thought I would send them while I looked at the spec. No, that's great! thank you! -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
Re: Submitted Documents to DOM 3 WIKI
So I think those NIST_ prefixes should be vendor_ in js. That way any vendor could hopefully easily integrate tests to their system by providing vendor_ functions. Those could be called something else too, sure. Maybe integration_point_XXX or hopefully something shorter. Is there a reason to have NIST_ prefix in testcase files? I couldn't get the testcases to work. Some JS error in error console. -Olli Carmelo Montanez wrote: Hi DOM 3 and Web Apps Group: Submitted some documents (tests and catalog file) to the DOM 3 WIKI page. Feel free to comment. Documents are at: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/tests/framework/ Thanks, Carmelo
