Re: [whatwg] localStorage + worker processes
On Sat, Mar 28, 2009 at 11:29 AM, Michael Nordman micha...@google.comwrote: On Tue, Mar 24, 2009 at 2:11 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 20 Mar 2009, Jonas Sicking wrote: I do think it would be great if workers had access to some type of structured storage. However I agree that the fact that both the main thread and workers have synchronous access to the same storage is not acceptable since that means that we're violating the shared-nothing-message-passing design that makes workers not have to deal with locks and other traditional multithread hazards. Agreed. The Database API seems well-suited for this, though. Again... its not just workers that are affected by this... speaking as someone that works on a multi-threaded browser, this is troubling. If its possible to spec features that allow script to poke at the world beyond the page boundaries in a fashion that doesn't not require locking semantics beyond (I assume that not was unintended.) the scope of a single scriptable API call... that would be less troubling. SQL storage where the single API call is run this complex transaction might be acceptable. But if the single API call is access some shared state and it's up to Web developers to deal with locking and synchronization --- that will never be acceptable. That burden must fall on browser developers, not Web developers. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Worker feedback
On Sat, Mar 28, 2009 at 2:23 PM, Ian Hickson i...@hixie.ch wrote: Robert O'Callahan wrote: Now, with the storage mutex, are there any cases you know of where serializability fails? If there are, it may be worth noting them in the spec. If there aren't, why not simply write serializability into the spec? Just writing that something must be true doesn't make it true. :-) I think it's safer for us to make the design explicitly enforce this rather than say that browser vendors must figure out where it might be broken and enforce it themselves. If serializability is the goal then I think it can only help to say so in the spec (in addition to whatever explicit design you wish to include), so that any failure of serializability is clearly an inconsistency in the spec that must be fixed rather than a loophole that authors and browser vendors might think they can rely on. I also suggest that speccing just serializability should be fine. It seems to me the current spec is proposing one implementation of serializability while other implementations are possible, and relying on the black-box equivalence principle to enable other implementations. But specifying serializability is probably simpler and may allow implementations that are unintentionally ruled out by the explicit design in the spec, especially as things become more complicated in the future. It would probably also be clearer to authors what they can expect. I think it's a lot like GC; we don't specify a GC algorithm, even though GC is hard; we just have an implicit specification that objects don't disappear arbitrarily. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] video and acceleration
On Sat, Mar 28, 2009 at 5:57 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: What is the recommended way to handle the video tag on such hardware? There are two obvious solutions: 0. Implement the spec, and just let it be really slow. 1. Attempt to approximate the correct behavior, given the limitations of the hardware. Make the video appear where it's supposed to appear, and use the 1-bit alpha (dithered?) to blend static items over it. Ignore transparency of the video. Ignore rotations, etc. 2. Ignore the HTML context. Show the video in manners more suitable to the user (e.g. full-screen or in an independent resizable window). 3. Add an optimized path to detect when the YUV overlay can be used to give the correct rendering, and use it in that case. This is not a spec issue, it's entirely an implementation issue. You're welcome to file a bug on that at http://bugzilla.mozilla.org; I can explain there more details about how it could be done, but it's unlikely to happen anytime soon unless a volunteer contributes the code. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Worker feedback
On 28.03.2009, at 4:23, Ian Hickson wrote: I think, given text/css, text/html, and text/xml all have character encoding declarations inline, transcoding is not going to work in practice. I think the better solution would be to remove the rules that make text/* an issue in the standards world (it's not an issue in the real world). In fact, transcoding did work in practice - that's because HTTP headers override inline character declarations. For new formats, though, I think just supporting UTF-8 is a big win. Could you please clarify what the win is? Disregarding charset from HTTP headers is just a weird special case for a few text resource types. If we were going to deprecate HTML, XML and CSS, but keep appcache manifest going forward, it could maybe make sense. - WBR, Alexey Proskuryakov
Re: [whatwg] Worker feedback
Scripts, and worker scripts in particular, should use application media type; using text/javascript is obsolete. [RFC4329#3]. Chris
Re: [whatwg] Canvas - toTempURL - A dangerous proposal
IFRAME where SRC=javascript:... has the same disk full problem as Canvas.toTempURL, and a DOS attack can also be launched simply by creating a large array that will fill the hard drive with virtual memory. In general, handling OOM conditions is not covered by the specification. Chris
Re: [whatwg] Canvas Shadows - Unnecessary Barrier to Entry
On Fri, Mar 27, 2009 at 11:22 PM, Charles Pritchard ch...@jumis.com wrote: [...] We've been working on Javascript / Canvas projects for two years now. We're in the process of releasing full implementations targeting the Common Runtime Language, Java AWT, ActionScript and DCOM. I'm sure you can all recognize, that these components have their own vector APIs, and that we're only sending requests through as a proxy. While we can implement everything, even the non-zero winding rule, there one part of the specification that's absolutely rotten. And that's the #shadows section. I love a shadow, I love a good looking UI, but most of these APIs do not have shadow support for shapes. Do the APIs not provide enough features so you can implement shadows yourself? e.g. Firefox uses Cairo which doesn't have any native support for shadows; but it can draw shapes onto an alpha-only surface, manually blur the pixels (if you can implement getImageData then I assume you must already have access to the raw pixels and can do the blurring efficiently), then draw the shape again, and composite everything appropriately, which results in a correct shadow implementation. I don't see what makes this fundamentally harder than implementing all the other required canvas features. [...] -- Philip Taylor exc...@gmail.com
Re: [whatwg] URL decomposition on HTMLAnchorElement interface
On Fri, 27 Mar 2009 21:53:48 -0400, Boris Zbarsky bzbar...@mit.edu wrote: Kartikaya Gupta wrote: The empty string falls under the anything else case in my suggestion above and would work as you expect. Null and empty string should, imo, have the same behavior here. It doesn't make sense to treat them differently to me. Do you agree that null and empty string should behave differently for search and hash? To me, it doesn't make sense to treat null and the empty string differently for some components but not others. There are big scary comments in the Gecko code for these setters saying that they must never ever throw. I suspect that making them throw would be a serious web compat issue. Is this Gecko-internal code you're referring to? Or the setters exposed to web content via HTMLAnchorElement? The latter. The Gecko-internal URI code does in fact throw on a lot of these setters, and the HTMLAnchorElement methods catch and eat these exceptions, very much on purpose. Ok. I'll assume there is valid reasoning behind that. Replace all the throws with be silently ignored in my proposal. Changing from an authority to a non-authority URI or the other way around doesn't seem desirable to me (and would only work for unknown schemes anyway, presumably, at best; it's better if it just never works). Does it matter? Since it's an unknown scheme, it's basically opaque data. You can't dereference it and fetch the resource it points to No, but you can pass it off to a helper application. In any case, my comment above was more concerned with your proposal that one should be able to create a non-authority http: URI than about unknown schemes. I don't think my proposal allowed creation of a non-authority http: URI. I said that 'Attempts to set host to null for a scheme known to require an authority should throw.' Since http is a scheme known to require an authority, you wouldn't be able to null out the authority. The one loophole I missed would be to create a non-http non-authority URI and then change the scheme to http. That can be fixed by amending the first sentence of my proposal to the following: - Attempts to set protocol to null, the empty string, or anything containing invalid characters (i.e. not in the scheme production of RFC3986) should throw. Setting it to a scheme known to require an authority when the authority component is null should also throw. Setting it to a scheme known to require no authority when the authority component is non-null should also throw. Setting it to anything else should be allowed and should update the scheme component of the underlying URI. (With appropriate adjustments of s/throw/be silently ignored/) Cheers, kats
Re: [whatwg] URL decomposition on HTMLAnchorElement interface
Kartikaya Gupta wrote: Do you agree that null and empty string should behave differently for search and hash? No, not really. Are they treated differently in current UAs (past null being treated as null, possibly)? To me, it doesn't make sense to treat null and the empty string differently for some components but not others. Agreed that it would be confusing from a web developer point of view. Of course from a URI point of view some URI components can be empty but present or can be not present at all, as you point out above. The latter. The Gecko-internal URI code does in fact throw on a lot of these setters, and the HTMLAnchorElement methods catch and eat these exceptions, very much on purpose. Ok. I'll assume there is valid reasoning behind that. Replace all the throws with be silently ignored in my proposal. For what it's worth, I suspect that the silent fail is somewhat interoperably implemented already. No, but you can pass it off to a helper application. In any case, my comment above was more concerned with your proposal that one should be able to create a non-authority http: URI than about unknown schemes. I don't think my proposal allowed creation of a non-authority http: URI. I said that 'Attempts to set host to null for a scheme known to require an authority should throw.' Since http is a scheme known to require an authority, you wouldn't be able to null out the authority. Or set it to the empty string, which has the same effect. Your proposal treats those differently. - Attempts to set protocol to null, the empty string, or anything containing invalid characters (i.e. not in the scheme production of RFC3986) should throw. Setting it to a scheme known to require an authority when the authority component is null should also throw. Setting it to a scheme known to require no authority when the authority component is non-null should also throw. Setting it to anything else should be allowed and should update the scheme component of the underlying URI. Honestly, I can't think of a sane way to define a protocol setter that changes from one URI type to another (type being has authority, doesn't have authority, unknown). Actually, as far as Gecko is concerned there are 5 different types; see the three constants defined at http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIStandardURL.idl#56 for three, plus not a hierarchichal URI (which never does the fixup from scheme:foo to scheme://foo) and unknown (treated like not a hierarchical URI). -Boris
Re: [whatwg] URL decomposition on HTMLAnchorElement interface
Interestingly, it looks like Opera doesn't support the hostname setter at all. Safari ignores the call in this case. I don't have IE to test offhand. True. Opera currently does not support setting these values separately.
