Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 24, 2011 at 3:43 PM, Ian Hickson wrote: > 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. Thanks, I think I see how this is supposed to work now. I'll rewrite the relevant sections of the typed array spec soon and ping you or post again if it looks like there are any other issues. -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. `._.-(,_..'--(,_..'`-.;.'
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 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=6272&to=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
[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 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: Mouse Lock
On Fri, Jun 24, 2011 at 1:58 PM, Aryeh Gregor wrote: > 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. > "Walling the mouse cursor into a box" and "changing the mouse to a delta movement device" are separate concepts. They shouldn't be wedged together--it may not even be possible to implement both at the same time, as discussed earlier. -- Glenn Maynard
Re: Mouse Lock
On Wed, Jun 22, 2011 at 5:20 AM, Simon Pieters wrote: > On Tue, 21 Jun 2011 00:43:52 +0200, Aryeh Gregor > 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.
Re: Mouse Lock
On Fri, Jun 24, 2011 at 12:00 PM, Vincent Scheib 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
> > 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."
[Bug 13042] Define Event.timeStamp
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13042 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Anne 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.
[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.
[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=advanced&short_desc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=Server-Sent+Events+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= [3] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0695.html
[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 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: 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
Re: [widget] technology/specification name
On Fri, Jun 24, 2011 at 12:44 PM, Scott Wilson wrote: > On 24 Jun 2011, at 10:41, Marcos Caceres wrote: > >> On Fri, Jun 24, 2011 at 11:08 AM, Rich Tibbett wrote: >>> Marcos Caceres wrote: On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchard 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 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: P&C 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
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 wrote: >> Marcos Caceres wrote: >>> >>> On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchard >>> 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 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: P&C 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 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 Fri, Jun 24, 2011 at 11:08 AM, Rich Tibbett wrote: > Marcos Caceres wrote: >> >> On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchard >> 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 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
[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 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 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
Marcos Caceres wrote: On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchard 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'.
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 Raggett http://www.w3.org/People/Raggett > >
Re: [widget] technology/specification name
On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchard 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
