Re: [whatwg] Orientation event in Firefox

Simon Fraser: > What you're talking about here is getting data from the > accelerometer to describe arbitrary positions, so I think it would > be clearer if these were called "accelerometer" events, or something > else that distinguishes them from the usage that only applies to the > cardinal angle

Re: [whatwg] behavior

On Fri, 18 Sep 2009 14:43:39 -0400, Boris Zbarsky wrote: On 9/18/09 10:21 AM, Michael A. Puls II wrote: Attaching a test. So, is it IE's behavior we want here, or Opera's? In my opinion, neither. We don't want to have plug-in instantiation depending on the CSS box model at all (and want to

Re: [whatwg] Orientation event in Firefox

I'm a little concerned about use of the word "orientation" for these kinds of events. WebKit on iPhone already uses the term "orientation" to mean "which way up is the device", i.e. in portrait or landscape, right-way-up or upside-down:

[whatwg] status of html5 Custom scheme and content handlers?

RE: 6.8.2 I ask because I am interesting in providing an implementation, and am wondering if it is stable enough to start. It is currently marked as a Working Draft, although I can not find any discussion since late spring, 2009. It reads as if the spec is fairly complete to provide an experimen

Re: [whatwg] behavior

On 9/18/09 10:21 AM, Michael A. Puls II wrote: Attaching a test. Thanks for doing that! In Opera: If you switch the display to none, it destroys the plug-in instance. Setting the display to something else again doesn't restore the previous plug-in instance. It creates a new one that starts p

Re: [whatwg] behavior

On Fri, 18 Sep 2009 08:18:04 -0400, Boris Zbarsky wrote: On 9/18/09 4:57 AM, Michael A. Puls II wrote: We (Gecko) consider it a bug that a display:none in a document doesn't instantiate the plug-in. BTW, what is the reason for considering it a bug? Because the current behavior of having t

Re: [whatwg] Global Script proposal.

Commenting in general on this (and not specifically the GlobalScript proposal), I think the outcome of discussions on this list too often is "solve it with a single-page Ajax app". In contrast, I think HTML5 should address the needs of multi-page (including all server-side oriented) apps with at le

Re: [whatwg] Feature requests in WebSocket

Ian Hickson wrote: > I don't see how we could hit limits within the OS with Web Sockets. Ian, Consider a webapp with U users, each with W widgets accessing S services on the server. The resources the server needs to service with with multiplexing is O(U+S) But if there is no multiplexing and ea

Re: [whatwg] behavior

On 9/18/09 4:57 AM, Michael A. Puls II wrote: We (Gecko) consider it a bug that a display:none in a document doesn't instantiate the plug-in. BTW, what is the reason for considering it a bug? Because the current behavior of having the plug-in instantiation handled by effectively the CSS box

Re: [whatwg] behavior

On Mon, 14 Sep 2009 08:42:10 -0400, Boris Zbarsky wrote: We (Gecko) consider it a bug that a display:none in a document doesn't instantiate the plug-in. BTW, what is the reason for considering it a bug? Is it because: { visibility: hidden; width: 0; height: 0; padding: 0; margin: 0; line-

Re: [whatwg] localStorage, the storage mutex, document.domain, and workers

> > > When we add more of these features, I think we will need a way to acquire > multiple locks simultaneously before running a callback. (So if we had > localStorage.runTransaction(function(storage) { ... }) and > otherLockingThing.runTransaction(function(thing) { ... }), we could also > have, fo

Re: [whatwg] localStorage, the storage mutex, document.domain, and workers

These two statements are true... * "We can't change the API" * It is seriously flawed ... and therein lies the problem. I'm sad to have to say it... but I hope this withers and dies an early death. Putting this in the web platform for perpetuity is a mistake. I don't support the adoption of this i