Re: [whatwg] Full screen for the element
On Tue, 30 Oct 2007, Michael A. Puls II wrote: > > > > Well the global default would always have to be false, since you never > > know when the next site is going to abuse you. > > Well, a user might turn on the global and use a blacklist for any > problem sites they encounter. Many already do that for cookies, java, > plugins and pics. (There's probably more that do the opposite though and > use a whitelist. Just saying that "always" may not be true. The default > when you install would have to be unchecked of course except for some > specific kiosk deal where the UA can only connect to trusted sites.) Assuming that we'll need a blacklist even before the feature exists seems like admitting that the feature is flawed, which is a good sign that we shouldn't include it, IMHO. :-) > I could even see there being a way to enable full screen for a site via > userJS/Greasemonkey scripts. > > (Meaning, there might be a way to do it even if the spec doesn't say > there is. If so, it'd be a good thing to study to see if it's worthy of > adding to the spec later.) Agreed. > > Also, if the setting exists, it's far easier to trick users into > > setting it than if it doesn't. > > Out of curiousity, is an automatic switch to full screen without the > user's consent considered an annoyance/usability problem or a > security/fishing attack/vulnerability problem or both? > > FWIW, it's only the former IMO. The former, yes. > Not that it matters, much, but with WMP, a script can use > SetDisplaySize(3) to automatically switch to fullscreen without the > user's consent. You can do the same with the videolan plugin using > player.video.fullscreen = true. No warnings or anything. Noted. > If someone does ask why scripts can't switch to full screen, what would > the reason(s) be? > > 1. There doesn't seem to be much demand for it. > > 2. It's not clear what would be the best way for UAs to provide the > functionality while preventing sites from taking advantage of the > feature and annoying users. Both, and also that it's considered ok for the user to have to tell the UA that he wants to go fullfreen (rather than the script having to tell the UA that the user wants to go fullscreen). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the element
On 10/29/07, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 29 Oct 2007, Michael A. Puls II wrote: > > > > I could imagine it this way: > > > > Global javascript option: allow scripts to enable full screen for video > > element = (default unchecked) > > Well the global default would always have to be false, since you never > know when the next site is going to abuse you. Well, a user might turn on the global and use a blacklist for any problem sites they encounter. Many already do that for cookies, java, plugins and pics. (There's probably more that do the opposite though and use a whitelist. Just saying that "always" may not be true. The default when you install would have to be unchecked of course except for some specific kiosk deal where the UA can only connect to trusted sites.) I could even see there being a way to enable full screen for a site via userJS/Greasemonkey scripts. (Meaning, there might be a way to do it even if the spec doesn't say there is. If so, it'd be a good thing to study to see if it's worthy of adding to the spec later.) > > user-created site preference for cool.site.com: allow scripts to enable > > full screen for video element = checked > > Requiring site-specific preferences seems a bit excessive for a new HTML5 > feature. Yeh, the spec requiring something that specific seems excessive, but it seems that's what UAs would do (in some simple or advanced form) anyway if they allowed scripts to control fullscreen. > Also, if the setting exists, it's far easier to trick users into > setting it than if it doesn't. Out of curiousity, is an automatic switch to full screen without the user's consent considered an annoyance/usability problem or a security/fishing attack/vulnerability problem or both? FWIW, it's only the former IMO. Not that it matters, much, but with WMP, a script can use SetDisplaySize(3) to automatically switch to fullscreen without the user's consent. You can do the same with the videolan plugin using player.video.fullscreen = true. No warnings or anything. > > Now, for me personally, I just want to be able to double-left-click on > > the video area to enter full screen and then do the same in full screen > > (or esc) to get back. I probably wouldn't want to automatically enter > > full screen. However, sites and others might want that and it might be > > cool. > > > > Either way it seems like there's an acceptable way to allow scripts to > > switch to full screen, if there's a need for it. > > I think having the UA provide it is enough, at least for now. Understood. If someone does ask why scripts can't switch to full screen, what would the reason(s) be? 1. There doesn't seem to be much demand for it. 2. It's not clear what would be the best way for UAs to provide the functionality while preventing sites from taking advantage of the feature and annoying users. ? -- Michael
Re: [whatwg] When to stop elements from playing
Ian Hickson wrote: First of all, that'll mean that calling .play() on a in-non-active-document element will silently fail. It'd probably be better to throw an exception. If it throws an exception, how do you switch it to the "play" mode? You might well want to do this, e.g. if it is possible the document in question will once against become an active document. It's also something that's easier to miss for an implementor. Might be a good idea to put it in the steps for play() and change the removed-from-document paragraph to say: When a media element is removed from a Document, or the .ownerDocument stops being an active document, the user agent must act as if the pause() method had been invoked. But that makes it possible to have the problem you mentioned, with elements that never stop playing. What I meant was to make play() throw if .ownerDocument isn't active, and make elements pause() when the .owernDocument goes inactive. In that case it shouldn't be possible to never stop playing. I agree that it might be desirable to put the in play-mode without actually starting to play it, so the current text looks fine. / Jonas
Re: [whatwg] SQL API - SQLTransactionErrorCallback
On Oct 29, 2007, at 6:25 PM, Ian Hickson wrote: On Mon, 29 Oct 2007, Brady Eidson wrote: I propose we change SQLTransactionErrorCallback.handleEvent() to have the same signature as the SQLStatementErrorCallback, which is: boolean handleEvent(in SQLTransaction transaction, in SQLError error); Actually I specifically didn't include the transaction because I can't see what you could do with it. You know which transaction it is, it's the one to which you are passing the method. Why can't a developer have a global transaction error callback they use for multiple transactions, including the possibility of transactions from more than one database at a time? No rule prevents this. They can, but so what? What are they going to do with the transaction object? It doesn't have any information they can use, and the only method on there is one that would raise an exception if they called it. If the author wants to pass context information to their error handler they can (only) do so using currying, I don't see how the SQLTransaction object is going to help them. I agree that other than *being* the context information, the SQLTransaction object itself won't help them. Since currying is a functional - if not annoying - solution, I'll let this one go :) Thanks, ~Brady
Re: [whatwg] Full screen for the element
On Mon, 29 Oct 2007, Michael A. Puls II wrote: > > I could imagine it this way: > > Global javascript option: allow scripts to enable full screen for video > element = (default unchecked) Well the global default would always have to be false, since you never know when the next site is going to abuse you. > user-created site preference for cool.site.com: allow scripts to enable > full screen for video element = checked Requiring site-specific preferences seems a bit excessive for a new HTML5 feature. Also, if the setting exists, it's far easier to trick users into setting it than if it doesn't. > Now, for me personally, I just want to be able to double-left-click on > the video area to enter full screen and then do the same in full screen > (or esc) to get back. I probably wouldn't want to automatically enter > full screen. However, sites and others might want that and it might be > cool. > > Either way it seems like there's an acceptable way to allow scripts to > switch to full screen, if there's a need for it. I think having the UA provide it is enough, at least for now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SQL API - SQLTransactionErrorCallback
On Mon, 29 Oct 2007, Brady Eidson wrote: > > > > > > I propose we change SQLTransactionErrorCallback.handleEvent() to > > > have the same signature as the SQLStatementErrorCallback, which is: > > > boolean handleEvent(in SQLTransaction transaction, in SQLError > > > error); > > > > Actually I specifically didn't include the transaction because I can't > > see what you could do with it. You know which transaction it is, it's > > the one to which you are passing the method. > > Why can't a developer have a global transaction error callback they use > for multiple transactions, including the possibility of transactions > from more than one database at a time? No rule prevents this. They can, but so what? What are they going to do with the transaction object? It doesn't have any information they can use, and the only method on there is one that would raise an exception if they called it. If the author wants to pass context information to their error handler they can (only) do so using currying, I don't see how the SQLTransaction object is going to help them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] License metadata in HTML
On Mon, 12 Sep 2005, Matthew Raymond wrote: > > Had a quick thought I'd like to share with you. Often times, content > from other sources might be inserted into a web page, or you may have > situations where you wish people to be able to copy part of the text > (such as a press release), but not all of it (such as the website UI and > graphics). You may also want (or are legally required) to list the > original holder of the copyright. There are also situations where > managing copyright information for content is difficult without > assistance from software. > > To resolve these problems [...] Which problems? From the previous paragraph, I only see one problem, "situations where managing copyright information for content is difficult without assistance from software". But it's not clear to me what those situations are. > I suggest the creation of two new attributes. The first is |copyright|, > which allows a copyright notice to be attached to an element. The > copyright is inherited by all descendants, unless a descendant element > has an assigned |copyright| itself, which overrides ancestor copyrights. > Thus, you can theoretically track any part of a document back to its > original copyright owner. > > The second attribute is |license|. It is inherited in the same way as > |copyright|, and provides a name and/or URL to the license for the > respective content. Editing software can potentially use the licensing > information to determine if certain content can be copied into content > under a different license. For this to be useful, it would have to be reliable, and I highly doubt that people would reliably include this information -- but, worse, it seems like authors would be likely to end up misrepresenting copyright and license information, which is actually a worse situation than the current ambiguous state. Also, it's unclear that we'd be able to come up with values for "license" than are unambiguous enough for software to be able to reliably determine what is legal and what isn't. Giving legal advice is a dodgy area, getting it wrong can land you in hot water. > Well, just a thought. There may be better ways to do this already. Let > me know what you think. I think we should let authors put copyrights in elements as freeform text, and let off-page licenses be linked to explicitly using rel=license, and not have any fine-grained control over what is copyrighted and what isn't, at least until we (as an industry) have far more experience with how to present license minutiae to authors. On Tue, 13 Sep 2005, Daniel O'Connor wrote: > > XML gave us xmlns for a reason! Failing that.. > > See: > http://dublincore.org/ > http://creativecommons.org/ > http://www.w3.org/2005/Talks/05-steven-xtech/ > http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-meta.html > http://hublog.hubmed.org/archives/001187.html > ... > > There's far too many more widely accepted methods of inserting > metainfomation (in the microformat / RDF + GRDDL / style) into a (x)HTML > document without the need for a "copyright" attribute. Some of those technologies might be useful here too, though I'm not sure any of them are really mature enough to handle copyrights and licenses. On Wed, 14 Sep 2005, Anne van Kesteren wrote: > > Of the particular section. I suppose you could nest ADDRESS inside > BLOCKQUOTE and have the effect. Anyway, did you miss my point about the > information should be visible? Having information visible -- or rather, having all data have an author-perceived effect by default -- is indeed a good way of ensuring that metadata remains accurate. I agree with your implication that copyright="" and license="" may not achieve this well. On Wed, 14 Sep 2005, Matthew Raymond wrote: > > No, I did not. Often times, it's impractical to list the copyright and > trademark for every item, especially when you have a document that it > heavily composited. (Imagine documents where there's a copyright notice > every few lines. This is especially the case when quoting, where the > content is broken up so that you can reply to individual statements.) In practice, I haven't seen much need for markup of these kinds of documents to be explicit, though. People seem happy to just list copyrights in the footer or in comments in the markup. On Mon, 12 Sep 2005, Ryan King wrote: > > > > Attributes are not backwards compatible. (Well they are, just not for > > this.) License and copyright information should always be visible to > > the user. > > Exactly why rel-license (http://microformats.org/wiki/rel-license) was > invented. Indeed, rel=license is in HTML5. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the element
On 10/29/07, Dave Singer <[EMAIL PROTECTED]> wrote:
> If we don't have a way for content to request full screen (markup,
> script, whatever), I'm OK with that. But I think that we should say
> why we left it out, in the spec., and not be silent. Otherwise we'll
> merely see browser makers doing their own extensions to do it anyway,
> and then we'll also have non-interoperable methods as well as the
> security issues...
> --
> David Singer
> Apple/QuickTime
>
I could imagine it this way:
Global javascript option: allow scripts to enable full screen for
video element = (default unchecked)
user-created site preference for cool.site.com: allow scripts to
enable full screen for video element = checked
Then, the trusted pages could use if (video.canToggleFullScreen()) to
see if they are allowed to toggle full screen. Then, they would use
video.toggleFullScreen() to automatically turn on full screen (they
might use a stored cookie preference or whatever) and or provide a
full screen button on the page.
I could imagine that easily working in Opera and FF3 with site preferences.
The spec would just have to support canToggleFullScreen() and
toggleFullScreen(). It would not have to mention site preferences
specifically. Maybe just recommend that it should be turned off by
default and recommend that UAs supporting toggleFullScreen() should
provide *some* mechanism to enable it on a per-site basis.
A tiny issue with toggleFullScreen() is that if a button on the page
is provided, once you're in full screen, you'll have to use the
browser-provided way to get out. But, toggleFullScreen() would still
be useful for the script to switch back to normal view automatically
when the clip is done playing or toggle for certain clips.
One thing with toggleFullScreen() that might not be funny would be:
while(1) {
video.toggleFullScreen();
}
If so, then perhaps it should not be a toggle and only be
enableFullScreen() (which would do nothing if already in full screen,
which would also make more sense for the tiny button issue mentioned
above, but would make coming out of full screen not possible by the
script.)
Now, for me personally, I just want to be able to double-left-click on
the video area to enter full screen and then do the same in full
screen (or esc) to get back. I probably wouldn't want to automatically
enter full screen. However, sites and others might want that and it
might be cool.
Either way it seems like there's an acceptable way to allow scripts to
switch to full screen, if there's a need for it.
--
Michael
Re: [whatwg] SQL API - SQLTransactionErrorCallback
On Oct 29, 2007, at 3:37 PM, Ian Hickson wrote: On Mon, 29 Oct 2007, Brady Eidson wrote: A SQLTransactionErrorCallback object has a single method: boolean handleEvent(in SQLError error); This method is meant for both notifying of a failure in the transaction as well as for deciding it's fate - should we commit what we have, or just roll it back? However, there's one problem - how does the script and it's SQLTransactionErrorCallback know which transaction is in question? I propose we change SQLTransactionErrorCallback.handleEvent() to have the same signature as the SQLStatementErrorCallback, which is: boolean handleEvent(in SQLTransaction transaction, in SQLError error); Actually I specifically didn't include the transaction because I can't see what you could do with it. You know which transaction it is, it's the one to which you are passing the method. Why can't a developer have a global transaction error callback they use for multiple transactions, including the possibility of transactions from more than one database at a time? No rule prevents this. Thanks, ~Brady
Re: [whatwg] SQL API - SQLTransactionErrorCallback
On Mon, 29 Oct 2007, Brady Eidson wrote: > > A SQLTransactionErrorCallback object has a single method: boolean > handleEvent(in SQLError error); > > This method is meant for both notifying of a failure in the transaction > as well as for deciding it's fate - should we commit what we have, or > just roll it back? However, there's one problem - how does the script > and it's SQLTransactionErrorCallback know which transaction is in > question? > > I propose we change SQLTransactionErrorCallback.handleEvent() to have > the same signature as the SQLStatementErrorCallback, which is: boolean > handleEvent(in SQLTransaction transaction, in SQLError error); Actually I specifically didn't include the transaction because I can't see what you could do with it. You know which transaction it is, it's the one to which you are passing the method. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SQL API - SQLTransactionErrorCallback
As I read this email, I realize we'd be making SQLTransactionErrorCallback and SQLStatementErrorCallback have identical properties, perhaps making them candidates for a pruning. I don't know what the name of the sole object would be, however, as the context would be quite different depending on if it were a statement err'ing out or a transaction. ~Brady On Oct 29, 2007, at 2:33 PM, Brady Eidson wrote: A SQLTransactionErrorCallback object has a single method: boolean handleEvent(in SQLError error); This method is meant for both notifying of a failure in the transaction as well as for deciding it's fate - should we commit what we have, or just roll it back? However, there's one problem - how does the script and it's SQLTransactionErrorCallback know which transaction is in question? I propose we change SQLTransactionErrorCallback.handleEvent() to have the same signature as the SQLStatementErrorCallback, which is: boolean handleEvent(in SQLTransaction transaction, in SQLError error); Thanks, ~Brady
Re: [whatwg] Full screen for the element
Ivo Emanuel Gonçalves wrote: As far as I understand this issue, the best solution is to leave it up to the user-agent. If they want to provide a full screen option let them have it. If users find it annoying or if it's heavily abused, they either disable it or move to another browser that knows what it's doing(tm). Basically, full screen video should be a client thing. The HTML 5 spec should merely suggest user-agents not to start in full screen mode by default. I think that's a good compromise. Not elegant, but probably works. Agreed. However I wasn't talking about fullscreen in my previous email in this thread. I was talking about full-window. Something that has entierly different security constraints and something that webpages will be able to do even if we don't provide an API. But as I said, I'm fine with leaving full-window to a later version of the spec if we see there's a need for it. / Jonas
[whatwg] SQL API - SQLTransactionErrorCallback
A SQLTransactionErrorCallback object has a single method: boolean handleEvent(in SQLError error); This method is meant for both notifying of a failure in the transaction as well as for deciding it's fate - should we commit what we have, or just roll it back? However, there's one problem - how does the script and it's SQLTransactionErrorCallback know which transaction is in question? I propose we change SQLTransactionErrorCallback.handleEvent() to have the same signature as the SQLStatementErrorCallback, which is: boolean handleEvent(in SQLTransaction transaction, in SQLError error); Thanks, ~Brady
Re: [whatwg] SQL API - Small editorial fix
On Mon, 29 Oct 2007, Brady Eidson wrote: > > There are 6 steps for the SQLTransaction.executeSql() call before the > statement is queued up. > > Step 5 says: > "If the Database object has an expected version that is neither the empty > string nor the actual version of the database, then mark the statement as > bogus (Error code 2)" > > Now that executeSql() is on the SQLTransaction object and not the > Database object, I think some context was lost here. It's pretty obvious > that we mean "the Database object this SQLTransaction was created with", > but perhaps the spec should state that explicitly for those who haven't > been following its evolution like we have :) Fixed. Let me know if it's ok. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When to stop elements from playing
On Mon, 29 Oct 2007, Jonas Sicking wrote: > > Scripts can actually still run fine even if you navigate away from a > page. But there are definitely weird things happening (such as global > scope being different from 'window'). > > This isn't the thread to discuss this though. I've saved your mail to the "scripts" pile for future examination. > > > 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? > > Are you referring to "When a media element is actively playing and its > owner Document is an active document, its current playback position must > increase monotonically at playbackRate units of media time per unit time > of wall clock time"? Yes. > First of all, that'll mean that calling .play() on a > in-non-active-document element will silently fail. It'd probably be > better to throw an exception. If it throws an exception, how do you switch it to the "play" mode? You might well want to do this, e.g. if it is possible the document in question will once against become an active document. > It's also something that's easier to miss for an implementor. Might be a > good idea to put it in the steps for play() and change the > removed-from-document paragraph to say: > > When a media element is removed from a Document, or the .ownerDocument > stops being an active document, the user agent must act as if the > pause() method had been invoked. But that makes it possible to have the problem you mentioned, with elements that never stop playing. I've put a note in the text near the pause() method that points out the active document thing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When to stop elements from playing
Ian Hickson wrote: 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.) Scripts can actually still run fine even if you navigate away from a page. But there are definitely weird things happening (such as global scope being different from 'window'). This isn't the thread to discuss this though. 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? Are you referring to "When a media element is actively playing and its owner Document is an active document, its current playback position must increase monotonically at playbackRate units of media time per unit time of wall clock time"? First of all, that'll mean that calling .play() on a in-non-active-document element will silently fail. It'd probably be better to throw an exception. It's also something that's easier to miss for an implementor. Might be a good idea to put it in the steps for play() and change the removed-from-document paragraph to say: When a media element is removed from a Document, or the .ownerDocument stops being an active document, the user agent must act as if the pause() method had been invoked. / Jonas
[whatwg] SQL API - Small editorial fix
There are 6 steps for the SQLTransaction.executeSql() call before the statement is queued up. Step 5 says: "If the Database object has an expected version that is neither the empty string nor the actual version of the database, then mark the statement as bogus (Error code 2)" Now that executeSql() is on the SQLTransaction object and not the Database object, I think some context was lost here. It's pretty obvious that we mean "the Database object this SQLTransaction was created with", but perhaps the spec should state that explicitly for those who haven't been following its evolution like we have :) Thanks, ~Brady
Re: [whatwg] Full screen for the element
If we don't have a way for content to request full screen (markup, script, whatever), I'm OK with that. But I think that we should say why we left it out, in the spec., and not be silent. Otherwise we'll merely see browser makers doing their own extensions to do it anyway, and then we'll also have non-interoperable methods as well as the security issues... -- David Singer Apple/QuickTime
