[whatwg] Canvas feedback
On Fri, 13 Mar 2009, Hans Schmucker wrote: This problem recently became apparent while trying to process a public video on tinyvid.tv: In article 4.8.11.3 Security with canvas elements, the origin-clean flag is only set depending on an element's origin. However there are many scenarios where an image/video may actually be public and actively allowing processing on other domains (as indicated by Access-Control-Allow-Origin). Is this an oversight or is there a specific reason why Access Control for Cross-Site Requests should not work for Canvas? I'm waiting for CORS to be a proven technology before using it widely in HTML. I think eventually it will be plugged into several features, including canvas and video, but for now it seems safer to wait and see. On Sat, 14 Mar 2009, Hans Schmucker wrote: Question is: what would be the best way to fix it? Of course the spec could be changed for video and image, but wouldn't it be simpler to update the defintion of origins to include patterns that can represent allow rules? On Sat, 14 Mar 2009, Robert O'Callahan wrote: I don't think changing the definition of origins is the right way to go. I agree with Rob that we don't want to be changing the 'origin' concept. It's brittle enough as it is. It seems better to define a category of public resources, specify that a resource served with Access-Control-Allow-Origin: * is public, and have canvas treat public resources specially. I don't think we need public resources, just resources that have been allowed and resources that haven't (like with video). But this, IMHO, can wait for a while longer, until we have tested CORS with a few technologies and proved that it is a good technology. On Sat, 14 Mar 2009, Biju wrote: Just like canvas.getImageData() and canvas.putImageData() Why canvas.getImageHSLData() and canvas.putImageHSLData() API are not provide? Is it something discussed and planned not have? In practice user agents actually store image data as memory buffers of RGBA data, so handling RGBA data is (or at least can be) extremely efficient. HSLA data is not a native type, so it would be an inefficient type to provide native access to. In practice, if you need to work in the HSLA space, then you should convert the data to HSLA and back manually, which would highlight the performance bottleneck implied in such an approach. Alternatively, convert whatever algorithms you are using to work in the RGBA space. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] video feedback
On Wed, 4 Mar 2009, Chris Pearce wrote: The media element spec says: If a media element whose |networkState| has the value |NETWORK_EMPTY| is inserted into a document, the user agent must asynchronously invoke the media element's resource selection algorithm. The resource selection algorithm then goes on to set the delaying-the-load-event flag to true. Depending on how the asynchronous invocation is implemented, the document could actually complete loading during the time after the insertion of a media element, but before the resource-selection algorithm sets the delaying-the-load-event flag is set to true. This means the load event could fire during that time, even though we intended to delay the load event. Maybe we should set the delaying-the-load-event flag to true before we asynchronously call the resource-selection algorithm, and then then resource-selection algorithm can set the delaying-the-load-event flag to false if that decides it needs to wait for a src or source element child? I've fixed this (though not quite as you describe, for simplicity's sake). On Fri, 6 Mar 2009, Chris Pearce wrote: There's an additional problem with the current media load algorithm spec, it's possible to cause two resource-selection asynchronous calls to run in parallel with the following javascript: var v = document.createElement(video); v.src = foo.ogg; v.load(); document.body.appendChild(v); The load() method will asynchronously invoke the media element's resource selection algorithm, and if the resource selection algorithm doesn't execute fast enough in the background to change the networkState, when we add the video to the document and the networkState is still NETWORK_EMPTY, the add-to-a-document code will asynchronously invoke the resource selection algorithm again. I fixed this along with the earlier problem. On Thu, 5 Mar 2009, Robert O'Callahan wrote: On Thu, Feb 26, 2009 at 10:19 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 25 Feb 2009, Robert O'Callahan wrote: Under Once enough of the media data has been fetched to determine the duration of the media resource, its dimensions, and other metadata, after setting the state to HAVE_METADATA, steps 7 and 8 say 7. Set the element's delaying-the-load-event flag to false. This stops delaying the load event. 8. This is the point at which a user agent that is attempting to reduce network usage while still fetching the metadata for each media resource would stop buffering, causing the networkState attribute to switch to the NETWORK_IDLE value, if the media element did not have an autobuffer or autoplay attribute. I suggested HAVE_CURRENT_DATA would be a better state for these actions, and I still think so. These actions should not occur until the UA is able to display the first frame of the video. Authors would want the first frame of a non-autobuffered video to be visible, and the document load event should fire after the first frame is available by analogy with images. I've updated the note as per your suggestion. In step 7 you still stop delaying the load event after loading metadata. I still say we should keep delaying the load event until we reach HAVE_CURRENT_DATA. Man, I suck at this. Fixed. Again. For real this time I hope. On Fri, 13 Mar 2009, Matthew Gregan wrote: It's possible that neither a 'play' nor 'playing' event will be fired when a media element that has ended playback is played again. When first played, paused is set to false. When played again, playback has ended, so play() seeks to the beginning, but paused does not change (as it's already false), so the substeps that may fire play or playing are not run. 'play' shouldn't fire, since it was never paused. 'playing' should fire, though, since the readyState will have dropped down to HAVE_CURRENT_DATA when the clip is ended, and will drop back up to HAVE_FUTURE_DATA after seeking. This behaviour seems reasonable if the media element has a loop attribute, since playback never really stops (as it restarts immediately upon ending). Actually the 'playing' event fires even in this case, which is a bit weird. Not sure how to suppress it, though, since if seeking takes non-zero time, we shouldn't suppress it after all. On Sun, 15 Mar 2009, Biju wrote: What I understood from http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#time-ranges following will be the syntax to access video elements buffered time-ranges v1.buffered.length v1.buffered.start(i) v1.buffered.end(i) When I compare it with existing syntax like document.links.length document.links[0].href document.images.length document.images[0].src window.frames.length window.frames[0].history I feel it should have been of the pattern v1.buffered.length v1.buffered[i].start v1.buffered[i].end So why we
Re: [whatwg] Link.onload; defer on style, depends
Ian Hickson wrote: On Sun, 15 Mar 2009, Boris Zbarsky wrote: Sean Hogan wrote: This is a request for the link element to be given an onload attribute. And presumably a readyState property. At least in Gecko, you can already detect whether the sheet is done loading: if you try to get its cssRules and that throws INVALID_ACCESS_ERR, then it's still loading. (If it throws DOM_SECURITY_ERR then you're not allowed to read the style data; that's why you have to check for the exact type of exception thrown. Though really, if you're loading style sheets cross-site you're in for a world of hurt unless you control both sites.) I haven't added readyState at this time. I am concerned about feature creep here. As for link.onload, link.readyState is implemented in IE since IE6. Same values as document.readyState, etc.
Re: [whatwg] Link.onload; defer on style, depends
Ian Hickson wrote: So testing this: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/44 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/45 (44 uses currentStyle, for IE/Opera, 45 uses getComputedStyle, for Opera/ Firefox/Safari) It seems Gecko is the only engine that blocks here. That's quite odd. The behavior this is showing in Safari, in particular, is the one described in http://webkit.org/blog/66/the-fouc-problem/, and last I'd heard that was causing compat issues and was going to be changed. Specifically, see https://bugzilla.mozilla.org/show_bug.cgi?id=84582#c16. Maybe it hasn't been changed after all? It would be interesting to hear from other browser vendors about their opinions on this issue. I would too. No. What's paused is execution of new scripts, not of existing ones. So in this case, b() executes immediately, while a() executes after the stylesheet loads. Woah, so this can affect the order of script execution? Yes, just like document.write(script src=...) would, no? That seems very dangerous. What if b() depends on a()? I would be surprised if this didn't cause compatibility problems. For what it's worth, we shipped this behavior in Firefox 3.0 and I have yet to see a bug report about anything other than rare instances of flashes of unstyled content due to scripts in one frame forcing layout in another while stylesheets are still loading in the latter. On Sat, 14 Mar 2009, Greg Houston wrote: On a side note, I can actually attach a functioning onload event to a link element in Internet Explorer. Firefox, Safari, and Chrome ignore my attempt, and Opera will fire the onload event but not update the style of the page. Since there are already implementations of this I've gone ahead and defined it. I have a question about this text. It says that the load event is fired asynchronously; that's fine. However, the page load event is fired synchronously on completion of network activity in some cases (at least in Gecko). Which means that if no steps are taken to prevent it, if the last resource loading is a stylesheet the load event for the page will fire before the load event for the stylesheet. It's not clear to me whether this is ok per the spec text. Note that for image load events such steps to prevent are in fact taken (a pending image load event blocks the page onload from firing). -Boris
Re: [whatwg] Link.onload; defer on style, depends
Boris Zbarsky wrote: No. What's paused is execution of new scripts, not of existing ones. So in this case, b() executes immediately, while a() executes after the stylesheet loads. Woah, so this can affect the order of script execution? Yes, just like document.write(script src=...) would, no? And just to be clear, since in Gecko 1.8.1 and earlier link rel=stylesheet blocked the parser, it behaved just like script src=... there. So the order of script execution in your testcase was affected in those builds as well. -Boris
[whatwg] Fwd: AppCache and SharedWorkers?
There hasn't been much discussion of this yet... a few comments on the list between august and november of 2008... [michaeln] How do workers and appCaches interact? [ian] workers are associated with browsing contexts, so they go through the normal app cache networking changes. This probably interacts badly with shared workers used from different app caches. We should probably study this more. Aaron, Maciej, others, do you have opinions on how these should interact? [michaeln] Seems reasonable to spec that dedicated workers are very related to their owner, execute in a child browsing context, and consequently inherit the same appCache. Seems reasonable to spec that shared workers are associated with a browsing context that is very distinct from their clients. Akin to an auxiliary top-level browsing context. [ian] The above seems reasonable... Beyond that it gets less clear. Do sharedWorker.js documents need a html manifest='url' equivalent? They don't have one today. I don't really want to add one... Should a shraredWorker loaded from appCacheA be distinct from a named shared worker loaded from appCacheB or from the network? That seems like a reasonable possibility too... I haven't fixed this yet. On Tue, Mar 24, 2009 at 6:14 PM, Drew Wilson atwil...@google.com wrote: I'm trying to understand the ApplicationCache spec as it applies to workers, but I didn't find anything promising when I searched the archives. Is ApplicationCache intended to apply to workers? The application cache API isn't available to workers, but I'm guessing the intent is that if an application creates a dedicated worker then worker requests (like importScripts()) would come out of the cache inherited from the parent document. If not, then it seems impossible to support running workers when in offline mode. Since SharedWorkers are shared by multiple windows, there's some ambiguity about which app cache it should use (perhaps always the one from the creator window?) - it seems like an app might get different SharedWorkers() loading from different app caches depending on the order in which different windows create them, which seems like a dubious outcome. Has this been discussed previously? -atw
Re: [whatwg] AppCache and SharedWorkers?
The appcache spec has changed since the ian and i sent these old messages. Child browsing contexts (nested iframes) no longer inherit the appcache of their parent context (frame) by default. How's this for a starting point for how these things intereract... * Dedicated worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for child browsing contexts. (So just like navigating an iframe). * Shared (or persistent) worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for top-level browsing contexts. (So just like navigating a window.) At least one question, I'm sure there are others... What does a shared (or persistent) worker do when the appcache its associated with is updated? Is there a way to reload itself with the new script in the latest version of the appcache? What about message ports between the worker and other contexts? On Wed, Mar 25, 2009 at 11:36 AM, Drew Wilson atwil...@google.com wrote: Awesome, thanks. That feels in line with how I was viewing the issue - the big problem (as you note below) is that the AppCache mechanism breaks down when you have two different top-level browsing context sharing a single resource (SharedWorkers). I'm working on a proposal for persistent workers (shared workers that keep running after the browser is closed, and launch on startup) and so how these workers interact with the application cache is of great interest to me. One approach that I'm considering is giving each persistent worker its own app cache, so rather than inheriting a cache from any given browsing context it would be responsible for managing its own offline resources. This seems to have a bunch of advantages, and might also be applicable to normal shared workers. -atw 2009/3/25 Michael Nordman micha...@google.com There hasn't been much discussion of this yet... a few comments on the list between august and november of 2008... [michaeln] How do workers and appCaches interact? [ian] workers are associated with browsing contexts, so they go through the normal app cache networking changes. This probably interacts badly with shared workers used from different app caches. We should probably study this more. Aaron, Maciej, others, do you have opinions on how these should interact? [michaeln] Seems reasonable to spec that dedicated workers are very related to their owner, execute in a child browsing context, and consequently inherit the same appCache. Seems reasonable to spec that shared workers are associated with a browsing context that is very distinct from their clients. Akin to an auxiliary top-level browsing context. [ian] The above seems reasonable... Beyond that it gets less clear. Do sharedWorker.js documents need a html manifest='url' equivalent? They don't have one today. I don't really want to add one... Should a shraredWorker loaded from appCacheA be distinct from a named shared worker loaded from appCacheB or from the network? That seems like a reasonable possibility too... I haven't fixed this yet. On Tue, Mar 24, 2009 at 6:14 PM, Drew Wilson atwil...@google.com wrote: I'm trying to understand the ApplicationCache spec as it applies to workers, but I didn't find anything promising when I searched the archives. Is ApplicationCache intended to apply to workers? The application cache API isn't available to workers, but I'm guessing the intent is that if an application creates a dedicated worker then worker requests (like importScripts()) would come out of the cache inherited from the parent document. If not, then it seems impossible to support running workers when in offline mode. Since SharedWorkers are shared by multiple windows, there's some ambiguity about which app cache it should use (perhaps always the one from the creator window?) - it seems like an app might get different SharedWorkers() loading from different app caches depending on the order in which different windows create them, which seems like a dubious outcome. Has this been discussed previously? -atw
Re: [whatwg] C:\fakepath\ in HTML5
The long and short of it with the c:\fakepath\ issue is that some browser vendors have reported compatibility problems with not having this. I acknowledge that there is some skepticism about whether this is a serious enough issue to warrant this ugly hack, but given that the concerns were raised by two browser vendors independently, it seems likely that we should heed their advice. I don't think is a huge issue because we will in due course (when Arun's spec is ready) be adding an API to input type=file that exposes the actual files, filenames, types, etc, and the .value API will be vestigial. (The .value API has other issues, like only exposing the first file in a multiple-file upload widget.) On Tue, 24 Mar 2009, Boris Zbarsky wrote: Ian Hickson wrote: According to Microsoft: http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx ...the problem was with a significant number of sites (e.g. education products, several movie sharing sites, etc) and devices (e.g. popular home routers). The blog post above includes a screenshot of a firmware upgrade screen that has this problem. This is not a site that could be fixed. Sure it is. You just need a browser that'll allow you to do a firmware upgrade to fix it. Which means that if one gets such an upgrade shipped before all browsers stop sending paths, things seem to be ok. Realistically speaking, that seems unlikely to be practical. I wouldn't be really surprised that someone would want to upgrade the firmware on a device ten years from now, for instance. We never know. I agree they're not as happy as they could be, but they're ok. In addition, is the expected lifetime of the affected device comparable to the expected time it takes to deploy the new behavior in browsers? If so, it's worth it to contact the device maker and ask them to fix things in their next model instead of working around them. We both know that evanglisation efforts don't have a great success rate. As far as the significant number of sites above... I wonder whether there's UA sniffing going on here that causes some of these to assume certain things about IE only. We've certainly seen quite a number of issues along those lines: we fix a bug, and discover that sites had written special browser-specific code taking advantage of that bug. Indeed, I wouldn't be surprised if this was why Opera and IE have seen this problem, but Mozilla has not. On Tue, 24 Mar 2009, Alex Henrie wrote: Example: A site lets a user upload a file and write some comments associated with that file. On the browser side, a new input element is dynamically created with the name and id Notes for C:\fakepath\upload.txt. On the server side, the server receives upload.txt and looks for Notes for upload.txt to match. It of course is not there because the programmer had no idea that the browser would be adding appending a fake path in JavaScript but not in HTTP. That seems like a rather brittle design; what if the user uploads two files with the same name, for instance? Or uploads an anonymous file (e.g. a file obtained from an on-board camera)? Or changes the selected file? I recommend using a unique ID instead, it's much more resilient. :-) On Tue, 24 Mar 2009, Bil Corry wrote: I played with this a bit more, it turns out that IE8 returns C:\fakepath\filename.ext for sites in the Internet zone, but returns the real path for sites in the Trusted zone. So even if HTML5 requires returning just the file name and is implemented as such in IE, the user can still designate their router as a Trusted Zone and be able to update their firmware. This is because the Trusted zone gets their less-standards-compliant IE7 mode. I don't think relying on this (or expecting other browsers to do this) is a scalable strategy. Here are some bugs that might be related to this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=304939 https://bugzilla.mozilla.org/show_bug.cgi?id=473047 https://bugzilla.mozilla.org/show_bug.cgi?id=440991 I haven't checked if they really are this problem, but it's possible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache and SharedWorkers?
On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman micha...@google.comwrote: The appcache spec has changed since the ian and i sent these old messages. Child browsing contexts (nested iframes) no longer inherit the appcache of their parent context (frame) by default. How's this for a starting point for how these things intereract... * Dedicated worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for child browsing contexts. (So just like navigating an iframe). Since dedicated workers are tightly tied (1:1) with a specific top-level browsing context, I'd say that they should use the same appcache as the document that started them. * Shared (or persistent) worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for top-level browsing contexts. (So just like navigating a window.) That may make sense for Shared workers, I think. For persistent workers I think this is a problem - persistent workers need a way to manage their own app cache, since they are not guaranteed to have any open windows/documents associated with them. My concern about this is that app cache manifests are only specified via manifest html tags, which makes them only applicable to HTML documents (you can't associate a manifest with a worker since there's no document to put the manifest tag in). At least one question, I'm sure there are others... What does a shared (or persistent) worker do when the appcache its associated with is updated? Is there a way to reload itself with the new script in the latest version of the appcache? What about message ports between the worker and other contexts? One could imagine that the worker would reload its javascript via importScripts(). It kind of assumes that the script is idempotent, though. -atw
Re: [whatwg] C:\fakepath\ in HTML5
While on the topic, something vaguely similar came to mind. If we make a puzzle of 2n-squared minus 1 (e.g. a puzzle of 15) in which web site visitors can slide tiles around through a grid, we might wish to detect, through script, when the puzzle has been solved. This means interrogating the value of Image.src as resolved by the browser. In IE, Chrome and FF I noted today (something different than it was a year or so ago) that for content served from the local drive space (in Windows anyhow), document.images[x].src resolves to file:///C:/ [path]. In Opera, it still resolves to file://localpath:/ . Hence, script to determine if the puzzle has been solved has to resort to a wee bit of mischief to untangle the issue. Over the past nine years or so, I've seen at least a half dozen different strategies employed by various browsers to deal with the issue, ranging from the sensible to the bizarre, varying as a function of where the file is found (in local drive space, networked files, or even files served from the web). Where might we expect things to settle down ultimately? cheers David P.S. I gather from what you've written here, that indeed the spec will simplify access to local drive space through input type=file eventually, hence allowing client-side image manipulation for web applications? Will this solution propagate outward into SVG as well, where it will also be quite useful, or only if the SVG is inlined in HTML? - Original Message - From: Ian Hickson i...@hixie.ch To: wha...@whatwg.org Sent: Wednesday, March 25, 2009 5:39 PM Subject: Re: [whatwg] C:\fakepath\ in HTML5 The long and short of it with the c:\fakepath\ issue is that some browser vendors have reported compatibility problems with not having this. I acknowledge that there is some skepticism about whether this is a serious enough issue to warrant this ugly hack, but given that the concerns were raised by two browser vendors independently, it seems likely that we should heed their advice. I don't think is a huge issue because we will in due course (when Arun's spec is ready) be adding an API to input type=file that exposes the actual files, filenames, types, etc, and the .value API will be vestigial. (The .value API has other issues, like only exposing the first file in a multiple-file upload widget.) On Tue, 24 Mar 2009, Boris Zbarsky wrote: Ian Hickson wrote: According to Microsoft: http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx ...the problem was with a significant number of sites (e.g. education products, several movie sharing sites, etc) and devices (e.g. popular home routers). The blog post above includes a screenshot of a firmware upgrade screen that has this problem. This is not a site that could be fixed. Sure it is. You just need a browser that'll allow you to do a firmware upgrade to fix it. Which means that if one gets such an upgrade shipped before all browsers stop sending paths, things seem to be ok. Realistically speaking, that seems unlikely to be practical. I wouldn't be really surprised that someone would want to upgrade the firmware on a device ten years from now, for instance. We never know. I agree they're not as happy as they could be, but they're ok. In addition, is the expected lifetime of the affected device comparable to the expected time it takes to deploy the new behavior in browsers? If so, it's worth it to contact the device maker and ask them to fix things in their next model instead of working around them. We both know that evanglisation efforts don't have a great success rate. As far as the significant number of sites above... I wonder whether there's UA sniffing going on here that causes some of these to assume certain things about IE only. We've certainly seen quite a number of issues along those lines: we fix a bug, and discover that sites had written special browser-specific code taking advantage of that bug. Indeed, I wouldn't be surprised if this was why Opera and IE have seen this problem, but Mozilla has not. On Tue, 24 Mar 2009, Alex Henrie wrote: Example: A site lets a user upload a file and write some comments associated with that file. On the browser side, a new input element is dynamically created with the name and id Notes for C:\fakepath\upload.txt. On the server side, the server receives upload.txt and looks for Notes for upload.txt to match. It of course is not there because the programmer had no idea that the browser would be adding appending a fake path in JavaScript but not in HTTP. That seems like a rather brittle design; what if the user uploads two files with the same name, for instance? Or uploads an anonymous file (e.g. a file obtained from an on-board camera)? Or changes the selected file? I recommend using a unique ID instead, it's much more resilient. :-) On Tue, 24 Mar 2009, Bil Corry wrote: I played with this a bit more, it turns out that IE8 returns C:\fakepath\filename.ext
Re: [whatwg] Link.onload; defer on style, depends
On Tue, Mar 24, 2009 at 7:24 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 15 Feb 2009, Boris Zbarsky wrote:
So in this:
!DOCTYPE html
...
script
document.write('link rel=stylesheet href=style');
document.write('scripta();\/script');
b();
/script
...is the script paused after the second document.write() call, before a()
and b() execute?
No. What's paused is execution of new scripts, not of existing ones. So in
this case, b() executes immediately, while a() executes after the stylesheet
loads.
Woah, so this can affect the order of script execution?
That seems very dangerous. What if b() depends on a()? I would be
surprised if this didn't cause compatibility problems.
As Boris points out, it doesn't change the order of execution compared
to having the link rel=stylesheet block, which is what gecko used to
do. Not sure what other browsers do.
On Sat, 14 Feb 2009, Garrett Smith wrote:
Boris:
Garrett:
What would make it easier? I'd really like to know how to design my
pages so that they are faster and more responsive.
Well, one option is to stop worrying about micromanaging the load
order and assume that speculative parsing will solve your problems
will it?
Possibly. If the author could declare what a script depends on and let
the implementation determine what to load and when, would that be too
complicated?
It seems like this is in general an issue that would be best left up to
the browsers to optimise for, instead of having authors be able to
micromange this (as Boris put it).
In general, scripts shouldn't depend on style sheets anyway; if you are
writing code where you want things to be fast, just avoid breaking that
rule of thumb and then it will never matter.
It's unlikely that we'll ever get to a point when scripts won't depend
on stylesheets though. Until CSS is perfect we'll always have to have
scripts that create more advanced layouts than what CSS can produce,
and these scripts are likely going to depend on data not available
until all relevant stylesheets have loaded.
So basically I put this argument in the same group as content
shouldn't depend on undefined behavior ;)
In fact, I believe that google was the big problem when we tried not
blocking on pending stylesheets. Something about ads hosted on
websites where the scripts from google relied on style information.
All that said, I would love to not have to block scripts on pending
stylesheets. If all other browsers get away with it, I think we should
be able to as well.
/ Jonas
Re: [whatwg] AppCache and SharedWorkers?
On Wed, Mar 25, 2009 at 3:01 PM, Drew Wilson atwil...@google.com wrote: On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman micha...@google.comwrote: The appcache spec has changed since the ian and i sent these old messages. Child browsing contexts (nested iframes) no longer inherit the appcache of their parent context (frame) by default. How's this for a starting point for how these things intereract... * Dedicated worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for child browsing contexts. (So just like navigating an iframe). Since dedicated workers are tightly tied (1:1) with a specific top-level browsing context, I'd say that they should use the same appcache as the document that started them. * Shared (or persistent) worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for top-level browsing contexts. (So just like navigating a window.) That may make sense for Shared workers, I think. For persistent workers I think this is a problem - persistent workers need a way to manage their own app cache, since they are not guaranteed to have any open windows/documents associated with them. My concern about this is that app cache manifests are only specified via manifest html tags, which makes them only applicable to HTML documents (you can't associate a manifest with a worker since there's no document to put the manifest tag in). At least one question, I'm sure there are others... What does a shared (or persistent) worker do when the appcache its associated with is updated? Is there a way to reload itself with the new script in the latest version of the appcache? What about message ports between the worker and other contexts? One could imagine that the worker would reload its javascript via importScripts(). It kind of assumes that the script is idempotent, though. Similarly one could use nested workers (which I like because it gives the new script a new global object). The shared/persistent worker would start a nested worker. Then for a reload, it could shut down the current nested worker and start up a new one. Regarding message ports, it would be up to the implementation to decide if the shared/persistent worker followed a pointer to implementation pattern or if it handed out message ports directly to the nested worker. Dave -atw
Re: [whatwg] AppCache and SharedWorkers?
Good point - I like the idea of nested workers, especially if the SharedWorker uses the pattern where it just passes off all incoming message ports directly to the nested worker so it doesn't have to proxy messages. It'd have to have some app-specific mechanism to get them all back when it wants to restart the nested worker, though :) -atw On Wed, Mar 25, 2009 at 5:09 PM, David Levin le...@google.com wrote: On Wed, Mar 25, 2009 at 3:01 PM, Drew Wilson atwil...@google.com wrote: On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman micha...@google.comwrote: The appcache spec has changed since the ian and i sent these old messages. Child browsing contexts (nested iframes) no longer inherit the appcache of their parent context (frame) by default. How's this for a starting point for how these things intereract... * Dedicated worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for child browsing contexts. (So just like navigating an iframe). Since dedicated workers are tightly tied (1:1) with a specific top-level browsing context, I'd say that they should use the same appcache as the document that started them. * Shared (or persistent) worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for top-level browsing contexts. (So just like navigating a window.) That may make sense for Shared workers, I think. For persistent workers I think this is a problem - persistent workers need a way to manage their own app cache, since they are not guaranteed to have any open windows/documents associated with them. My concern about this is that app cache manifests are only specified via manifest html tags, which makes them only applicable to HTML documents (you can't associate a manifest with a worker since there's no document to put the manifest tag in). At least one question, I'm sure there are others... What does a shared (or persistent) worker do when the appcache its associated with is updated? Is there a way to reload itself with the new script in the latest version of the appcache? What about message ports between the worker and other contexts? One could imagine that the worker would reload its javascript via importScripts(). It kind of assumes that the script is idempotent, though. Similarly one could use nested workers (which I like because it gives the new script a new global object). The shared/persistent worker would start a nested worker. Then for a reload, it could shut down the current nested worker and start up a new one. Regarding message ports, it would be up to the implementation to decide if the shared/persistent worker followed a pointer to implementation pattern or if it handed out message ports directly to the nested worker. Dave -atw
Re: [whatwg] video feedback
At 2009-03-25T10:16:32+, Ian Hickson wrote: On Fri, 13 Mar 2009, Matthew Gregan wrote: It's possible that neither a 'play' nor 'playing' event will be fired when a media element that has ended playback is played again. When first played, paused is set to false. When played again, playback has ended, so play() seeks to the beginning, but paused does not change (as it's already false), so the substeps that may fire play or playing are not run. 'playing' should fire, though, since the readyState will have dropped down to HAVE_CURRENT_DATA when the clip is ended, and will drop back up to HAVE_FUTURE_DATA after seeking. Right, so your intention is to interpret it thusly: readyState becomes HAVE_CURRENT_DATA when playback ends because it's not possible for the playback position to advance any further, and thus it's not possible to have data beyond the current playback position (which HAVE_FUTURE_DATA is predicated upon). Makes sense, but can the spec be made clearer about the behaviour in this case? HAVE_FUTURE_DATA talks about advancing *without reverting to HAVE_METADATA*, which doesn't apply in this case because we have all the data available locally. (Also, note that after the seek it'd return directly to HAVE_ENOUGH_DATA in the case I'm talking about, since the media is fully cached. That still requires a 'playing' event to fire, so that's fine.) Based on that interpretation, when the user sets playbackRate to -1 after playback ends, the readyState would change from HAVE_CURRENT_DATA to HAVE_FUTURE_DATA because the current playback position can now advance. Following this logic, if playbackRate is set to 0 at any time, the readyState becomes HAVE_ENOUGH_DATA, as advancing the playback position by 0 units means the playback position can never overtake the available data before playback ends. Except this case seems to be specially handled by: The playbackRate can be 0.0, in which case the current playback position doesn't move, despite playback not being paused (paused doesn't become true, and the pause event doesn't fire). ...which uses the term move rather than advance, but suggests that the concept of the playbackRate advancing by 0 isn't consider advancing, which seems logical. Cheers, -mjg -- Matthew Gregan |/ /|kine...@flim.org
Re: [whatwg] Canvas feedback
On Wed, Mar 25, 2009 at 3:11 AM, Ian Hickson i...@hixie.ch wrote: On Sat, 14 Mar 2009, Biju wrote: Just like canvas.getImageData() and canvas.putImageData() Why canvas.getImageHSLData() and canvas.putImageHSLData() API are not provide? Is it something discussed and planned not have? In practice user agents actually store image data as memory buffers of RGBA data, so handling RGBA data is (or at least can be) extremely efficient. HSLA data is not a native type, so it would be an inefficient type to provide native access to. In practice, if you need to work in the HSLA space, then you should convert the data to HSLA and back manually, which would highlight the performance bottleneck implied in such an approach. Alternatively, convert whatever algorithms you are using to work in the RGBA space. As in both case the will be performance hit. Isnt it better to take care that in C/Compiled code rather than in JavaScript . code for converting from HSLA to RGBA will be already there in the browser code so that need to be only exposed to JavaScript
