Re: [whatwg] toDataURL image/jpeg composition
On Fri, Dec 3, 2010 at 1:06 AM, Charles Pritchard ch...@jumis.com wrote: Currently, Firefox and Safari output image/jpeg in a way that differs from the spec: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11431 is there a reason you haven't found/filed bugs in bugzilla.mozilla.org/bugs.webkit.org?
Re: [whatwg] [html5] r5399 - [giow] (2) Define option.selected; make option disabled selected still get sel [...]
On Tue, 07 Dec 2010 23:13:13 +0100, Ian Hickson i...@hixie.ch wrote: On Tue, 31 Aug 2010, Simon Pieters wrote: Maybe select requiredoption value selected disabledChoose one... should be allowed? I considered that, but since disabled options don't get selected, that wouldn't work without yet more special-casing. It gets selected in Opera, Firefox and WebKit. AFAICT the spec makes it selected, too (selectedness is true if selected= is present regardless of disabled=). The spec allows select requiredoption valueChoose one...option selectedFoo. Maybe it should require the label option to be selected by default (either implicitly or explicitly) when the select has required? No, otherwise there'd be no way to just select the current value without removing the label. Yeah. The spec currently doesn't require there to be any select label option if the required attribute is present on select. Right, the label doesn't have to be present. Why would we require one? Because without one the required attribute has no effect, so is likely an authoring mistake. Also, s/selected element's/select element's/ -- Simon Pieters Opera Software
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On Wed, 15 Sep 2010, Gavin Peters (�~S~K�~V~G彼德�~V�) wrote: Hi, I'm working on link tags inside of chrome. We're now experimenting with an optimization that uses link tags and headers to avoid round trips for cache validation in many cases. I propose we add an optional etags last-modified attribute to the link element. If present for an http uri, these tags represent an assertion about the current cache status of the target resource. A browser that has a cached resource for that uri with the same etags and/or last-modified may present the link data without validation in connection with the link retrieval. A browser that has a cached resource for that uri which has a different etags and/or last-modified should treat the resource as if it is in need of validation for retrieval, even if normal cache expiry would treat the resource as valid. I anticipate that these attributes will be more commonly (and probably safely) used on the Link: header than in the link element. When used, they have the potential to save a browser many round trip cache validations (304s) even for data with short cache expiry, and to also to potentially allow early cache-expiry for resources which change ahead of their cache validity period. These are both great speedups; page loads should be faster and network use should be reduced. As others have pointed out, these don't seem to add anything to the equation that couldn't also be handled by simply changing the URL and giving the resources essentially infinite cacheable lifetimes. In both cases, the HTML document has to be changed (in the same location even). The advantage of the URL trick is it works today, and is probably easier to understand (most authors are unlikely to know how to find their ETags even if they knew what they were, for instance). On Mon, 20 Sep 2010, Roger Hågensen wrote: It would be better to define this as explicitly indicating which resources are NOT valid any longer, with most sites/web applications this would only be a select few links. Doing that would require knowing what the browser's cache contains. I haven't added this to the spec yet. However, I encourage experimentation -- that's how we work out what the spec should say; if this turns out to be popular and effective, we should reconsider adding it to the language. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Proposal for a tab visibility API
Hi all, On the Chromium team we’ve identified a couple of use cases that we’d like to address with a simple API, and we’d love your feedback. In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, although some heuristics do exist (like detecting mousemove events). In the future, there may be cases where such detection is even more important, for example in the prerendering feature ( http://code.google.com/p/chromium/issues/detail?id=61745) that Chromium is currently in the early stages of experimentation with. ==Use cases== * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. * A streaming video site doesn’t want to start the video until the user actually views the tab for the first time (i.e. video shouldn’t start automatically if a user opens the tab in the background). * A page wants to detect when it is being prerendered so it can behave appropriately. * A page wants to detect when it is moving into or out of the back-forward cache. With these use-cases in mind, there are a number of requirements. ==Requirements== * Easy for developers to write scripts that fall back on old behaviors for browsers that do not implement this API * Ability to query the document’s current visibility state * Events fired when the document transitions between visibility states * Ability for browser vendors to add new visibility states in the future ==Strawman API== What follows is a proposed API that fits the requirements. Note that another route would be to attempt a mostly-compatible extension of Mozilla’s existing pageshow and pagehide events, which would not necessarily be perfectly backwards compatible. =document.visibility= A read-only property that returns a string, one of: * “visible” : the tab is focused in its window * “hidden” : the tab is backgrounded within its window * “prerender” : the tab is currently being loaded in an off-screen tab, and may never be shown to the user. * “cache” : the tab is currently in the back-forward-cache. Note that in Mozilla’s current implementation, document.visibility would never actually be “cache” because Javascript cannot execute when in the cache. In the future, the list of possible values may be extended. Of these states in this list, all except “visible” are considered to be hidden. Developers can use the existence of this property to know that they can rely on the rest of this API, too. =document.isVisible= A simple convenience read-only property that returns a boolean. Returns true if document.visibility’s current value is in the set of visibility states considered to be visible (for the first iteration of this API, that would only include the “visible” state). =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibility just before it was changed to the current value. Note that visibility has nothing to do with whether the document’s contents have fully loaded or not, which implies that for any given visibility transition event, onload may or may not have already fired. Thoughts or comments are welcome. --Alex Komoroske
Re: [whatwg] Proposal for a tab visibility API
On 12/8/10 2:47 PM, Alex Komoroske wrote: * A page wants to detect when it is moving into or out of the back-forward cache. This is covered by pagehide/pageshow events, as you note; note that the bfcache visibility state has some big differences from the other invisible states, as currently implemented. Maybe we should be trying to converge them, but I'm not convinced. There are several issues we should keep in mind as we work on this: 1) background tab is pretty narrow. Minimized windows, windows that aren't on the current desktop, etc, have all the same problems. 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. A read-only property that returns a string, one of: * “visible” : the tab is focused in its window And certain conditions in the window, ideally; though I can see leaving that to a further iteration of the API. * “cache” : the tab is currently in the back-forward-cache. Note that in Mozilla’s current implementation, document.visibility would never actually be “cache” because Javascript cannot execute when in the cache. Yes, but javascript running in other windows can touch the cached JS objects, no? -Boris
Re: [whatwg] Proposal for a tab visibility API
On Wed, 08 Dec 2010 19:47:34 -, Alex Komoroske komoro...@chromium.org wrote: Hi all, On the Chromium team we’ve identified a couple of use cases that we’d like to address with a simple API, and we’d love your feedback. In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, Minor semantic nitpick: please use the term /does not have focus/ rather than /is a background tab/, as the latter is misleading in window managers that don't use tabs to represent (all) windows. [Ninja'd] although some heuristics do exist (like detecting mousemove events). In the future, there may be cases where such detection is even more important, for example in the prerendering feature ( http://code.google.com/p/chromium/issues/detail?id=61745) that Chromium is currently in the early stages of experimentation with. ==Use cases== * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. Fair 'nuff (though I stress the importance of Web IDL APIs like this being specified separately from HTML). * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. I argue that dynamic content should be declared as such. HTTP can hint at expiry of content, allowing UAs to automagically refetch content, but still allowing users to have the final say and set reasonable limits and take bandwidth constraints into consideration. I may not want to download that ad every two seconds over my metered mobile ad hoc network. * A streaming video site doesn’t want to start the video until the user actually views the tab for the first time (i.e. video shouldn't start automatically if a user opens the tab in the background). I don't see how autoplaying videos relate to Web IDL, but this is covered in other specifications. Autoplay is quite annoying, and there are other reasons for not automatically following links in pages and playing media recently downloaded, but I'm going OT. * A page wants to detect when it is being prerendered so it can behave appropriately. * A page wants to detect when it is moving into or out of the back-forward cache. Pass. Remember to take note of the existing SIGTSTP, in case there's anything to learn from history. With these use-cases in mind, there are a number of requirements. ==Requirements== * Easy for developers to write scripts that fall back on old behaviors for browsers that do not implement this API * Ability to query the document’s current visibility state * Events fired when the document transitions between visibility states * Ability for browser vendors to add new visibility states in the future Make a note of job/task managers potentially suspending unneded jobs, such as hidden/detached/backgrounded document (e.g. PDF, HTML) renderers. ==Strawman API== What follows is a proposed API that fits the requirements. Note that another route would be to attempt a mostly-compatible extension of Mozilla’s existing pageshow and pagehide events, which would not necessarily be perfectly backwards compatible. =document.visibility= A read-only property that returns a string, one of: * “visible” : the tab is focused in its window * “hidden” : the tab is backgrounded within its window Foremost, this makes more assumptions about the window management of the target system. Also, why would it be useful to know the focus of a tab inside of a window which may or may not be focused itself? =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibility just before it was changed to the current value. Note that visibility has nothing to do with whether the document’s contents have fully loaded or not, which implies that for any given visibility transition event, onload may or may not have already fired. A property of visibilitychanged that hints at whether the program will continue executing or not.
[whatwg] Websockets
Hi all, I guess a lot of people are asking the question but, what is the state on the following: http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ Apparently this is the case in Opera as well. --- Kind Regards, Schalk Neethling Passionate Web Developer
Re: [whatwg] Websockets
* Schalk Neethling wrote: I guess a lot of people are asking the question but, what is the state on the following: http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ Apparently this is the case in Opera as well. This is an announcement from today, so in all likelyhood nothing has changed about the state since the announcement. There is nothing new here; that there is software out there that treats port 80 traffic as HTTP traffic even if you don't want it to has been known for a couple of years. So long as Websocket goes over port 80 you have to either shout please don't treat this as HTTP!! down the tube and hope for the best with varying levels of confidence depending on what it is that you are shouting, or you can make the Websocket protocol such that no harm can come from the software not listening to your shouting. The news here is that some people looked at some simple forms of shouting and found that those simple forms of shouting aren't perfect. There are many proposals for shouting and making the protocol such that shouting is unnecessary that are being discussed in the IETF hybi Working Group. What will become of that, or when that will arrive, is anyone's best guess. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Proposal for a tab visibility API
On Wed, Dec 8, 2010 at 2:47 PM, Alex Komoroske komoro...@chromium.org wrote: =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. Should be visibilitychange rather than visibilitychanged, to match change, cuechange, durationchange, formchange, ratechange, readystatechange, and volumechange (I didn't expect so many . . .). On Wed, Dec 8, 2010 at 2:57 PM, Boris Zbarsky bzbar...@mit.edu wrote: 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. That sounds like it would probably eclipse all other use-cases in popularity. More sites have ads with timers on them than contain puzzle games or poll for dynamic content. Is there any way for browsers to dodge this while still serving the other use-cases? Or do we just figure that users can just leave the site or do per-site blocking if it gets too annoying, so it's not a big problem?
Re: [whatwg] Proposal for a tab visibility API
Am 08.12.2010 21:40 schrieb Bjartur Thorlacius: On Wed, 08 Dec 2010 19:47:34 -, Alex Komoroske In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, Minor semantic nitpick: please use the term /does not have focus/ rather than /is a background tab/, as the latter is misleading in window managers that don't use tabs to represent (all) windows. [Ninja'd] I am not too much familiar with the terminology here, but I humbly think that not having focus does not necessarily mean a window is not visible. I often have more than one visible window; maybe one where I am currently working, and another one at the side with a football game streamed or whatever. I wouldn't like the football stream to be stopped when this window looses focus. But when the stream gets totally hidden, be it that I open a new tab in the same window, or place some other window in front of it, the streaming application might want to save bandwidth by pausing the streaming of the visuals, while streaming on the audio. Thus, I'd consider an api for detecting the visibility state of every HTML element useful (totally visible, partially visible, hidden - or a percentage value).
Re: [whatwg] video loading algorithms
On Tue, 3 Aug 2010, Boris Zbarsky wrote:
On 8/2/10 5:20 PM, Ian Hickson wrote:
Or does stop the currently running task in #spin-the-event-loop
imply a jump to step 2 of the algorithm under #processing-model2?
Yes.
OK, that might be worth clarifying.
Done.
(Note: I still have a problem with the way pause is defined here,
but I've raised that before, I believe.)
I think we all have a problem with pause, but I don't know what we
can do about it. I don't have any pending feedback from you on this
topic, as far as I can tell.
Odd. I definitely sent something about it (in particular that it
doesn't seem very easily implementable in terms of network event
behavior, if the pause is waiting on a network event and other network
events need to not be delivered in the meantime).
The pause thing is never invoked when waiting for network behaviour on
the same event loop. (That wouldn't work, as you point out.)
On Wed, 4 Aug 2010, Chris Pearce wrote:
On 4/08/2010 11:32 a.m., Ian Hickson wrote:
In the case of a tasks which invokes an algorithm which has a
synchronous section, and then pauses the event loop (such calling
window.alert()), we should not run the synchronous section until the
event loop pause has completed?
Currently, yeah. We might want to make pause also trigger
synchronous sections, if that's a problem.
Having pause trigger synchronous sections is definitely easier for us
to implement, and would make pausing the event loop consistent with
spinning the event loop WRT synchronous sections.
Ok, done.
On Wed, 4 Aug 2010, Philip Jägenstedt wrote:
On Tue, 03 Aug 2010 17:40:33 +0200, Boris Zbarsky bzbar...@mit.edu
wrote:
On 8/3/10 4:27 AM, Philip Jägenstedt wrote:
For the record, here's how I interpreted await a stable state:
The only state that is not stable is a running script.
I don't think that's true; for example you could be in an unstable
state if you're in the middle of the parser inserting some nodes into
the DOM.
If the parser running in considered an unstable state, then we would
have to wait until the whole document has finished parsing before
running the resource selection algorithm.
No, the parser is defined in terms of tasks and its interaction with the
event loop (including what is a stable state) is defined.
Thus, video would be unnecessarily delayed in a way that img isn't.
Actually img waits for much the same thing. :-) (Its rendering is
updated when the event loop spins, which is around the same time as what
is called a stable state.)
Therefore, when reaching that step, if the resource selection
algorithm was triggered by a script, wait until that script has
finished and then continue.
Per spec as currently written, this will give the wrong behavior.
For example, if the script in question calls showModalDialog, this is
supposed to interrupt the script task and spin the event loop, and so
your synchronous section would need to run while the modal dialog is
up. It doesn't sound like your implementation does that.
That could be, but is this behavior actually useful for anything? It's
certainly simpler to implement and more predictable for authors to
always wait until the current script has finished executing.
Consider trying to play a sound in the background while the dialog is up,
for instance.
On Tue, 24 Aug 2010, Philip Jägenstedt wrote:
[Step 3 of the Otherwise clause at the end of the An end tag whose tag
name is script section of The text insertion mode.]
Should this step be read as
while (there is no style sheet blocking scripts and the script's ready to be
parser-executed flag is set) {
Spin the event loop
}
or
do {
Spin the event loop
} while (there is no style sheet blocking scripts and the script's ready to
be parser-executed flag is set)
It was meant to be the former. I've fixed it.
In other words, will the synchronous section always be executed?
Not in between one script and a script that was document.write()ten by
that script, no, not always.
I think I meant to say that it if the synchronous section has run
depends on whether or not the parser happened to return to the event
loop before the script. In other words, networkState could be
NETWORK_NO_SOURCE, NETWORK_EMPTY or NETWORK_LOADING here. Hopefully all
my conclusions are incorrect and there's actually a guarantee that the
synchronous sections runs before any scripts execute, see above.
There is not such a guarantee.
On Thu, 26 Aug 2010, Silvia Pfeiffer wrote:
On Tue, Aug 24, 2010 at 6:24 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 24 Jul 2010, Silvia Pfeiffer wrote:
There is definitely a spec bug, because different locations of the
spec say diverging things.
For the record, when the spec contradicts itself, and one part is
normative (such as the algorithm here) and another is non-normative
Re: [whatwg] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Wed, 18 Aug 2010, Silvia Pfeiffer wrote: On Wed, Aug 18, 2010 at 11:13 AM, Ian Hickson i...@hixie.ch wrote: Agreed. I've made the API clearly say that duration is the time at the end, even in the case where the start is not actually zero, to sidestep this issue somewhat. (The start will almost always be zero, so the slightly misleading name seems like a non-issue.) It's a shame we are using the word duration instead of the more appropriate word endTime for this. Would it be too difficult to change it at this time? For most people it'll be a duration. I don't think it's a big deal. On Mon, 23 Aug 2010, Philip Jägenstedt wrote: It's too late, all scripted controls for video that display a timeline are already using the duration property. On Mon, 23 Aug 2010, Chris Double wrote: And they're probably using it as a duration not an end time. Doesn't this change cause problems? I don't see how why they would. The only time it makes a difference is if they have a non-zero starting time, and they'd have to handle that too (using .initialTime). It's unlikely that someone will use .initialTime correctly, but .duration incorrectly, IMHO. Also if they do use it incorrectly the mistake will probably be pretty obvious. :-) On Mon, 23 Aug 2010, Philip Jägenstedt wrote: It can't in Opera, since currentTime will always start at 0 (modulo bugs). Is there any browser that really intends to let currentTime start at an offset, and why? That's a good question; if .initialTime is always going to be zero then we will likely just drop it. If so, I suppose that the seek knob will start somewhere in the middle and that any attempt to seek to before that point will just seek to that non-zero offset. That's a pretty weird UI and one reason I think the timeline should always be normalized, whatever the timestamps or other metadata of the resource itself says. The UI would be the same either way -- instead of 0..10 it would just 5..15 or some such. DVRs use this kind of UI a lot, for instance when they show the real time of the video on their seek bar. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for a tab visibility API
On 12/8/10 5:29 PM, Markus Ernst wrote: Thus, I'd consider an api for detecting the visibility state of every HTML element useful (totally visible, partially visible, hidden - or a percentage value). This is pretty hard to implement, in general. For example, if I put another window over the browser window then whether the content in the browser is visible depends on the exact app running in that window, and on the parts of it overlapping the browser content, right? -Boris
Re: [whatwg] video loading algorithms
On Mon, 26 Jul 2010, Silvia Pfeiffer wrote: I now wonder about the intention of play() (and also of pause()). As I understood it, they are both meant to reload the media resource if @currentSrc has changed, similar to what load() is supposed to do. I do not believe that has ever been the intent. Both descriptions of play() and pause() have a loading the media resource in them. Yes, but not for the purpose of reloading, only for the purpose of loading the resource in the first place. I assumed that if the @currentSrc had changed, that would trigger loading the new media resource, too. If that is not the intention, maybe the non-normative description should point out that it only triggers loading the media resource when the @src attribute is being set for the very first time. Well that's not quite accurate either... it does it if the networkState is NETWORK_EMPTY, which can happen in a variety of conditions. I'm open to changing this text (from if necessary which is what it says now) but I really don't know what to change it to that would be both accurate and helpful. Though, to be honest, I don't really see a difference between setting @src through JavaScript for the first time (which IIUC also has a NETWORK_EMPTY state) and re-setting it again a subsequent time - IMHO both should consistently either include the media resource loading or exclude it. The difference is that the first time there's nothing loaded, so to play() anything you have to load it, whereas the second time there's already something loaded, which play() can just play straight away without having to load anything first. On Tue, 27 Jul 2010, Silvia Pfeiffer wrote: Sure, but this is only a snippet of an actual application. If, e.g., you want to step through a list of videos (maybe an automated playlist) using script and you need to provide at least two different formats with source, you'd want to run this algorithm frequently. Just have a bunch of videos in the markup, and when one ends, hide it and show the next one. Don't start dynamically manipulating source elements, that's just asking for pain. If you really must do it all using script, just use canPlayType and the video src= attribute, don't mess around with source. Thanks for adding that advice. I think it's important to point that out. I can add it to the spec too if you think that would help. Where would a good place for it be? There is a note in the source element section that reads as follows: Dynamically modifying a source element and its attribute when the element is already inserted in a video or audio element will have no effect. To change what is playing, either just use the src attribute on the media element directly, or call the load() method on the media element after manipulating the source elements. Maybe you can add some advice there to use canPlayType to identify what type of resource to add in the @src attribute on the media element. Also, you should remove the last half of the second sentence in this note if that is not something we'd like to encourage. Cheers, Silvia.
Re: [whatwg] Video with MIME type application/octet-stream
Long story short: I haven't changed the spec where it talks about video, source type, Content-Type, and direct file inspection for type determination. My plan is to just wait and see what browsers do and update the spec accordingly in due course. This is mostly because we clearly have a wide range of opinions regarding what the right behaviour is, implementations are still changing, and implementors often disagree with their own implementations at this stage. On Tue, 31 Aug 2010, Boris Zbarsky wrote: On 8/31/10 3:36 AM, Ian Hickson wrote: You might say Hey, but aren't you content sniffing then to find the codecs and you'd be right. But in this case we're respecting the MIME type sent by the server - it tells the browser to whatever level of detail it wants (including codecs if needed) what type it is sending. If the server sends 'text/plain' or 'video/x-matroska' I wouldn't expect a browsers to sniff it for Ogg content. The Microsoft guys responded to my suggestion that they might want to implement something like this with what's the benefit of doing that?. One obvious benefit is that videos with the wrong type will not work, and hence videos will be sent with the right type. If the question is what the benefits of that are, one is that the view video in new window context menu option actually works. Another benefit is that you can send someone the link to the video, instead of the embedding page, and it will work. Another is that when you save the video to disk the browser will fix up the extension correctly, if needed. I think that they would argue that these should work either way, with the same sniffing being used to ensure it works in all of these places. It seems that sniffing is context-sensitive. Yes, but one issue is that we really do want resources to be usable outside the context the page happens to want to put them in. The ship has sailed on img, clearly, and is working on sailing on video, but I feel that the behavior IE and Chrome are implementing here is highly detrimental to the web. Not that they care much. Sadly, the boat has sailed for text/html and XML at this point, but for binary types, and for contexts where text/plain isn't a contender, why bother doing anything but sniff? See above. As long as some contexts are sniffing and some are not, we have a problem. If it were all-sniff (with the same algorithm across the board!) or all-not-sniff, we might be ok. I could go either way, but I think the road to all-sniff is less steep. On Tue, 31 Aug 2010, Boris Zbarsky wrote: On 8/31/10 9:57 AM, Anne van Kesteren wrote: If the question is what the benefits of that are, one is that the view video in new window context menu option actually works. If you sniff you can sniff there too. Not really, since it's just rendering in a toplevel browser window. Or rather... one could, but sniffing or not depending on something other than the state of the url bar and the server response in toplevel browser windows is extremely poor UI. I'm not sure I follow. It works fine for sniffing JPEGs sent with the wrong type; why wouldn't it work for videos too? Another benefit is that you can send someone the link to the video, instead of the embedding page, and it will work. If you sniff you can sniff there too. (Unless that user uses a competitor's browser, but that would be an incentive to encourage that user to use the sniffing browser.) You can't sniff in a toplevel browser window. Not the same way that people are sniffing in video. It would break the web. How so? On Tue, 31 Aug 2010, Aryeh Gregor wrote: If you can't come up with any actual problems with what IE is doing, then why is anything else even being considered? Because a number of people I respect, such as Boris, who also happen to have more influence than I, since they are implementors, would rather we not determine types based on leading byte comparisons but on the MIME type. There's a very clear-cut problem with relying on MIME types: MIME types are often wrong and hard for authors to configure, and this is not going to change anytime soon. Certainly it won't change if we have any sniffing going on. :-) Sadly, the boat has sailed for text/html and XML at this point, but for binary types, and for contexts where text/plain isn't a contender, why bother doing anything but sniff? If this is your position, why doesn't the spec match it? The spec doesn't reflect my position. It would be quite different if it did. :-) It reflects what can be implemented interoperably within the constraints put forward by implementors. On Tue, 31 Aug 2010, Boris Zbarsky wrote: On 8/31/10 3:59 PM, Aryeh Gregor wrote: On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarskybzbar...@mit.edu wrote: You can't sniff in a toplevel browser window. Not the same way that people are
Re: [whatwg] toDataURL image/jpeg composition
On 12/8/2010 12:13 AM, timeless wrote: On Fri, Dec 3, 2010 at 1:06 AM, Charles Pritchardch...@jumis.com wrote: Currently, Firefox and Safari output image/jpeg in a way that differs from the spec: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11431 is there a reason you haven't found/filed bugs in bugzilla.mozilla.org/bugs.webkit.org? WebKit has had a bug standing for awhile. I've pinged their mailing list. IE9 exhibits behavior per specs. The appropriate Mozilla coders are active on this mailing list, and this may be a policy decision, opposed to defect. Chromium has gone forward with the non-standard behavior seen in Firefox. Either it's a spec change, or Mozilla/Safari should change their behavior. On that note: was the following resolved? https://bugs.webkit.org/show_bug.cgi?id=39177 Oliver's response wasn't much help. My prior understanding was that this issue was resolved, by changing the spec, and FF changing its behavior to match.
Re: [whatwg] Fullscreen feedback
(This e-mail only contains responses to the one brief part of the full- screen API feedback that apply to the spec(s) I'm working on; I believe Anne has stated an intent to specify an API for actually supporting fullscreen display of Web content and I have not responded to feedback that would be appropriate for that spec. In case it is helpful to Anne, I've included below the feedback to which I did not include responses.) On Fri, 20 Aug 2010, Mike Wilcox wrote: On Aug 20, 2010, at 3:24 PM, Ian Hickson wrote: By CSSOM, I mean a separate specification, specifically one from the family of specifications that Anne is working on ...though my understanding is that Anne doesn't have the bandwidth to take this on right now (this may be less of a problem if Robert's proposal can just be taken wholesale, though). RE: Fullscreen - I would be happy if the warning text was removed: User agents should not provide a public API to cause videos to be shown full-screen. It appears the warning is no longer present. Did I just miss it? The other feedback was as follows (trimmed to remove non-material feedback, process discussion, and redundant quoting): On Fri, 20 Aug 2010, Adam Barth wrote: On Fri, Aug 20, 2010 at 7:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Aug 21, 2010 at 8:24 AM, Ian Hickson i...@hixie.ch wrote: One comment: Rather than adding an allowfullscreen attribute on iframe, I would suggest just assuing that sandboxed content (i.e. content of iframes with the sandbox= attribute) can't go fullscreen. I can provide a sandbox flag for this state. If we think there are use cases for allowing sandboxed iframes to go fullscreen, then I can also add a keyword that turns off the flag when present (like allow-scripts does for scripts). (I'm assuming there are no cases for disabling fullscreen for unsandboxed iframes; are there?) What about legacy content that doesn't use sandbox? It might expect cross-origin IFRAMEs to not be able to take over its window, but if the IFRAME content goes fullscreen, it effectively can. I think allowing subframes to go fullscreen should always be opt-in. How is going fullscreen different from opening a popup window? On Sat, 21 Aug 2010, Kit Grose wrote: It's the same document *in the same state* as it was in when you triggered fullscreen. You would expect fullscreen on a video or animation not to start that video or animation from the beginning or reload it. On Fri, 20 Aug 2010, Adam Barth wrote: I meant from a security model perspective. :) On Sat, 21 Aug 2010, Robert O'Callahan wrote: That depends on how the UA chooses to handle it. But this proposed fullscreen API is based on the idea that the fullscreen content takes over the toplevel browsing context to which it belongs. (The content is styled to fill the IFRAME, and the IFRAME element is styled to fill the parent document's viewport.) On Sun, 22 Aug 2010, Adam Barth wrote: On Sun, Aug 22, 2010 at 8:00 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Aug 22, 2010 at 4:12 AM, Adam Barth w...@adambarth.com wrote: That does seem dangerous if the location bar still displays the URL of the top-level browsing context because it violates the constraint principle of display delegation. That's why I want to default to prohibiting subframe content from going fullscreen. Yeah, I agree that we'd need something like that in this model. It's unfortunate though. Won't folks package video widgets using iframes? I guess they'll need to include this silly attribute in their copy-and-paste this markup code in order for full screen to work. This doesn't seem like a good model for full-screen. �I would think the model of re-parenting the content to a popup window that fills the entire screen would be a better model. I think that model is a lot harder to spec and a lot harder for Web authors to understand. I'd certainly be interested in looking at a proposal if someone wants to pursue that approach. There's been some work in WebKit around the concept of a magic iframe that keeps it's environment intact even when it's adopted from one document to another. I'm not sure how much of that has been discussed for standardization, but you could imagine a model like that working where a frame is adopted into a popup window that fills the screen. On Mon, 23 Aug 2010, Robert O'Callahan wrote: That's sorta-ok if your video is a subframe that you treat as a black box. But if your video element is just an element in your page with event handlers attached to it, and with various scripts that interact with it, and you rip that element out (plus maybe some supporting elements representing your player UI) and drop it in another document, it seems to me you're going to have to code very carefully to ensure it keeps working over there (and the original page doesn't
Re: [whatwg] video resource selection algorithm and NETWORK_NO_SOURCE
On Wed, 1 Sep 2010, Simon Pieters wrote: I think it might be good to run the media element load algorithm when setting or changing src on source (that has a media element as its parent), but not type and media (what's the use case for type and media?). However it would fire an 'emptied' event for each source that changed, which is kind of undesirable. Maybe the media element load algorithm should only be invoked if src is set or changed on a source that has no previous sibling source elements? What's the use case? Just set .src before you insert the element. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Html 5 video element's poster attribute
On Sun, 19 Sep 2010, Shiv Kumar wrote: I'd like to see the implementation of the poster attribute change to something that is more useful. By useful I mean something that wroks without the need for javascript and works the way most people would expect. Currently the poster disappears as soon as the first frame has been downloaded, which typically takes a second. This is an implementation choice; the spec allows either the poster to be used or the first frame. This is to allow the browser to use the poster frame until playback begins, but to then use the first frame if the user seeks back to the start of the video. The poster should not show while the player is seeking (some browser implementation do show the poster while seeking, resulting a flashes) That's an implementation bug. The spec doesn't allow that. The poster should show again after the video has ended. Why? The visibility of the poster should be scriptable and/or controllable using an attribute. Meaning that one should be able to turn on/off the poster (without changing the poster attrbute's value) What's the use case for this? On Mon, 20 Sep 2010, Silvia Pfeiffer wrote: | When a video element is paused and the current playback position is | the first frame of video, the element represents either the frame of | video corresponding to the current playback position or the poster | frame, at the discretion of the user agent. The first half of the either...or... statement is really annoying and should be removed. That would be annoying in a different way -- it would mean you couldn't seek back to the start of the video and see the first frame. We could make the spec more precise and require that a particular behaviour occur before playback has ever happened and another after playback has ever happened, but in practice I think that there is only one behaviour that is useful and desireable enough that all browsers will implement it, and we don't gain much by making the other more esotecir behaviours non-conforming for those few people who would prefer it the other way. (In general it is considered bad form to require particular UI unless there is a strong reason to do so.) On Sun, 19 Sep 2010, Monty Montgomery wrote: If the default action is to redisplay the poster, the other possibilities are available via trivial scripting (remove it or even replace it with a different poster after we start playing). If the poster does not redisplay and the content presenter wants it to, we're back into scripting an entire control system from scratch, as overlaying a div/image [to get the poster back] hides the native controls and makes them inaccessable again. The default behaviour without script should be the most useful behaviour, not the behaviour that can most easily be turned into another behaviour with script. On Mon, 20 Sep 2010, Zachary Ozer wrote: I'd like to weight in quickly on this based on feedback from our users on this (they have a lot). * Webkit's original implementation (show the first frame once it's available) is requested by a lot of people. What they don't realize is that the first frame is black for 99% of videos, so they end up using the poster anyway. We've resisted this because of limitations in Flash (you have to start loading the video, then call play() and pause() on the first frame), but I'd say it's still a good idea to display the first frame if there's no poster set and preload is set to auto (or add another preload level for poster). This seems consistent with the spec's requirements. * Don't show the poster when the video buffers - just pause the video and give some visual indication that you're buffering. This also. * We've never had anyone request different poster images for begin / pause / end. People generally just want it to appear at the beginning and end, and they want the same image. If someone wants to change it, allow them to set the poster attribute via JavaScript. I'm not aware of people wanting to have it appear at the end -- this never came up in the study of use cases. Can you elaborate on this? Are there examples of sites that do this today? It seems like you could just put the end poster frame in the last frame of view instead. * Don't clear the poster on load(). A lot of people get confused by this. It might make sense to clear it in the setter for video src, but I could see this confusing people as well. Not sure what this is referencing. * I'm not sure how reset() would work. Would you reset the list of source too? What is reset()? On Sun, 19 Sep 2010, Shiv Kumar wrote: First I do want to make clear that it's not about being able to do things via script, but rather declaratively via attributes to the extent possible. At least that's the way I feel Html should be. That is, to the extent possible, Html should be self sufficient, without requiring JavaScript to
Re: [whatwg] Html 5 video element's poster attribute
Apologies for top posting; I'm on my phone. One case where posters come back after playback is complete is when there are multiple videos on the page, and only one has playback focus at a time, such as a page of preview movies for longer ones to purchase. In that case, showing the poster again on blur makes sense conceptually. It seems that getting back into the pre-playback state, showing the poster again would make sense in this context. That would imply adding an unload() method that reverted to that state, and could be used to make any cached media data purgeable in favour of another video that is subsequently loaded. On Dec 8, 2010 6:56 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 19 Sep 2010, Shiv Kumar wrote: I'd like to see the implementation of the poster attribut... This is an implementation choice; the spec allows either the poster to be used or the first frame. This is to allow the browser to use the poster frame until playback begins, but to then use the first frame if the user seeks back to the start of the video. The poster should not show while the player is seeking (some browser implementation do show t... That's an implementation bug. The spec doesn't allow that. The poster should show again after the video has ended. Why? The visibility of the poster should be scriptable and/or controllable using an attribute. Mea... What's the use case for this? On Mon, 20 Sep 2010, Silvia Pfeiffer wrote: | When a video element is paused and the current p... That would be annoying in a different way -- it would mean you couldn't seek back to the start of the video and see the first frame. We could make the spec more precise and require that a particular behaviour occur before playback has ever happened and another after playback has ever happened, but in practice I think that there is only one behaviour that is useful and desireable enough that all browsers will implement it, and we don't gain much by making the other more esotecir behaviours non-conforming for those few people who would prefer it the other way. (In general it is considered bad form to require particular UI unless there is a strong reason to do so.) On Sun, 19 Sep 2010, Monty Montgomery wrote: If the default action is to redisplay the poster... The default behaviour without script should be the most useful behaviour, not the behaviour that can most easily be turned into another behaviour with script. On Mon, 20 Sep 2010, Zachary Ozer wrote: I'd like to weight in quickly on this based on feedba... * Webkit's original implementation (show the first frame once it's available) is requested by a lot of people. What they don't realize is that the first frame is ... (you have to start loading the video, then call play() and pause() on the first frame), but I'd say it's still a good idea to display the first frame if there's no p... This seems consistent with the spec's requirements. * Don't show the poster when the video buffers - just pause the video and give some visual i... This also. * We've never had anyone request different poster images for begin / pause / end. People gen... and end, and they want the same image. If someone wants to change it, allow them to set the poster attribute via JavaScript. I'm not aware of people wanting to have it appear at the end -- this never came up in the study of use cases. Can you elaborate on this? Are there examples of sites that do this today? It seems like you could just put the end poster frame in the last frame of view instead. * Don't clear the poster on load(). A lot of people get confused by this. It might make sens... Not sure what this is referencing. * I'm not sure how reset() would work. Would you reset the list of source too? What is reset()? On Sun, 19 Sep 2010, Shiv Kumar wrote: First I do want to make clear that it's not about being... The goal isn't to make HTML declarative to the extent possible, but to make it declarative for the most common 80% of use cases. As regards having control over the poster's visibility using attributes/script, the use case ... producers frequently want us to show the poster after the video has ended. It seems clear that they can play it again if they want to... why would they not be able to? Do you have an example of a site I can use that does this? I'm curious to study this kind of UI. Seeing that there is no way to show it again (after it has disappeared) I think that there sh... any use for the poster attribute if one wants to turn on the poster. I don't really see why one would want to turn on the poster. What's the use case? Yes, I know one can assign/un-assign the poster attribute. But really is that how we see func... even this solution will not make the poster visible when required (or when desired). If you want to change the poster, changing the poster= attribute seems like a perfectly reasonable way to do it. On Sun, 19 Sep 2010, Robert
Re: [whatwg] Video with MIME type application/octet-stream
On 12/8/10 8:19 PM, Ian Hickson wrote: You can't sniff in a toplevel browser window. Not the same way that people are sniffing invideo. It would break the web. How so? People actually rely on the not-sniffing behavior of UAs in actual browser windows in some cases. For example, application/octet-stream at toplevel is somewhat commonly used to force downloads without a corresponding Content-Disposition header (poor practice, but support for Content-Disposition hasn't been historically great either). (Note that the spec as it stands takes a compromise position: the content is only accepted if the Content-Type and type= values are supported types (if present) and the content sniffs as a supported type, but nothing in the spec checks that all three values are the same.) Ah, I see. So similar to the way img is handled... I can't quite decide whether this is the best of both worlds, or the worst. ;) It certainly makes it simpler to implement video by delegating to QuickTime or the like, though I suspect such an implementation would also end up sniffing types the UA doesn't necessarily claim to support so maybe it's not simpler after all. -Boris
Re: [whatwg] Proposal for a tab visibility API
On 12/8/10 5:55 PM, Alex Komoroske wrote: 1) background tab is pretty narrow. Minimized windows, windows that aren't on the current desktop, etc, have all the same problems. In general this can be very challenging to do correctly, as you allude to, and others later in the thread mention. What about windows on a second monitor that are partially obscured by another window? Fully obscured? I explicitly left those out of my list, yes, because they are rather difficult to detect. This initial API aims to allow developers to detect the obvious cases where they are guaranteed that their content is not visible at all. There is no such guarantee for background tabs. For example, browsers may show tab previews in various contexts (Panorama in Firefox 4, e.g.). 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. I'd really appreciate some comment on this. I'm pretty worried about adding features that we then have to start working around people abusing almost immediately... -Boris
Re: [whatwg] Proposal for a tab visibility API
On Dec 8, 2010, at 11:47 AM, Alex Komoroske wrote: Hi all, On the Chromium team we’ve identified a couple of use cases that we’d like to address with a simple API, and we’d love your feedback. In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, although some heuristics do exist (like detecting mousemove events). In the future, there may be cases where such detection is even more important, for example in the prerendering feature (http://code.google.com/p/chromium/issues/detail?id=61745) that Chromium is currently in the early stages of experimentation with. ==Use cases== * A streaming video site doesn’t want to start the video until the user actually views the tab for the first time (i.e. video shouldn’t start automatically if a user opens the tab in the background). This use case can be handled without help from the page. In Safari, video (whether through media elements or plugins) won't start playing when a user opens a tab in the background, until the user switches to that tab. * A page wants to detect when it is moving into or out of the back-forward cache. This use case is already handled with events specific to the back/forward cache (pagehide and pageshow). That leaves the following use cases: * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. * A page wants to detect when it is being prerendered so it can behave appropriately. I am not sure what the third needs exactly, but it seems like first two could be better served with an API that sets a timer which will only fire when the page is visible. That kind of API might be easier to use right, and avoids the need for JS to run when switching tabs, just to cancel and restart timers. Also I wonder if pagehide and pageshow could be broadened to help the prerendering use case. It seems a bit speculative to make API just so Web pages can find out about an experimental feature being used. Regards, Maciej With these use-cases in mind, there are a number of requirements. ==Requirements== * Easy for developers to write scripts that fall back on old behaviors for browsers that do not implement this API * Ability to query the document’s current visibility state * Events fired when the document transitions between visibility states * Ability for browser vendors to add new visibility states in the future ==Strawman API== What follows is a proposed API that fits the requirements. Note that another route would be to attempt a mostly-compatible extension of Mozilla’s existing pageshow and pagehide events, which would not necessarily be perfectly backwards compatible. =document.visibility= A read-only property that returns a string, one of: * “visible” : the tab is focused in its window * “hidden” : the tab is backgrounded within its window * “prerender” : the tab is currently being loaded in an off-screen tab, and may never be shown to the user. * “cache” : the tab is currently in the back-forward-cache. Note that in Mozilla’s current implementation, document.visibility would never actually be “cache” because Javascript cannot execute when in the cache. In the future, the list of possible values may be extended. Of these states in this list, all except “visible” are considered to be hidden. Developers can use the existence of this property to know that they can rely on the rest of this API, too. =document.isVisible= A simple convenience read-only property that returns a boolean. Returns true if document.visibility’s current value is in the set of visibility states considered to be visible (for the first iteration of this API, that would only include the “visible” state). =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibility just before it was changed to the current value. Note that visibility has nothing to do with whether the document’s contents have fully loaded or not, which implies that for any given visibility transition event, onload may or may not have already fired. Thoughts or comments are welcome. --Alex Komoroske
