Re: [whatwg] Full screen for the video element
At 23:39 -0500 25/10/07, Greg Houston wrote: Roughly, one solution might be: The user is playing a video within a web page. They click on full screen mode. You are describing something initiated by user action, which any browser is quite free to support. But if that user action is mediated through HTML, or the fullscreen request originates in the HTML, the position is rather harder. What you write below is only 'obviously' an embedded video for a few seconds, alas. But the question remains: should we provide standard markup to do fullscreen, since most browsers will provide an extension to do it anyway, or not? And if so, how much do we say about the security issues (and what)? And if not, how do we still need to say about the security issues for browsers that do it anyway through UI, extension, or both? The toolbar, status bar, menu bar, and so forth are removed, leaving just the title bar and close, minimize, and restore controls. If there is no movement of the mouse for 2-5 seconds the title bar disappears. With movement of the mouse again, the title bar reappears. If the user clicks on the close control, the window returns to its original state while continuing to play the video within the page. Also, If the video comes to an end the window returns to its original state. If you don't want the title bar to control closing full screen mode, the browser could display a special video bar during full screen mode directly underneath the title bar. This bar could have play controls on it. Again, the video bar (as well as the title bar) would disappear after so many seconds of no mouse movement. In addition to redisplaying the title bar (and potentially the video bar) on mouse movement, it might be helpful to have a way to overlay play controls (pause, stop, and so forth) on top of the video at this time giving the designer a way to add those controls or supplement those that would be in the video bar if the video bar was implemented. Standard hotkeys in full screen mode might be nice, e.g., space bar (play, pause). With javascript it is already possible to make full screen web pages. If advertisers were going to exploit this they would have by now. Standardizing full screen video mode seems like a good idea since users will learn what to expect and how to navigate it. Otherwise, you potentially have a 1000 different implementations of fullscreen mode devised by designers requiring the end user to figure out each time how to navigate that particular implementation. On 10/25/07, Jonas Sicking [EMAIL PROTECTED] wrote: Dave Singer wrote: At 19:50 -0700 25/10/07, Jonas Sicking wrote: Dave Singer wrote: At 0:48 + 26/10/07, Ian Hickson wrote: On Sat, 13 Oct 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) Yep, that's a problem. I was also thinking along the lines of allowing fullscreen() within non-synthetic event handlers, in a similar fashon to popups (just like Kornel suggested). Given how often popups are abused today even with those requirements, I hesitate to do this. (Can you imagine if every time you clicked a link to go to a new site, a full-window or full-screen advert played?) If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). But you don't need to tell the browser that explicit confirmation is required; you merely need to say that, if the browser supports fullscreen requests (and it may ignore them), it must be clear to the user that the screen is 'filled' with the video and not his normal desktop. Yes, a dialog before is one way, but so is, for example, a blinking red 10-pixel border around the screen that says security warning! do not treat as desktop! continuously. There are (I hope) better designs. :-) i.e. state the requirement, not the solution. I just can't think of a solution that doesn't fall into at least one of these categories: 1) Some sort of user-confirmation that most users will not understand (such as the dialog) 2) Uses annoying ugly UI that will make no sites want to use it (such as a blinking red border) 3) Is unsafe 4) Will be annoying since advertisers are going to abuse it. You may be right. But a lack of imagination on my part may not be a good reason to leave out the feature,
Re: [whatwg] When to stop video elements from playing
On Fri, 19 Oct 2007, Robert O'Callahan wrote:
Suppose a script creates a video element, adds it to the document,
starts it playing, then removes the element from the document and drops
all references to it. When should the element stop playing?
I've made the spec say that it stops playing when you remove it from the
document. However, that doesn't really mean much, it can still play when
it's out of the document.
-- when all JS references to the element have been dropped (and garbage
collection runs)?
-- when the user leaves the page?
-- when the end of the stream is reached? (which could be never)
I've explicitly addressed all of these in the spec.
On Thu, 18 Oct 2007, Maciej Stachowiak wrote:
However, you'd probably want audio elements to be able to play outside
the document.
Indeed, that's an important use case.
On Fri, 19 Oct 2007, timeless wrote:
I can easily have a bookmarklet that goes through the dom tree and stops
(or stops and deletes) all audio elements. I can't have such a
bookmarklet for things that are only reachable via JS scope (and I don't
mean JS object graph, I mean function call chains, since that's the best
way to be evil, site's don't need to let people have access via object
properties).
Bookmarklets are effectively browser-specific and thus interoperability
isn't a concern for them. They can use UA-specific extensions if needed.
On Fri, 19 Oct 2007, timeless wrote:
On 10/19/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
This doesn't seem like something a typical end user would do.
the how perhaps not, but i think the goal is.
If a user wants to mute all audio, a mute key on the keyboard or in the
UA's chrome seems like the more likely solution, both of which are
possible within the constraints of the spec.
On Sat, 20 Oct 2007, dev wrote:
As a user , I would really prefer that the no Sound comes from the
browser, unless and until I can see a play/pause button inside the page.
So if the element is removed the sound and/or the video should stop.
This is what the spec now requires.
On Fri, 19 Oct 2007, Robert O'Callahan wrote:
A related question is whether display:none audio and video elements
should produce sound.
Yes. The sound from audio and video elements isn't stylistic; it's
asynchronously played content, and thus not affected by CSS properties.
My current opinion is that audio and video elements should behave
like img and load/play whether or not they're in a document, but they
should only emit sound if they're in a document with a presentation and
are not in a display:none subtree. Then to play a sound you'd have to
insert the element into your document somewhere with size 0x0 (which
should be the default for audio).
But it's a rather tangled issue.
Having to insert audio elements in the tree to have them play seems
artificial, especially since they wouldn't play where you put them -- the
tree position would be basically meaningless. A typical use case is the:
var a = new Audio('fx.wav');
a.autoplay = true;
...or similar.
On Fri, 19 Oct 2007, Anne van Kesteren wrote:
I think you want to do:
var soundeffect = new Audio(sound.wav)
soundeffect.onload = function() { this.play() }
which is what was possible with the old Audio API (became audio) Opera
implemented.
Right, that too.
On Fri, 19 Oct 2007, Robert O'Callahan wrote:
When would the Opera stop playing that sound? When the user left the
page? Only when the sound finished?
Per spec, at the earliest of the two. (Though in the former case, if the
user returned to the page and the bfcache hadn't flushed the message away,
the sound would resume playing.)
On Fri, 19 Oct 2007, Jonas Sicking wrote:
No. The time at which garbage collection will reclaim an object is
unpredictable, so relying on garbage collection for behavior is a bad
idea.
Agreed.
If we let videos or audios play even when out of the document I
don't see how we could avoid this.
The spec requires audible elements not to be garbage collected.
Or do you mean by 'play' only move forward in their time-position, not
emit sound?
Sound emission.
What happens in opera is if you do:
myAudio = new Audio(foo.wav);
myAudio.onload = function () {
this.play();
myAudio = null;
}
When will the audio stop playing?
Per spec, the element will play through to the end (or until the browsing
context is navigated away).
On Fri, 19 Oct 2007, Jonas Sicking wrote:
Opps, forgot to answer this one. I strongly feel that both audio and
video should make sound for display:none elements. The CSS display
property should only affect the visual appearance of the node.
Additionally, it's more efficient for us, and simpler for the author, if
hidden-but-played audio/video elements don't create a frame and don't
affect layout.
Agreed.
On Fri, 19 Oct 2007, fantasai wrote:
A related question is whether display:none
Re: [whatwg] Full screen for the video element
Greg Houston wrote: With javascript it is already possible to make full screen web pages. If advertisers were going to exploit this they would have by now. On my browser it is not. In firefox I can and do disable the ability for javascript to move or resize windows because web pages insist on annoying me by resizing to fullscreen. The only reason we don't disable this by default in firefox is that a lot of sites have come to depend on being able to resize windows. So lots of users are paying the price of annoying maximizing windows in order for us to support the few legitimate websites that resize windows. Had the resize api not been there in the first place those legitimate websites would have come to depend on it and would have worked fine. Lets not do the same mistake again. Standardizing full screen video mode seems like a good idea since users will learn what to expect and how to navigate it. Otherwise, you potentially have a 1000 different implementations of fullscreen mode devised by designers requiring the end user to figure out each time how to navigate that particular implementation. I imagine what will happen is that pages will create a video that covers the whole content area of the current window and then have some mechanism that minimizes the video again. I could see an argument for having an API that maximizes the video within the content area of the current window and adds some sort of browser specific UI to minimize it again. However, it isn't clear that sites will prefer that over having their users choose 'fullscreen' from the context menu (or whatever other UI the browser chooses to use). Actually, the more I think about it the more I like the idea of an API for fullwindow. What do other people think? / Jonas
Re: [whatwg] Gigantoredesignorrific changes to the Database API
On Oct 25, 2007, at 7:26 PM, Dimitri Glazkov wrote:
I like the operation structure, imposed by the new spec: (database
(transaction (statement (handler, and error callbacks are nice. A
couple of things stood out:
1) The transactions are now required and this seems like an
unreasonable performance hit. What if the API would assume transaction
mode, but would allow authors to explicitly state that the operation
is not a transaction:
db.operation(function(op) {
// implicitly a transaction
});
db.operation(function(op) {
// explicitly not a transaction, just a set of statements in one
context.
}, null, false /* states that this is not a transaction */);
.. or something along these lines.
I think we've established that with at least a few popular sql
implementations - if you use things correctly - wrapping single
statements in transactions does not affect performance in a critical
manner.
That consideration aside, having the Transaction as the basic work
unit in the API keeps things very clean and solves a lot of problems.
It implicitly helps with simultaneous access to the same database from
different browsing contexts (or even different processes) and it
simplifies both the API and implementations.
Also, there's nothing stopping web developers from running a single
statement in a transaction.
With the way Transactions are worked into the new API, I'm convinced
we don't need to add more API just to let a developer run a
transaction-less statement.
2) Fully asynchronous is scary. Are we sure this is going to be
well-digested? I can just see people doing this:
db.operation(function(tx) {
var count;
tx.executeSql(SELECT COUNT(*) AS C FROM BLAH;, function(r) {
count = r.item(0).c;
});
if (count 0) {
// do happy things.
}
});
I am very pleased that this entire API is designed around the fact
that synchronous I/O on the main thread is bad, and would argue
against any attempt to introduce synchronous I/O without an extremely
compelling argument.
I don't think unskilled/uninformed developers might use the API
incorrectly is compelling enough to change the design and give them
the power to do I/O on the main thread.
There are various JS libraries - some very popular - that make
challenging APIs easier to use, but I really don't think this one is
all that challenging!
3) I think I misunderstand step 11, help me out. If the commit has
failed once, why try to re-commit, even if the error callback
instructs you to?
Trying to commit a failed transaction twice won't result in any
negative side effects, but it's also probably not necessary.
If a way could be found to rewrite the Transaction Steps to work
around this, but still keep the steps clear and unambiguous, I would
be okay with that.
~Brady
Re: [whatwg] Couple comments on Database storage spec.
Ian Hickson wrote: I think not having quote will make people write their own, and every so often fail at it. People that don't think about the possibility of getting exploited aren't going to use neither '?' nor quote() so they are hosed either way. If we include examples for how to do this (embedding ? directly into the query and adding the stuff to the array), will that work? It's easier to do than quoting. It does sound like a good idea to make all examples use the '?' syntax. I still think that providing a quote() implementation would do more good than harm, but admittedly I don't care that much. Especially given that the worst that can happen is bugs and not security breaches. / Jonas
Re: [whatwg] When to stop video elements from playing
A couple of comments: The spec currently doesn't say to set the autoplaying flag to false when an element is removed from the Document. I take it that will mean that the element will start playing if it's currently waiting for data? This seems undesirable to me for two reasons: A) I think nodes not in the document should only start playing when more explicitly asked to. B) It creates a race condition where the element _will_not_ play when if enough data had been downloaded at the point when the element was removed, but _will_ play if it was still waiting for data. Is there any reason we couldn't state the removing the element from the Document calls pause() on the element? I think that it is still currently possible that a currently playing element can get garbage collected. Alternatively, that it is possible to create elements that will never stop playing, even if the user navigates away. Consider the following scenario: 1) Page A opens a new window containing Page B 2) Page A creates a reference to Page B 3) Page B creates an audio element that doesn't live in its Document and sticks it in a global variable of its context. 4) Window containing Page B is closed. Page B does not go away since Page A is holding a reference to it. 5) Page B calls .play() on the audio 6) Page A drops reference to Page B 7) Garbage Collection runs 8) User leaves Page A 9) Garbage Collection runs The only step here that is slightly suspicious is step 5 since a closed-but-alive page is running script. I believe this can happen in a number of ways, the simplest being that Page A calls a function on Page B. But I suspect there are also events that can fire in Page B even after it has closed. The question is, when does the audio element stop playing? If it stops playing in step 7 we still have the situation that it can stop running at a seemingly random point in time, i.e. when GC runs. Step 6 isn't necessarily even needed since both Page A and Page B would get destroyed in step 9 anyway. If we say that the audio should not get garbage collected in step 7 since it is playing audio, at what point should it stop playing? There is no connection between the audio and Page A so step 6 and 8 won't be special in any way to the audio. I believe the best solution here is to say that step 5 should throw an exception. I.e. you can't start playing a media element whose .ownerDocument is not a displayed document. Other suggestions welcome. / Jonas
Re: [whatwg] SQL API and changeVersion() with no callbacks
On Oct 26, 2007, at 3:23 PM, Ian Hickson wrote: On Thu, 25 Oct 2007, Brady Eidson wrote: For the sake of simplicity in the API, I see no reason why there couldn't be a single version of changeVersion() with the 2 strings and 2 callbacks. Then if a user truly wanted to call changeVersion() but wasn't interested in the results, they could just pass null for both of the callbacks. Very good point. I have removed the overloads here. This is not going to be frequently called, so why not require the callbacks. I suppose the same could be said about executeSql(). Well... I can certainly see people queuing up a bunch of requests and dealing with the errors at the end in the transaction error handler. I am open to requiring that that have an explicit null though. Who do other people think? I'm glad there's agreement on changeVersion() and that it has been changed. I wanted to raise the executeSql() point for discussion, not because I feel strongly about it. I agree that queueing up a bunch of queries then dealing with the error at the end is a realistic use case. ~Brady
Re: [whatwg] SQL API - SQLVersionChangeCallback vs SQLTransactionCallback
On Thu, 25 Oct 2007, Dimitri Glazkov wrote: I may be completely alone in this one, but is schema versioning as part of the API really a necessary thing? I mean, it's convenient, but is it necessary? Just trying to keep it simple. In particular with the offline stuff, it is highly likely that code will be running and interacting with the database in one window when a script tries to update the schema, and we don't want authors to have to implement some primitive locking facility of their own to prevent old versions corrupting the data. I think it's relatively light-weight yet provides something that could end up being really useful in certain cases. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SQL API and changeVersion() with no callbacks
On Thu, 25 Oct 2007, Brady Eidson wrote: For the sake of simplicity in the API, I see no reason why there couldn't be a single version of changeVersion() with the 2 strings and 2 callbacks. Then if a user truly wanted to call changeVersion() but wasn't interested in the results, they could just pass null for both of the callbacks. Very good point. I have removed the overloads here. This is not going to be frequently called, so why not require the callbacks. I suppose the same could be said about executeSql(). Well... I can certainly see people queuing up a bunch of requests and dealing with the errors at the end in the transaction error handler. I am open to requiring that that have an explicit null though. Who do other people think? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SQL API - SQLVersionChangeCallback vs SQLTransactionCallback
On Thu, 25 Oct 2007, Brady Eidson wrote: changeVersion() takes SQLVersionChangeCallback and SQLTransactionErrorCallback arguments. transaction() takes SQLTransactionCallback and SQLTransactionErrorCallback arguments. SQLVersionChangeCallback and SQLTransactionCallback have identical properties. Yeah, this is a historical artefact (in one revision, they had different return types). Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SQL API and changeVersion() with no callbacks
On Sat, 27 Oct 2007 00:23:57 +0200, Ian Hickson [EMAIL PROTECTED] wrote: I suppose the same could be said about executeSql(). Well... I can certainly see people queuing up a bunch of requests and dealing with the errors at the end in the transaction error handler. I am open to requiring that that have an explicit null though. Who do other people think? There at least some feedback from the developer community that they'd like to see optional arguments: http://www.dustindiaz.com/dom-interfaces-suck/ -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] several messages about the naming of the loop attributes
Bikeshed alert. On Fri, 19 Oct 2007, Michael A. Puls II wrote: Maybe we should rename 'loopcount' to 'playcount'...? playcount fits better with the number of times to play the clip than loopcount does. Ok. Done. Hmm. Is the spec really ambigious? Here's an example: [...] What you're saying is that the attribute name is non-intuitive, not that the spec is ambiguous. I agree. Changed as noted above. Now, I am suggesting: loopCount - playCount currentLoop - playIndex || currentPlayIndex || currentPlayCountIndex I have left this one for now. I don't like index, for reasons discussed below. On Fri, 19 Oct 2007, Simon Pieters wrote: I don't have an opinion about naming in general, but I will note that .playIndex is consistent with select's .selectedIndex. For me this counts as a point against -- the selectedIndex identifies an item in a list, whereas here we are identifying a general period of time. On Fri, 19 Oct 2007, Dave Singer wrote: I have wondered whether it would be clearer if we called it loopFrom and loopTo, and had loopCount be the count of the *extra* plays, and loopNumber (or loopIndex) the current *extra* play. So if loopCount is 0, loopStart and loopEnd are irrelevant, and loopNumber will never exceed 0 either. I don't think loopFrom and loopTo is necessarily better than loopStart and loopEnd. On Fri, 19 Oct 2007, Randy Drielinger wrote: The terminoly we currently have is the one that's being used in the Video / Editting branch. Although they don't sound too logical, we could keep these (thus making it more consistent definition-wise) or perhaps pursue another name set from an area and adapt those. I don't favor creating a new named set to make things clear only for HTML5.0 sake. Are you ok with the new names? On Fri, 19 Oct 2007, Dave Singer wrote: yes, and clarifying that there is a straight play from start to end, and then loopCount extra plays from loopStart to loopEnd, counted by loopNumber. The same names with repeat instead of loop would also work. is that clearer, easier to explain and understand? so a loopCount of 0 means no loops, just the straight play. loopNumber 0 means we have not yet looped. I'm not sure that loopCount = 0 is clearer than playCount = 1. In fact I think people get confused over loopCount too much, however it works. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Couple comments on Database storage spec.
On Fri, 26 Oct 2007, Jonas Sicking wrote: It does sound like a good idea to make all examples use the '?' syntax. I still think that providing a quote() implementation would do more good than harm, but admittedly I don't care that much. Especially given that the worst that can happen is bugs and not security breaches. Ok. We'll see in v2 if we need the function afterall. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Gigantoredesignorrific changes to the Database API
On Thu, 25 Oct 2007, Dimitri Glazkov wrote:
1) The transactions are now required and this seems like an
unreasonable performance hit. What if the API would assume transaction
mode, but would allow authors to explicitly state that the operation
is not a transaction:
On Fri, 26 Oct 2007, Brady Eidson wrote:
I think we've established that with at least a few popular sql implementations
- if you use things correctly - wrapping single statements in transactions
does not affect performance in a critical manner.
I agree with Brady. We can add this in a later version if we need it -- I
made sure the API had room for it.
On Thu, 25 Oct 2007, Dimitri Glazkov wrote:
2) Fully asynchronous is scary. Are we sure this is going to be
well-digested? I can just see people doing this:
db.operation(function(tx) {
var count;
tx.executeSql(SELECT COUNT(*) AS C FROM BLAH;, function(r) {
count = r.item(0).c;
});
if (count 0) {
// do happy things.
}
});
On Fri, 26 Oct 2007, Brady Eidson wrote:
I am very pleased that this entire API is designed around the fact that
synchronous I/O on the main thread is bad, and would argue against any
attempt to introduce synchronous I/O without an extremely compelling argument.
I don't think unskilled/uninformed developers might use the API incorrectly
is compelling enough to change the design and give them the power to do I/O on
the main thread.
There are various JS libraries - some very popular - that make challenging
APIs easier to use, but I really don't think this one is all that challenging!
I think again that Brady's opinion is in line with most Web browser
developers at this point; the synchronicity of the API was the biggest
complaint of the first version.
On Thu, 25 Oct 2007, Dimitri Glazkov wrote:
3) I think I misunderstand step 11, help me out. If the commit has
failed once, why try to re-commit, even if the error callback instructs
you to?
Fixed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SQL API and Transactions
On Thu, 25 Oct 2007, Brady Eidson wrote: For major steps during processing of a transaction, if that step fails the SQLTransactionErrorCallback is invoked. Additionally, for each statement processed within a transaction, success and failure in executing that statement both result in a callback - SQLStatementCallback and SQLStatementErrorCallback respectively. With the above mechanisms, there is a lot of solid notification to the script about progress of a transaction. There seems to be a flaring hole, however. Step 9 of the transaction steps stipulates that if the transaction fails to commit, the script will get an SQLTransactionErrorCallback indicating this failure. However, there is no final callback indicating *success* of the commit. In the case of a general transaction used for a chain of executeSql calls, the script will have gotten a callback for each statement as it succeeds and therefore might assume the transaction will succeed. However, they don't know *when* is has succeeded. In the case of the transaction wrapped by a changeVersion() call, the script will definitely know when the changeVersion() fails, but will not know at what point in time the changeVersion() has finished and the data is all committed to disk. I can see a script wanting to know when a transaction is actually 100% complete and committed before moving on to the next task. I just don't know how important it is, and wanted to bring this point up for discussion. We can add a third callback to changeVersion() and transaction(). I can't see any other way to solve it. What do people think? Too heavy-weight, or ok? I'm ok with doing it if people want it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SVG extensions to canvas
That would presumably because of the intrinsic size Anne referred to. SVG's contain scaling information; the size is designated in the image file. --- Daniel Brumbaugh Keeney Devi Web Development [EMAIL PROTECTED] ---
Re: [whatwg] cue points in media elements
On Wed, 24 Oct 2007, Dave Singer wrote: Caution: cross-posted to whatwg and htmlwg; be careful with follow-ups! Actually, please don't cross-post new threads to both groups. As mentioned earlier this week, I only cross-post when the messages I'm replying to were sent to both groups as a convenience to both groups so they can see what progress is being made on issues that were discussed there; as a general rule it's better to not cross-post. Thanks! We've been looking into both semantic and implementation considerations of cue points. We wonder whether cue ranges might not make more sense. Done. I also changed the way that cue points (er, ranges) are removed, which I think will make it easier to handle swapping in sets of subtitles or the like. Comments welcome. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
On Fri, 26 Oct 2007, Dave Singer wrote: If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). But you don't need to tell the browser that explicit confirmation is required; you merely need to say that, if the browser supports fullscreen requests (and it may ignore them), it must be clear to the user that the screen is 'filled' with the video and not his normal desktop. Yes, a dialog before is one way, but so is, for example, a blinking red 10-pixel border around the screen that says security warning! do not treat as desktop! continuously. There are (I hope) better designs. :-) i.e. state the requirement, not the solution. In general I agree, but when we don't have a single solution we can think of that's any good, it seems highly experimental (and thus inappropriate for HTML5) to have the requirement in the spec. On Thu, 25 Oct 2007, Jonas Sicking wrote: I just can't think of a solution that doesn't fall into at least one of these categories: 1) Some sort of user-confirmation that most users will not understand (such as the dialog) 2) Uses annoying ugly UI that will make no sites want to use it (such as a blinking red border) 3) Is unsafe 4) Will be annoying since advertisers are going to abuse it. Neither can I. On Fri, 26 Oct 2007, Dave Singer wrote: You may be right. But a lack of imagination on my part may not be a good reason to leave out the feature, unless we are fairly sure that the feature cannot be implemented with the requirement for phishing protection in an acceptable way, ever, at all. Actually, lack of imagination on everyone's part _is_ a good reason to leave out a feature. We shouldn't be using HTML standardisation as a research lab, we should be standardising things we know work. On Thu, 25 Oct 2007, Jonas Sicking wrote: I'd say it's the other way around. We shouldn't include features that we can't think of a way to implement them. Right. On Thu, 25 Oct 2007, Greg Houston wrote: Roughly, one solution might be: The user is playing a video within a web page. They click on full screen mode. The toolbar, status bar, menu bar, and so forth are removed, leaving just the title bar and close, minimize, and restore controls. If there is no movement of the mouse for 2-5 seconds the title bar disappears. With movement of the mouse again, the title bar reappears. If the user clicks on the close control, the window returns to its original state while continuing to play the video within the page. Also, If the video comes to an end the window returns to its original state. If you don't want the title bar to control closing full screen mode, the browser could display a special video bar during full screen mode directly underneath the title bar. This bar could have play controls on it. Again, the video bar (as well as the title bar) would disappear after so many seconds of no mouse movement. In addition to redisplaying the title bar (and potentially the video bar) on mouse movement, it might be helpful to have a way to overlay play controls (pause, stop, and so forth) on top of the video at this time giving the designer a way to add those controls or supplement those that would be in the video bar if the video bar was implemented. Standard hotkeys in full screen mode might be nice, e.g., space bar (play, pause). That's what the spec has now. The user has to tell the UA to go full-screen. With javascript it is already possible to make full screen web pages. If advertisers were going to exploit this they would have by now. Actually, they can't, as far as I can tell. Standardizing full screen video mode seems like a good idea since users will learn what to expect and how to navigate it. Otherwise, you potentially have a 1000 different implementations of fullscreen mode devised by designers requiring the end user to figure out each time how to navigate that particular implementation. You only need one implementation -- the user agent's. It just means you can't have little JavaScript UI to trigger it, but I think that's ok. On Fri, 26 Oct 2007, Dave Singer wrote: But the question remains: should we provide standard markup to do fullscreen, since most browsers will provide an extension to do it anyway, or not? And if so, how much do we say about the security issues (and what)? And if not, how do we still need to say about the security issues for browsers that do it anyway through UI, extension, or both? Through UI there's not really a security problem. Through an extension, that's up to the UA. We can't mention all the ways that UAs can shoot themselves through the foot. If an extension turns out to be good, then we can spec it. On Fri, 26 Oct 2007, Jonas Sicking wrote: I imagine what will happen is that pages will create
Re: [whatwg] When to stop video elements from playing
On Fri, 26 Oct 2007, Jonas Sicking wrote: A couple of comments: The spec currently doesn't say to set the autoplaying flag to false when an element is removed from the Document. I take it that will mean that the element will start playing if it's currently waiting for data? This seems undesirable to me for two reasons: A) I think nodes not in the document should only start playing when more explicitly asked to. B) It creates a race condition where the element _will_not_ play when if enough data had been downloaded at the point when the element was removed, but _will_ play if it was still waiting for data. Is there any reason we couldn't state the removing the element from the Document calls pause() on the element? Good point. Fixed. I think that it is still currently possible that a currently playing element can get garbage collected. Alternatively, that it is possible to create elements that will never stop playing, even if the user navigates away. Consider the following scenario: 1) Page A opens a new window containing Page B 2) Page A creates a reference to Page B 3) Page B creates an audio element that doesn't live in its Document and sticks it in a global variable of its context. 4) Window containing Page B is closed. Page B does not go away since Page A is holding a reference to it. 5) Page B calls .play() on the audio At this point nothing happens, because B isn't an active document, and playback only occurs (according to the spec) if the ownerDocument is an active document. The only step here that is slightly suspicious is step 5 since a closed-but-alive page is running script. Right, but the point would still hold if page A called .play(). I believe this can happen in a number of ways, the simplest being that Page A calls a function on Page B. But I suspect there are also events that can fire in Page B even after it has closed. Actually per spec, if I recall, you can't run script if you're not an active document. (To start with, your Window object won't have your properties any more, which makes things difficult if we allow script.) I believe the best solution here is to say that step 5 should throw an exception. I.e. you can't start playing a media element whose .ownerDocument is not a displayed document. What do you think of what the spec says at the moment? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Call for Comments
Last November, as part of the feedback on the W3C HTML WG charter, I wrote an e-mail [1] saying that I thought a realistic timetable would have a first working draft released in October 2007. We don't really need archived copies with the way the WHATWG works, since everything happens in the open with a Subversion interface and everything, but, I figured that I should publish an archived copy anyway, so today I put out a frozen call for comments draft: http://www.whatwg.org/specs/web-apps/2007-10-26/multipage/ If anyone was hoping for a semi-stable version to start reviewing the draft, I would say that this is it. We're pretty much feature-complete at this point, which is to say I don't think we'll be adding any major features to HTML5 going forward (though of course minor features like additions to certain APIs are likely to still occur). There is a public issues list: http://www.whatwg.org/issues/ ...which has about 3700 issues in it. The next order of business is simply to go through all of those issues. I've been tracking the issue count since early October, and at the moment the count is reducing at a rate of about 7 a day, which works out to being about a year and a bit of solid work, which puts us on track to reach Last Call in 2009, as I predicted in the aforementioned e-mail. I'd like to thank everyone here in the WHATWG community for helping make this work fun and pleasant. It's really nice to be able to work in such a friendly atmosphere. I hope the coming year will continue the same way! [1] http://lists.w3.org/Archives/Public/www-archive/2006Nov/0045.html Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SVG extensions to canvas
Hi Daniel, Sorry, I still don't get it. A raster (bitmap) image, which _isn't_ really designed to scale, has intrinsic size yet it is scaled by the IMG's width and height attributes. Why isn't an image that _is_ designed to scale not scaled by the IMG's width and height attributes? Regards, -Vlad http://xhtml.com Original Message From: Devi Web Development Date: 2007-10-26 7:44 PM That would presumably because of the intrinsic size Anne referred to. SVG's contain scaling information; the size is designated in the image file. --- Daniel Brumbaugh Keeney Devi Web Development [EMAIL PROTECTED] ---
