Re: Mouse Lock
I recently saw what appeared to be the AG group complaining that the html WG didn't care to specify Accessibility bits even though W3 policy requires considering both internationalization and accessibility. I know that we like to innovate and let everyone else backfill the missing pieces later, but perhaps that isn't a wonderful approach. On the topic of devices without keyboards, I picked up a MeeGo 1.2 tablet in May. It has no keyboard, and no useful edges. It doesn't have a right click feature, and it's perfectly reasonable for a web application to demand to detect gestures and long presses. It has one real button: Power - which turns the device completely off, after which it takes an incredibly long time to boot. Not to mention that a user might not appreciate losing any other unsaved data. It does have rotation detection (which barely works), again, something which web applications are free to want to handle themselves. It also has single sensor which is incredibly quirky and easy to misplace or overlook which barely functions for task switching. You could claim that it's sufficient as a way out, but it makes me uncomfortable. Plus there's no way for a UI to explain to the user how to press it; it isn't usefully labeled. On 6/23/11, Charles Pritchard ch...@jumis.com wrote: timeless, I agree, it'd be nice to know. I'd really like to see this put toward the AG (Accessibility Guidelines) people, as they're the ones who follow this kind of things. It's absolutely the case that a user needs an ability to escape from the mouse lock context, and to have one which lies outside of any processing handled by the untrusted scripting environment. The *AG practices are always the first to document these needs. Requiring keyboard for something that locks a mouse is not acceptable; a user must be able to release their pointer device without requiring a keyboard. The same applies for keyboard locks. Assistive technologies (AT) have their place in this, and can give some leeway to the user agent (UA), as long as the UA provides enough semantics to allow the AT to handle this kind of work. Again, these issues are always brought up by AG documents. I'll give you two examples for pointer device escape: 1) Right click/context menu; always works. 2) Click and hold; X number of seconds could pop up a context menu. 3) extreme coordinate and hold; x seconds on an extreme coordinate pops up a menu. On the extreme-coordinate; an input device which may only signal changes in x/y positioning may still be used to activate UA menus. Developers are by all practical purposes, required by existing standards and technologies, to leave space on the edges of the screen. Though this is mostly related to safe areas on televisions, the principle applies beyond that, and is de facto required by existing full screen semantics [wherein the top extremes create a dialog to escape]. So, by luck of history; extreme coordinates are encouraged and in practice, required as a means of escaping mouse lock. There are certainly cases where extreme coordinates could be useful to an application. Those corner cases will have to be thought about, by those implementing such apps. All the best, -Charles On 6/23/2011 6:29 PM, timeless wrote: And what if the device in question is just a touchscreen with no keyboard, mouse or hardware buttons? On 6/20/11, Tab Atkins Jr.jackalm...@gmail.com wrote: On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettayolli.pet...@helsinki.fi wrote: On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote: The use-case is non-fullscreen games and similar, where you'd prefer to lock the mouse as soon as the user clicks into the game. Minecraft is the first example that pops into my head that works like this - it's windowed, and mouselocks you as soon as you click at it. And how would user unlock when some evil sites locks the mouse? Could you give some concrete example about It's probably also useful to instruct the user how to release the lock. I'm assuming that the browser reserves some logical key (like Esc) for releasing things like this, and communicates this in the overlay message. -- Sent from my mobile device
Re: [widget] technology/specification name
On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchard ch...@jumis.com wrote: One issue which comes up is that widget is also used in ARIA to describe ui elements. I suspect we'll see apps used ubiquitously; widget seems to e reserved to early experiments in linked apps; apps via iframe. Like many on this thread, I don't have a strong objection against the name. I rather appreciate the thread, it's bringing out more distinctions as to what we're talking about and targeting. Lets just change it to Packaged Web Apps. -- Marcos Caceres http://datadriven.com.au
RE: [widget] technology/specification name
The problem with widgets is that the name conflicts (or is a bit different angle) with the UI widgets (or controls) that are also in use (e.g. wxWidgets, GTK widgets etc.). We could invent some other name (WAF, WebApplicationPackaging etc. as people quote already), but ... On the other hand many people already talk W3C widgets. W3C widgets as the spec name is used in many other specs, not only W3C ones. Thus I suggest keeping the name as it is. Changing it now could confuse the industry even more and will not help, I think. BTW: There are also NetFront Widgets :) Thanks, Marcin -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Scott Wilson Sent: Thursday, June 23, 2011 8:18 PM To: Dave Raggett Cc: Karl Dubost; public-webapps@w3.org; Bruce Lawson Subject: Re: [widget] technology/specification name Part of the issue is that its a fairly generic technology that can be applied to areas including: - Browser extensions - Installable web apps - Desktop widgets - Site gadgets - TV/STB widgets - Mobile webapps I think the name widgets came from the heritage of Opera Widgets, Nokia Widgets, Apple Dashboard Widgets (etc). Personally I don't think its all that bad as a name, but I don't feel especially attached to it either. If there is a better option, lets go for it. On the other hand, if there are barriers to adoption other than branding, lets address them. Unfortunately, I suspect a fair amount of it is just NIH syndrome. S On 23 Jun 2011, at 17:26, Dave Raggett wrote: In the webinos project [1] we are using installed vs hosted web apps. On 23/06/11 15:58, Karl Dubost wrote: I do not want to start a name bikeshedding. The name doesn't bother me so far, but I have seen that comment again and again. On Thu, 23 Jun 2011 14:06:24 GMT In Bruce Lawson's personal site : Installable web apps and interoperability At http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperabilit y/ Installable apps (in W3C parlance, Widgets - which is a terrible name) allow authors to write apps using HTML(5), CSS, JavaScript, SVG etc, and package them up into a glorified Zip file with some configuration details which can then be installed on a computer. It seems that extensions or addons would be more cognitively connected with Web developers. y'know, so terrible is the W3C Widgets name that I didn't even think it referred to the same thing as Chrome's apps, et al. - http://twitter.com/nevali/status/83866541388603392 [1] http://webinos.org/ -- Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: [widget] technology/specification name
Marcos Caceres wrote: On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchardch...@jumis.com wrote: One issue which comes up is that widget is also used in ARIA to describe ui elements. I suspect we'll see apps used ubiquitously; widget seems to e reserved to early experiments in linked apps; apps via iframe. Like many on this thread, I don't have a strong objection against the name. I rather appreciate the thread, it's bringing out more distinctions as to what we're talking about and targeting. Lets just change it to Packaged Web Apps. Agreed. I'd couple that with the short-hand term 'web package'.
[Bug 13035] on http://www.w3.org/TR/css-print/#s.8.4 It seems this line: br { content: \A } is missing :before If I am wrong please update http://www.w3.org/TR/CSS21/generate.html#propdef-co
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13035 Ms2ger ms2...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ms2...@gmail.com Component|WebSocket API (editor: Ian |Issues with the CSS level 2 |Hickson)|revision 1 specification Resolution||INVALID AssignedTo|i...@hixie.ch|b...@w3.org Product|WebAppsWG |CSS 2.1 QAContact|member-webapi-...@w3.org| --- Comment #2 from Ms2ger ms2...@gmail.com 2011-06-24 09:13:37 UTC --- CSS3-content indeed allows this. Since this has nothing to do with HTML or WebApps specs, I'm going to move it to the CSSWG's bugzilla product. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [widget] technology/specification name
On Fri, Jun 24, 2011 at 11:08 AM, Rich Tibbett ri...@opera.com wrote: Marcos Caceres wrote: On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchardch...@jumis.com wrote: One issue which comes up is that widget is also used in ARIA to describe ui elements. I suspect we'll see apps used ubiquitously; widget seems to e reserved to early experiments in linked apps; apps via iframe. Like many on this thread, I don't have a strong objection against the name. I rather appreciate the thread, it's bringing out more distinctions as to what we're talking about and targeting. Lets just change it to Packaged Web Apps. Agreed. I'd couple that with the short-hand term 'web package'. We would just be changing the title of the documents. It's not like we are changing the widget element or the widget interface. This is just a repaint of the bikeshed from off white to mother of perl. I think this is probably the 1000th time we have had this naming discussion over the last 5 years. Hopefully, if we do change stuff as we go to REC, it will be the last. -- Marcos Caceres http://datadriven.com.au
Re: [widget] technology/specification name
On Jun/24/2011 4:50 AM, ext Marcin Hanclik wrote: Changing it now could confuse the industry even more and will not help, I think. Agreed, and in the abscence of any new and overwhelmingly compelling new information, I will object to any name change. -AB
Re: [widget] technology/specification name
On 24 Jun 2011, at 10:41, Marcos Caceres wrote: On Fri, Jun 24, 2011 at 11:08 AM, Rich Tibbett ri...@opera.com wrote: Marcos Caceres wrote: On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchardch...@jumis.com wrote: One issue which comes up is that widget is also used in ARIA to describe ui elements. I suspect we'll see apps used ubiquitously; widget seems to e reserved to early experiments in linked apps; apps via iframe. Like many on this thread, I don't have a strong objection against the name. I rather appreciate the thread, it's bringing out more distinctions as to what we're talking about and targeting. Lets just change it to Packaged Web Apps. Agreed. I'd couple that with the short-hand term 'web package'. We would just be changing the title of the documents. It's not like we are changing the widget element or the widget interface. This is just a repaint of the bikeshed from off white to mother of perl. I think this is probably the 1000th time we have had this naming discussion over the last 5 years. Hopefully, if we do change stuff as we go to REC, it will be the last. OK, that sounds a bit confusing. Rather than change the Widgets: PC spec, how about create a new Note on Packaged Web Apps that references the W3C Widgets family of specifications as the recommended set of specifications for realizing the various packaged web app UCs? That way we can talk about W3C Packaged Web Apps without invalidating any references to the individual Widget specifications. (This is sort of like sticking a mother-of-pearl facade onto the front of the bikeshed rather than repainting it) -- Marcos Caceres http://datadriven.com.au
Re: [widget] technology/specification name
On Fri, Jun 24, 2011 at 12:44 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: On 24 Jun 2011, at 10:41, Marcos Caceres wrote: On Fri, Jun 24, 2011 at 11:08 AM, Rich Tibbett ri...@opera.com wrote: Marcos Caceres wrote: On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchardch...@jumis.com wrote: One issue which comes up is that widget is also used in ARIA to describe ui elements. I suspect we'll see apps used ubiquitously; widget seems to e reserved to early experiments in linked apps; apps via iframe. Like many on this thread, I don't have a strong objection against the name. I rather appreciate the thread, it's bringing out more distinctions as to what we're talking about and targeting. Lets just change it to Packaged Web Apps. Agreed. I'd couple that with the short-hand term 'web package'. We would just be changing the title of the documents. It's not like we are changing the widget element or the widget interface. This is just a repaint of the bikeshed from off white to mother of perl. I think this is probably the 1000th time we have had this naming discussion over the last 5 years. Hopefully, if we do change stuff as we go to REC, it will be the last. OK, that sounds a bit confusing. Rather than change the Widgets: PC spec, how about create a new Note on Packaged Web Apps that references the W3C Widgets family of specifications as the recommended set of specifications for realizing the various packaged web app UCs? That way we can talk about W3C Packaged Web Apps without invalidating any references to the individual Widget specifications. (This is sort of like sticking a mother-of-pearl facade onto the front of the bikeshed rather than repainting it) That WFM. We always talked about doing a preface architecture document that explained how all the bits work together (we can probably take some text from the old Landscape doc). I don't see it being more than a page or two. -- Marcos Caceres http://datadriven.com.au
[widgets] VMMF, Meta Viewport, and Width and Height.
The View Mode Media Feature is commonly used with the device adaption spec [1]. What would be quite useful would be a way of making meta viewport respect the widget's width and height (as declared in the widgets config.xml). My proposal would be to introduce widget-width and widget-height to be used as follows: meta name=viewport content=height=widget-height,width=widget-width The use case: better control of virtual viewport so it always matches the desired size of the widget author. [1] http://dev.w3.org/csswg/css-device-adapt/ -- Marcos Caceres http://datadriven.com.au
[eventsource] Is Server-Sent Events ready for LC? ; deadline July 1
Hixie, All, Ian responded [1] to the last set of Server-Sent Events comments I had noted, and Bugzilla now reports Zarro Boogs [2] for this spec (11835/Fixed, 11836/WontFix, 12411/Fixed, 12883/WontFix). As such, this raises the question if the spec is ready for Last Call Working Draft publication (see [3] for information about what it means for the spec to be LC ready). If you have any feedback on this question, please send it by July 1. The latest Editor's Draft is: http://dev.w3.org/html5/eventsource/ -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1079.html [2] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=product=WebAppsWGcomponent=Server-Sent+Events+%28editor%3A+Ian+Hickson%29longdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailtype1=substringemail1=emailtype2=substringemail2=bug_id_type=anyexactbug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= [3] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0695.html
[Bug 13042] New: Define Event.timeStamp
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13042 Summary: Define Event.timeStamp Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM Range AssignedTo: dave.n...@w3.org ReportedBy: ms2...@gmail.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13042] Define Event.timeStamp
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13042 Anne ann...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Anne ann...@opera.com 2011-06-24 14:48:38 UTC --- https://bitbucket.org/ms2ger/dom-core/changeset/e1e6c0d02fae -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Mouse Lock
And what if the device in question is just a touchscreen with no keyboard, mouse or hardware buttons? From the draft spec: Touch devices may also choose to reserve a portion of the touch interface for an unlock gesture. Mouse lock seems irrelevant on a touchscreen... I've added clarification to the draft spec in the use case section, Touch screen device input All the application use cases are relevant on touch screen devices as well. A user should be permitted to make large gestures that are interpreted as movement deltas, without concern over the absolute positions of the touch points. Other UI elements from the user agent and system should be suppressed while under mouse lock. Absolute position of touch points should always be available, unlike mouse input where the concept of the cursor is removed. On a touch screen the absolute positions will always be relevant. Devices with no keyboard must provide escape from lock via either hard buttons or reserved screen space for an escape gesture.
Re: Mouse Lock
On Fri, Jun 24, 2011 at 12:00 PM, Vincent Scheib sch...@google.com wrote: I've added clarification to the draft spec in the use case section, Touch screen device input All the application use cases are relevant on touch screen devices as well. A user should be permitted to make large gestures that are interpreted as movement deltas, without concern over the absolute positions of the touch points. Other UI elements from the user agent and system should be suppressed while under mouse lock. Absolute position of touch points should always be available, unlike mouse input where the concept of the cursor is removed. On a touch screen the absolute positions will always be relevant. I don't believe it makes sense to have a mouse lock mode on a touchscreen which causes touching UI elements to instead be sent as mouse events to the window. That would be very confusing. Touching in-window and then dragging out-of-window on a touchscreen is useful, but you should be able to do that with regular mouse (or touch) events already. It can be used in fullscreen mode, where there are no UI elements, but in that case it's not necessary--you can just use mouse events directly. The main reason for mouse lock--the issue of the mouse being moved beyond the edge of the screen--doesn't apply to touchscreens (you can't touch outside the screen). -- Glenn Maynard
Re: Mouse Lock
On Wed, Jun 22, 2011 at 5:20 AM, Simon Pieters sim...@opera.com wrote: On Tue, 21 Jun 2011 00:43:52 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: There's a middle ground here: you can lock the mouse to the window, but not completely. That is, if the user moves the mouse to the edge, it remains inside, but if they move it fast enough it escapes. This is enough to stop the window from accidentally losing focus when you're trying to click on something near the edge of the screen, but it lets you easily get outside the window if you actually want to. IIRC, Wine does this in windowed mode. Of course, it might not be suitable for games that want to hide the cursor, like FPSes, but it might be a possible fallback if the browser doesn't trust the site enough for whatever reason to let it fully lock the mouse. This seems weird. When would you use this middle ground? Would users understand it? Also, as you say, totally inappropriate for FPS games. Well, the time when I noticed it in Wine is when I was running some kind of isometric RPG or strategy game or something, and had to run in windowed mode because it was buggy in fullscreen. In these games you have a map, and you scroll around on the map by moving the mouse to the edge of the screen. You do have a visible mouse cursor, but you don't want it to leave the window because then you have to position it pixel-perfect to get the window to scroll, instead of just slamming it against the side. Of course, you could just trap the mouse for real in this case as well. In practice that might be fine. Also, it occurs to me that the author could always make the cursor transparent if they wanted to confuse the user, and the user might not think to move it quicker to get it out even if they could see it (although it's an intuitive thing to try). So it might not be a security advantage at all relative to actually locking the cursor. But this does highlight the fact that we probably want to support mouse-locking that doesn't hide the cursor also, for this kind of mouse-based scrolling. In that case, though, the coordinates and mouse events should behave just like regular. If the user presses the cursor up against the side of the screen and it visually stops moving, no mousemove events should be fired even if the user does keep moving the actual mouse. The application would then want to check the cursor's location instead of listening for events.
[Bug 13020] No user agent will implement the storage mutex so this passage does not reflect reality
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13020 Ms2ger ms2...@gmail.com changed: What|Removed |Added CC||i...@hixie.ch, ||ms2...@gmail.com, ||public-webapps@w3.org Component|HTML5 spec (editor: Ian |Web Storage (editor: Ian |Hickson)|Hickson) Product|HTML WG |WebAppsWG QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Thu, Jun 23, 2011 at 4:52 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 21 Jun 2011, Ian Hickson wrote: How about we just make postMessage() take the object to clone in the first argument, an array of objects to transfer in the second; on the other side, the author receives the object cloned, with anything listed in the array and in the structured data being transferred instead of cloned, and, in addition, in the event.ports array, a list of the ports that were given in the transfer array. This has the advantage of being completely backwards-compatible. So for example, on the sending side: postMessage(['copied', copiedArrayBuffer, transferredArrayBuffer, transferredPort1], // could be an object too [transferredArrayBuffer, transferredPort1, transferredPort2]); ...on the receiving side, the event has data == ['copied', newCopiedArrayBuffer, newTransferredArrayBuffer, newTransferredPort1]; ports == [newTransferredPort1, newTransferredPort2]; It's not going to win any design awards, but I think that boat has sailed for this particular API anyway, given the contraints we're operating under. Since no serious problems were raised with this and it seems to address all the constraints, I've now specced this. One edge case that wasn't mentioned above is what happens when a non-port Transferable object is in the second list but not the first. I defined it such that it still gets cloned (and thus the original is neutered), but it is then discarded. (That definition more or less fell out of the way one'd have to implement this to make it simple to understand, but I'm happy to do it a different way if there's a good reason to.) http://html5.org/tools/web-apps-tracker?from=6272to=6273 Thanks, this looks great! Minor issue: there are a few places where transfered should be transferred. Slightly larger issue. In the typed array spec, views like Float32Array refer to an ArrayBuffer instance. It's desired to be able to transfer multiple views of the same ArrayBuffer in the same postMessage call. Currently, because each Transferable is transferred independently, transferring the first view will cause the view and underlying ArrayBuffer to be neutered, so upon encountering the second view, an exception will be thrown since its ArrayBuffer was already transferred. This could happen with any Transferable object that has a reference to another Transferable, so I don't think it's a problem overly specific to typed arrays. The way this was addressed in the current typed array strawman proposals was to split the transfer operation into two stages: cloning of, and closing of, the original object. First, all transferable objects were cloned, and then they all were closed. See http://www.khronos.org/registry/typedarray/specs/latest/#9.2 . This can be addressed in the current spec by stating in http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#transferable-objects that the transfer map is provided to the steps defined by the type of the object in question. That way, transferring of a particular object can update the map during the transfer operation, possibly adding more associations to it. The map will provide enough state to allow transfer of dependent transferable objects. Thoughts? Should I file a bug about this? kbr: Feel free to ping me if you need advice on how to use this with ArrayBuffer in the short term. On the long term I'm happy to just spec this in the same spec as the rest of this stuff. Thanks. In the long run I'd be very happy to have the semantics for ArrayBuffer and views defined in this spec. In the short term, I'd like to prototype this first and get some experience with it. -Ken
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, 24 Jun 2011, Kenneth Russell wrote: Slightly larger issue. In the typed array spec, views like Float32Array refer to an ArrayBuffer instance. It's desired to be able to transfer multiple views of the same ArrayBuffer in the same postMessage call. Currently, because each Transferable is transferred independently, transferring the first view will cause the view and underlying ArrayBuffer to be neutered, so upon encountering the second view, an exception will be thrown since its ArrayBuffer was already transferred. The views shouldn't be Transferable. Only the buffer should be. The views should continue to have the behaviour you had described before, where they recurse to clone their buffer then just clone the view. Since the buffers would already be transferred (the transfering happens before the cloning), it'll all just work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
