Re: [whatwg] input type=location proposals
2010/6/18 Eitan Adler li...@eitanadler.com: These are two separate proposals and I both could co-exist one as type=location and the other as type=gps Even though this sounds pretty nice to me, something critical should be figured out before going deeper. Precisely: 1. Maps are heavy to get, this means UA should heavily cache and/or it should own whole maps data (huge!) 2. If 1) didn't exist because UA can, for instance, get maps data in a blink of an eye: whose data are we gonna use? 3. Maps data are often non-free and non-open, reliable maps data are always non-free and non-open. My 2c... -- Bye, Michelangelo
Re: [whatwg] input type=location proposals
1. Maps are heavy to get, this means UA should heavily cache and/or it should own whole maps data (huge!) 2. If 1) didn't exist because UA can, for instance, get maps data in a blink of an eye: whose data are we gonna use? 3. Maps data are often non-free and non-open, reliable maps data are always non-free and non-open. For type=gps I was thinking something like the following: 1) type=gps results in a (double?) text box which takes a latitude and a longitude 2a) there is some css option that tells the text box to act like a map instead. 2b) If the css option is on there is also some method of requesting a map source this source could be any existing map provider Then again now that I think about it some more I don't see this working out too well. -- Eitan Adler
Re: [whatwg] video
On Mon, 8 Mar 2010, balachandar muruganantham wrote: I have heard from people that there have been a discussion on supporting the fullscreen mode for HTML5 video element. can anyone share the information on the conclusion we arrived at? i searched in the archive but i could not come to any conclusion. On March 25th, Ian Hickson then said: The conclusion was that it is a presentational issue and therefore should be handled in one of the CSSOM specs. Unfortunately we don't have anyone who has the bandwidth to edit a spec to specify how to make things go full-screen. WebKit is experimenting with some APIs in this space, I believe. I hope it's not minded if I weigh in on this topic as I feel strongly about it. It's very important that the HTML5 spec address developers' needs without crippling their abilities due to unfounded or incorrect security implementations. This is the problem we've been dealing with in regard to the file input uploaders for years, trying to simply apply a little CSS style to them. Adobe has blocked inappropriate use of fullscreen by tying that functionality to the click of a button. It can't be done onload or programmatically, it requires a user's interaction. The HTML5 spec can provide the same thing for fullscreen video. It's no different than the security used for HTML file inputs – you can't open a a File Browse Dialog, the user must click a button. I sincerely hope developers' needs aren't made secondary in such debates. While I appreciate proper browser security, in some cases it forces us to just look for workarounds to circumvent the security. The lack of fullscreen is a serious issue for us as we deal with clients and superiors who ask us to replace the Flash video player with an HTML5 video player... only to have us go back to them and say Here is the cool player with custom controls... sorry, you can't do fullscreen though, it's not allowed. The obvious response to this is Flash can, why can't HTML5? and well, let's just use Flash then. Finally, in reference to the CSSOM Ian, I'm not sure this is what you are referring to, but another solution to the fullscreen issue is if the browser default controls could be styled with CSS. This would be a real win-win, as we could have our secure fullscreen button (as implemented in Webkit but not Firefox strangely) and also have a faster path to custom controls. While I would guess this would be a CSSOM issue, it seems that it would still be a recommendation by WHATWG. Mike Wilcox http://clubajax.org m...@mikewilcox.net
Re: [whatwg] video
On Sun, 2010-06-20 at 16:07 -0500, Mike Wilcox wrote: On Mon, 8 Mar 2010, balachandar muruganantham wrote: I have heard from people that there have been a discussion on supporting the fullscreen mode for HTML5 video element. can anyone share the information on the conclusion we arrived at? i searched in the archive but i could not come to any conclusion. On March 25th, Ian Hickson then said: The conclusion was that it is a presentational issue and therefore should be handled in one of the CSSOM specs. Unfortunately we don't have anyone who has the bandwidth to edit a spec to specify how to make things go full-screen. WebKit is experimenting with some APIs in this space, I believe. I hope it's not minded if I weigh in on this topic as I feel strongly about it. It's very important that the HTML5 spec address developers' needs without crippling their abilities due to unfounded or incorrect security implementations. This is the problem we've been dealing with in regard to the file input uploaders for years, trying to simply apply a little CSS style to them. Adobe has blocked inappropriate use of fullscreen by tying that functionality to the click of a button. It can't be done onload or programmatically, it requires a user's interaction. The HTML5 spec can provide the same thing for fullscreen video. It's no different than the security used for HTML file inputs – you can't open a a File Browse Dialog, the user must click a button. I sincerely hope developers' needs aren't made secondary in such debates. While I appreciate proper browser security, in some cases it forces us to just look for workarounds to circumvent the security. The lack of fullscreen is a serious issue for us as we deal with clients and superiors who ask us to replace the Flash video player with an HTML5 video player... only to have us go back to them and say Here is the cool player with custom controls... sorry, you can't do fullscreen though, it's not allowed. The obvious response to this is Flash can, why can't HTML5? and well, let's just use Flash then. Couldnt we have a property in the video tag that allows full screen? That would solve what you are saying I think. --fagan
Re: [whatwg] video
On Sun, 2010-06-20 at 22:13 +0100, Shane Fagan wrote: On Sun, 2010-06-20 at 16:07 -0500, Mike Wilcox wrote: On Mon, 8 Mar 2010, balachandar muruganantham wrote: I have heard from people that there have been a discussion on supporting the fullscreen mode for HTML5 video element. can anyone share the information on the conclusion we arrived at? i searched in the archive but i could not come to any conclusion. On March 25th, Ian Hickson then said: The conclusion was that it is a presentational issue and therefore should be handled in one of the CSSOM specs. Unfortunately we don't have anyone who has the bandwidth to edit a spec to specify how to make things go full-screen. WebKit is experimenting with some APIs in this space, I believe. I hope it's not minded if I weigh in on this topic as I feel strongly about it. It's very important that the HTML5 spec address developers' needs without crippling their abilities due to unfounded or incorrect security implementations. This is the problem we've been dealing with in regard to the file input uploaders for years, trying to simply apply a little CSS style to them. Adobe has blocked inappropriate use of fullscreen by tying that functionality to the click of a button. It can't be done onload or programmatically, it requires a user's interaction. The HTML5 spec can provide the same thing for fullscreen video. It's no different than the security used for HTML file inputs – you can't open a a File Browse Dialog, the user must click a button. I sincerely hope developers' needs aren't made secondary in such debates. While I appreciate proper browser security, in some cases it forces us to just look for workarounds to circumvent the security. The lack of fullscreen is a serious issue for us as we deal with clients and superiors who ask us to replace the Flash video player with an HTML5 video player... only to have us go back to them and say Here is the cool player with custom controls... sorry, you can't do fullscreen though, it's not allowed. The obvious response to this is Flash can, why can't HTML5? and well, let's just use Flash then. Couldnt we have a property in the video tag that allows full screen? That would solve what you are saying I think. --fagan Not really. The argument is about abuse of a fullscreen mode. An attribute in the video tag would mean it would start in fullscreen mode, which would be the easiest way to abuse it. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] video
On Sun, Jun 20, 2010 at 11:19 PM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: On Sun, 2010-06-20 at 22:13 +0100, Shane Fagan wrote: On Sun, 2010-06-20 at 16:07 -0500, Mike Wilcox wrote: On Mon, 8 Mar 2010, balachandar muruganantham wrote: I have heard from people that there have been a discussion on supporting the fullscreen mode for HTML5 video element. can anyone share the information on the conclusion we arrived at? i searched in the archive but i could not come to any conclusion. On March 25th, Ian Hickson then said: The conclusion was that it is a presentational issue and therefore should be handled in one of the CSSOM specs. Unfortunately we don't have anyone who has the bandwidth to edit a spec to specify how to make things go full-screen. WebKit is experimenting with some APIs in this space, I believe. I hope it's not minded if I weigh in on this topic as I feel strongly about it. It's very important that the HTML5 spec address developers' needs without crippling their abilities due to unfounded or incorrect security implementations. This is the problem we've been dealing with in regard to the file input uploaders for years, trying to simply apply a little CSS style to them. Adobe has blocked inappropriate use of fullscreen by tying that functionality to the click of a button. It can't be done onload or programmatically, it requires a user's interaction. The HTML5 spec can provide the same thing for fullscreen video. It's no different than the security used for HTML file inputs – you can't open a a File Browse Dialog, the user must click a button. I sincerely hope developers' needs aren't made secondary in such debates. While I appreciate proper browser security, in some cases it forces us to just look for workarounds to circumvent the security. The lack of fullscreen is a serious issue for us as we deal with clients and superiors who ask us to replace the Flash video player with an HTML5 video player... only to have us go back to them and say Here is the cool player with custom controls... sorry, you can't do fullscreen though, it's not allowed. The obvious response to this is Flash can, why can't HTML5? and well, let's just use Flash then. Couldnt we have a property in the video tag that allows full screen? That would solve what you are saying I think. --fagan Not really. The argument is about abuse of a fullscreen mode. An attribute in the video tag would mean it would start in fullscreen mode, which would be the easiest way to abuse it. Thanks, Ash http://www.ashleysheridan.co.uk The attribute should only instruct the browser to show the fullscreen button in the controls panels and in the context menu and not to switch to fullscreen mode immediately. This will allow to enforce/maintain a user action as the trigger for the fullscreen mode and thus avoid abuse of the feature programmatically. -- Diego Perini
Re: [whatwg] video
On Mon, 2010-06-21 at 00:03 +0200, Diego Perini wrote: On Sun, Jun 20, 2010 at 11:19 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Sun, 2010-06-20 at 22:13 +0100, Shane Fagan wrote: On Sun, 2010-06-20 at 16:07 -0500, Mike Wilcox wrote: On Mon, 8 Mar 2010, balachandar muruganantham wrote: I have heard from people that there have been a discussion on supporting the fullscreen mode for HTML5 video element. can anyone share the information on the conclusion we arrived at? i searched in the archive but i could not come to any conclusion. On March 25th, Ian Hickson then said: The conclusion was that it is a presentational issue and therefore should be handled in one of the CSSOM specs. Unfortunately we don't have anyone who has the bandwidth to edit a spec to specify how to make things go full-screen. WebKit is experimenting with some APIs in this space, I believe. I hope it's not minded if I weigh in on this topic as I feel strongly about it. It's very important that the HTML5 spec address developers' needs without crippling their abilities due to unfounded or incorrect security implementations. This is the problem we've been dealing with in regard to the file input uploaders for years, trying to simply apply a little CSS style to them. Adobe has blocked inappropriate use of fullscreen by tying that functionality to the click of a button. It can't be done onload or programmatically, it requires a user's interaction. The HTML5 spec can provide the same thing for fullscreen video. It's no different than the security used for HTML file inputs – you can't open a a File Browse Dialog, the user must click a button. I sincerely hope developers' needs aren't made secondary in such debates. While I appreciate proper browser security, in some cases it forces us to just look for workarounds to circumvent the security. The lack of fullscreen is a serious issue for us as we deal with clients and superiors who ask us to replace the Flash video player with an HTML5 video player... only to have us go back to them and say Here is the cool player with custom controls... sorry, you can't do fullscreen though, it's not allowed. The obvious response to this is Flash can, why can't HTML5? and well, let's just use Flash then. Couldnt we have a property in the video tag that allows full screen? That would solve what you are saying I think. --fagan Not really. The argument is about abuse of a fullscreen mode. An attribute in the video tag would mean it would start in fullscreen mode, which would be the easiest way to abuse it. Thanks, Ash http://www.ashleysheridan.co.uk The attribute should only instruct the browser to show the fullscreen button in the controls panels and in the context menu and not to switch to fullscreen mode immediately. This will allow to enforce/maintain a user action as the trigger for the fullscreen mode and thus avoid abuse of the feature programmatically. -- Diego Perini That would work +1 --fagan
Re: [whatwg] video
On Sun, Jun 20, 2010 at 5:07 PM, Mike Wilcox m...@mikewilcox.net wrote: I sincerely hope developers' needs aren't made secondary in such debates. While I appreciate proper browser security, in some cases it forces us to just look for workarounds to circumvent the security. The lack of fullscreen is a serious issue for us as we deal with clients and superiors who ask us to replace the Flash video player with an HTML5 video player... only to have us go back to them and say Here is the cool player with custom controls... sorry, you can't do fullscreen though, it's not allowed. The obvious response to this is Flash can, why can't HTML5? and well, let's just use Flash then. Actually a web developer can already implement a HTML5 VIDEO FullScreen solution for Firefox. (Hope same can be with other HTML5 Browsers) Here are the steps * Provide a full screen control button. * Popup an overlay message is asking Please confirm by pressing F11 key if you want to go Full Screen Mode VIDEO * watch for window.onresize event * on window.onresize event - check we are doing the overlay message for FullScreen - then if window.fullScreen=true make the video big as window client area positioned topleft of th epage * Additionally on window.onload if window.fullScreen=true then ask user if he want to do full screen. Bugs on this subject https://bugzilla.mozilla.org/show_bug.cgi?id=545812 https://bugzilla.mozilla.org/show_bug.cgi?id=470628
Re: [whatwg] video
Diego Perini diego.per...@gmail.com schrieb am Mon, 21 Jun 2010 00:03:15 +0200: The attribute should only instruct the browser to show the fullscreen button in the controls panels and in the context menu and not to switch to fullscreen mode immediately. This will allow to enforce/maintain a user action as the trigger for the fullscreen mode and thus avoid abuse of the feature programmatically. AFAIK, at least Firefox shows a fullscreen option already in the context menu. What makes you think there is another attribute needed (besides @controls) ? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] video
On Sun, Jun 20, 2010 at 8:23 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: AFAIK, at least Firefox shows a fullscreen option already in the context menu. What makes you think there is another attribute needed (besides @controls) ? So... an interesting bit of fun comes up when you use layout tricks to prevent the context menu in order to make save as impossible, and you eliminate the full screen option as an unwanted side effect. There is also the issue of the context menu not being an especially intuitive or discoverable way of activating it, especially if all the rest of the controls are buttons below the video.
Re: [whatwg] video
On Sun, 2010-06-20 at 21:06 -0400, Gregory Maxwell wrote: On Sun, Jun 20, 2010 at 8:23 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: AFAIK, at least Firefox shows a fullscreen option already in the context menu. What makes you think there is another attribute needed (besides @controls) ? So... an interesting bit of fun comes up when you use layout tricks to prevent the context menu in order to make save as impossible, and you eliminate the full screen option as an unwanted side effect. There is also the issue of the context menu not being an especially intuitive or discoverable way of activating it, especially if all the rest of the controls are buttons below the video. I think the context menu is a sensible place to find a fullscreen option short of a button existing as part of the video controls. Also, if someone is daft enough to think that disabling the context menu will prevent people from saving their clips, then they deserve the pain of not being able to make the video play full-screen :p Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] video
On Sun, Jun 20, 2010 at 9:17 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Sun, 2010-06-20 at 21:06 -0400, Gregory Maxwell wrote: On Sun, Jun 20, 2010 at 8:23 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: AFAIK, at least Firefox shows a fullscreen option already in the context menu. What makes you think there is another attribute needed (besides @controls) ? So... an interesting bit of fun comes up when you use layout tricks to prevent the context menu in order to make save as impossible, and you eliminate the full screen option as an unwanted side effect. There is also the issue of the context menu not being an especially intuitive or discoverable way of activating it, especially if all the rest of the controls are buttons below the video. I think the context menu is a sensible place to find a fullscreen option short of a button existing as part of the video controls. Short of. Yes. But I think that the gap between the two is pretty big from a usability perspective (though I have no data to back this up) Also, if someone is daft enough to think that disabling the context menu will prevent people from saving their clips, then they deserve the pain of not being able to make the video play full-screen :p I can agree that it's usually a bad move... and people who do it to prevent saving belong in the same circle of hell as the people that send HTML mail to mailing lists (ahem :) ), but I think you're incorrect to assume that it's always a daft move. For example, what if you have a video available in multiple qualities and you believe it would be beneficial for the viewers of your site to be corralled into your official download page where they can get the most appropriate file, rather than getting the 'thumbnail' that comes out of the save as? ... if the save as works, many people are going to use it without even bothering to look at the superior download link. Or you might want to direct the user to a lower quality/cost distribution service which isn't suitable for streaming but works as well for non-realtime use. Even if your interest is in preventing downloads— simply slowing down most people most of the time may adequately address your need, and overlaying a transparent div to hide access to the controls is a perfectly workable way of doing that. In any case, I think the motivations of context-menu-prohibitions are mostly off topic here. The simple usability issue is enough to justify doing something, if something can actually be done.
Re: [whatwg] video
On Mon, Jun 21, 2010 at 1:06 PM, Gregory Maxwell gmaxw...@gmail.com wrote: So... an interesting bit of fun comes up when you use layout tricks to prevent the context menu in order to make save as impossible, and you eliminate the full screen option as an unwanted side effect. We actually have a patch that works harder to find a video element under the mouse position, to show the full-screen option in such cases. Of course, it could still be defeated. There is also the issue of the context menu not being an especially intuitive or discoverable way of activating it, especially if all the rest of the controls are buttons below the video. I agree. We do need an API for scripted fullscreen. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[whatwg] Fw: video
Sorry. forgot to use the correct mail address for the list. Gregory Maxwell gmaxw...@gmail.com schrieb am Sun, 20 Jun 2010 21:06:57 -0400: On Sun, Jun 20, 2010 at 8:23 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: AFAIK, at least Firefox shows a fullscreen option already in the context menu. What makes you think there is another attribute needed (besides @controls) ? So... an interesting bit of fun comes up when you use layout tricks to prevent the context menu in order to make save as impossible, and you eliminate the full screen option as an unwanted side effect. History has shown repeatedly that people will go to great lengths to do unbelievable stupid things. However, I do not believe that we should condone this — such a bozo copy protection scheme should never be a reason to make life anymore complex for users and implementors. Also, from a strategic point of view, if there is no possibility to disable certain useful functionality with the needed granularity (so that collateral damage is inevitable), malicious authors may get a clue and stop doing such things. There is also the issue of the context menu not being an especially intuitive or discoverable way of activating it, especially if all the rest of the controls are buttons below the video. If this is the only problem, it clearly is an an implementor issue. UAs could show a little fullscreen button besides the volume / mute controls, no extra markup attribute needed. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] Fw: video
On Mon, Jun 21, 2010 at 12:07 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: There is also the issue of the context menu not being an especially intuitive or discoverable way of activating it, especially if all the rest of the controls are buttons below the video. If this is the only problem, it clearly is an an implementor issue. UAs could show a little fullscreen button besides the volume / mute controls, no extra markup attribute needed. Not quite. Every functionality in the @controls this far has an analogous javascript function so that Web page authors that cannot activate the @controls and have to run their own (e.g. for corporate design issues) have the functionality to replace the buttons with a custom button. This would be required with a fullscreen button as part of the @controls, too. Honestly, is security with fullscreen really such a big issue that we absolutely cannot afford to have a javascript control for it? Cheers, Silvia.
