Re: [whatwg] Consensus on video element (scriptable) Full-Screen
That's Flash's behavior, not YouTube's choice - we'd love to allow fullscreen usage on one screen while focus is in another. This is the right way to do it, though - content can* *request changes to the fullscreen state, but the User Agent is ultimately responsible for granting or denying that request, or even changing arbitrarily later on. -John On Wed, Sep 22, 2010 at 1:52 AM, timeless wrote: > no. > > it is not ok to allow content authors to refuse to deliver content > unless they are "full screen". > > having events which enable providers to hold users hostage is a bad thing. > > if i have two screens today and try to watch a youtube video "full > screen" (with flash), it tries to unfullscreen when my focus shifts to > the other screen. > > this isn't proper. my system should not be held hostage to the whims > of providers.. >
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
If there are multiple elements on the page (e.g. multiple inline video players) that could go fullscreen, you still need some way to determine which of them the user intended to make fullscreen. My understanding is that was the point of designating a fullscreen element - it still requires that elements cooperate (by checking to see that they are the intended fullscreen element), but it's possible for them to do the right thing. If fullscreen was initiated at the document level, then the intended behavior is ambiguous, and I would expect none of the elements to go fullscreen. -John On Sun, Aug 8, 2010 at 10:50 PM, Robert O'Callahan wrote: > Fullscreen support for specific elements is more than just a convenience - > it's fairly common to have multiple elements on a page that could be made to > go fullscreen > > If the browser fullscreen API only supported making the entire page > fullscreen, you could make an element fullscreen by making the page > fullscreen and then making the element fill the page. > > This is in fact what the proposed API does. It just provides a convenient > way for authors to achieve it. > > > Rob > -- > "Now the Bereans were of more noble character than the Thessalonians, for > they received the message with great eagerness and examined the Scriptures > every day to see if what Paul said was true." [Acts 17:11] >
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
Fullscreen support for specific elements is more than just a convenience - it's fairly common to have multiple elements on a page that could be made to go fullscreen, such as a page with multiple video players. For YouTube, we've chosen to put our embeddable player within an , but I imagine some others will directly inline their player content. Mike, regarding your suggestions of element-level allow/deny attributes, I'm not sure I see how this can work. The root problem in your examples is that the page author is allowing untrusted content in their page. Ads should be sandboxed from the rest of the page for more than just prevention of fullscreen. -John On Fri, Aug 6, 2010 at 3:34 PM, Robert O'Callahan wrote: > On Sat, Aug 7, 2010 at 1:57 AM, Mike Wilcox wrote: > >> Regarding fullscreen elements: I appreciate the initiative, but I wonder >> if it's necessary to allow fullscreen at the element level? > > > It's not necessary, but it's a very useful convenience. It also allows the > UA to perform transition effects that are impossible just at the author > level. > > I think Simon is already pointing out potential gotchas. What exactly is >> the difference between a fullscreen-element and a fullscreen-page that has >> an element in absolutely position, top z-index, at 100% width and height? > > > Nothing; see the proposed UA style sheet additions in the spec. > > >> As a developer, after entering fullscreen I could possibly do a fancy >> transition of the element to take up 100%. >> > > You can't do it as well as the UA can, because a really good transition > effect involves desktop-level effects that authors don't have access to. For > example you might want part of the window to zoom out and cover the entire > screen, semi-transparent over the desktop while zooming. > > I would disrecommend authors trying to create custom transition effects > that depend on geometry; they probably won't work across browsers because > they'll interfere with the UA's effects. > > > Rob > -- > "Now the Bereans were of more noble character than the Thessalonians, for > they received the message with great eagerness and examined the Scriptures > every day to see if what Paul said was true." [Acts 17:11] >
Re: [whatwg] More YouTube response
Ok - sounds like pretty much unanimous objection to the idea of DRM plugins being instantiated via tag. I'll still be pushing on the DRM plugin providers to implement an interface that mimics the tag - my primary goal is to be able to have a single player implementation independent of whether or not DRM is involved. It's not the end of the world if one uses and the other uses . -John On Mon, Jul 5, 2010 at 8:45 AM, Nils Dagsson Moskopp < nils-dagsson-mosk...@dieweltistgarnichtso.net> wrote: > John Harding schrieb am Thu, 1 Jul 2010 15:59:37 > -0700: > > > 1. Standard Video Format > > […] > > On the current path, a content provider knows > > that by offering H.264 and WebM, they can reach all HTML5-capable > > browsers. This honestly is a reasonable state for YouTube right now > > - we use H.264 in cases outside the tag as well, but it would > > be nice to converge on a single baseline format at some point in the > > future. > > Practically, I think the ball is / was in Apple's court to decide this. > While to this day other browser makers have decided to ship two (!) > royalty-free video formats (Theora and VP8), Apple is the single H.264 > holdout, and they have a tight itegration to their hardware as well. > > Sadly, I do not have hope for any consolidation regarding video > formats. And while Youtube may be fine with having to provide only two > formats instead of a dozen, for the common smaller webmaster this is a > significant task, as transcoding resources are limited. > > Recently, I have been discussing implementation with the > administrator of an imageboard. It was ultimately decided to not add > this feature, precisely because of the multitude of video formats of > which none can be played in every modern browser. It's a shame. > > > […] > > > 3. Content Protection > > […] > > The basic requirements > > around content protection that we get from content owners basically > > consist of encrypting the content and limiting the decryption to a > > "verified" and authorized client - the realm of traditional DRM. > > This can not possibly work if you have an open standard, which by > design has to be implementable by everyone who cares, which includes a > wide range of free and proprietary software vendors. > > > Rather than ask browsers to get into the DRM business, what I think > > would work best is having a means for 3rd party DRM providers to > > supply browser plug-ins which implement the tag for protected > > content - not all that different than selecting a pluggable codec. > > To define a feature like that would hurt an otherwise open standard and > help to balkanize the browser market even more. If you really want to > do this, why not just use flash / java / whatever can deliver using > already available proprietary means ? > > > […] > > > Greetings, > -- > Nils Dagsson Moskopp // erlehmann > <http://dieweltistgarnichtso.net> >
Re: [whatwg] More YouTube response
MySpace is my canonical example - they allow arbitrary SWFs to be embedded in profiles, but not s. Flash added support a while back that allows containing pages to block SWFs from executing script or accessing the contents of the page, which MySpace enforces by rewriting the tag that users post. Before that, yes, allowing arbitrary SWFs to be posted by users was a huge security hole. Regardless, I think we're all agreed on the path forward (Use s to embed content instead of naked tags) and just need to start moving on it, and the ball is largely in YouTube's court on this point. -John On Fri, Jul 2, 2010 at 6:20 PM, Maciej Stachowiak wrote: > > On Jul 2, 2010, at 6:04 PM, Maciej Stachowiak wrote: > > > > > Any site which does that has a giant security hole, since Flash can be > used to arbitrarily script the embedding page. It's about as safe as > allowing embedding of arbitrary off-site
Re: [whatwg] More YouTube response
On Thu, Jul 1, 2010 at 9:16 PM, Aryeh Gregor > wrote: > > As several people pointed out (and which I tried to get at in my post), > this > > is really an ecosystem issue rather than a change needed in the spec or > in > > browsers. I suspect it's going to take some time, but the flexibility of > > embedding content via will be a big step forward. > > Wouldn't it be straightforward for YouTube to offer support > right now, in addition to ? The backend support should be > simple to do. If you keep the code as the default embed > recommendation and hide the embed code somewhere so people > will only use it if they look for it, you won't risk confusing anyone. > Sites that currently whitelist from YouTube will eventually > whitelist from YouTube too -- I hope there aren't many sites > that permit *arbitrary* s to be inserted by untrusted users. > Allowing will have other benefits, like allowing fallback > "install Flash" content (currently omitted from the code, I > assume to keep the size down). > Yes, it's pretty straightforward to offer -based embed code, but it needs to be coupled with getting sites to accept them, or we end up with a lot of confused, unhappy users. Note that sites don't generally whitelist specific SWFs - they generally allow all Flash embeds. > > Another thing that occurs to me is that you might show HTML5 video > when Flash isn't installed/enabled, or when the Flash player crashes. > Or at least you could give an option, instead of just failing silently > (for embeds) or saying the user should install Flash (on the site > itself). My primary machine runs Linux, and Flash usually doesn't > work at all. If I didn't know about the HTML5 beta, I wouldn't be > able to use YouTube at all. And as it is, I can't use any YouTube > embeds most of the time. > Yes, this is the main point of using an to embed code - it allows the site providing embeddable content to tailor the presentation to the user/device/context at runtime, rather than requiring the presentation to be fixed up-front. > > > When limiting keyboard input, I'd suggest devices w/ onscreen keyboards > > simply disable the keyboard. Applications that work well with touch > > interfaces generally provide gesture alternatives for the limited set of > > keys that would be available. Alternately, devices could limit the > keyboard > > to the set of allowed keys. > > The problem is if the program makes a fake keyboard and then directly > intercepts touch events to that location, without invoking the OS's > keyboard at all. The user won't be able to tell that the keypresses > are going to the website instead of the OS. But I can't see this as > being a big issue -- screen space is so limited on these devices that > websites are fullscreen anyway, or practically. On my Nexus One, > unless you're scrolled to the top of the site, websites take up the > whole screen except for the bar at the top, which is present in all > apps. So they could already trivially spoof any application, if they > know the target platform. Not if the user presses the menu button, I > guess. > Yeah, I realized that loophole after I sent the mail. The same vulnerability is there if fullscreen is initiated by a control the browser chrome, though - at the end of the day, the primary problem to solve is ensuring that users understand they're still viewing a web page, and the contents are provided by the web page rather than the OS. > > As pointed out, this is not strictly an issue for tag, though > > certainly related especially for local preview. I have not been closely > > following the work on the element, though that seems to be where > > this is headed. > > adoption shouldn't interfere with adoption, though. > Even if YouTube switched to by default, it could keep Flash > for recording until was implemented. It's probably best for > implementers to focus on perfecting (and maybe , etc.) > before they put too much work into , since those are much > bigger use-cases. > You're absolutely right, and I think the order things are going is correct - is more important than
Re: [whatwg] More YouTube response
On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Hunt wrote: > On 2010-07-02 13:56, Julian Reschke wrote: > >> On 02.07.2010 13:38, Anne van Kesteren wrote: >> >>> Whether playing video requires a plugin is very much an issue for this >>> list, I think. What Henri explained -- not having lock-in to a >>> particular platform because of proprietary plugins -- is a large part of >>> the reason why we have in the first place. >>> >> >> That may be true. >> >> But there's nothing in the spec that actually disallows adding support >> for plugin-based DRM, right? (Just clarifying) >> > > Correct. Vendors can theoretically implement any codec or container they > like, with any features or limitations they like. > > MP4 already has various DRM schemes in use. Apple, for example, could > support FairPlay protected videos, though the use of such content with > would effectively be limited to within iTunes. > > Even Matroska has elements that can be used for general purpose encryption > and DRM purposes, though these features were not included within WebM. But > theoretically, those features could be added and implemented with some > agreed upon encryption scheme. > > I would still, however, argue against anything of the sort being added to > WebM because DRM doesn't do anything to protect content, but is rather used > as a way for content providers to control the market by blocking unwanted > innovation and competition that they don't like, including open source > software. > > I think it's unavoidable that the functionality of the tag in some browsers will be extended by various add-ons to the browser. IE's implementation uses whatever codecs are installed and available to DirectShow; my understanding is that Safari operates this way as well. My point here is primarily that it would be good for tag adoption in general if browsers enabled traditional DRM solutions to integrate in this way. It still requires that users will have some non-open software installed on their machine (that's unavoidable as long as content owners require it of us), but means that users can continue using their browser of choice, and content distributors don't need to write a completely new player for each DRM provider they need to support.
[whatwg] More YouTube response
Glad to see my post spurred some good discussion - I'll try to address topic by topic below, but one of the great points made is that some of the functionality YouTube needs from browsers probably doesn't belong in the HTML5 spec (e.g. streaming, content protection). I'm happy to take those discussions elsewhere if this forum is inappropriate, but it seems like it would likely be the same group of people, just on a different mailing list. 1. Standard Video Format Yes, this has been debated a lot, and I generally agree that leaving it out of the spec was the best way forward for the spec. Shane Fagan pointed out that Flash supports multiple different codecs, which is true, but every version since Flash 7 has supported Sorenson Spark video and MP3 audio. I don't think anyone is suggesting that browsers shouldn't support multiple codecs, but having a consistent baseline is important. On the current path, a content provider knows that by offering H.264 and WebM, they can reach all HTML5-capable browsers. This honestly is a reasonable state for YouTube right now - we use H.264 in cases outside the tag as well, but it would be nice to converge on a single baseline format at some point in the future. 2. Robust Video Streaming Andy Berkheimer on our team has been putting some thought into this, so I'll defer to him for more specific proposals. For an app like YouTube, it is *extremely *useful to have fine-grained control over how the browser fetches media from the server. Whether the details belong in the HTML5 spec or not depends on the preferred design - something similar to Flash 10.1's appendBytes() mechanism would affect the tag interface, for example, while a transport protocol could be completely separate. 3. Content Protection Some of the discussion here seems to have conflated application-controlled video delivery with content protection, but in an ideal world, the two are independent. The basic requirements around content protection that we get from content owners basically consist of encrypting the content and limiting the decryption to a "verified" and authorized client - the realm of traditional DRM. Rather than ask browsers to get into the DRM business, what I think would work best is having a means for 3rd party DRM providers to supply browser plug-ins which implement the tag for protected content - not all that different than selecting a pluggable codec. 4. Encapsulation and Embedding As several people pointed out (and which I tried to get at in my post), this is really an ecosystem issue rather than a change needed in the spec or in browsers. I suspect it's going to take some time, but the flexibility of embedding content via will be a big step forward. 5. Fullscreen Maciej actually covered YouTube's requirements pretty well. I'd add that it's not just controls that are important for us to maintain: we have a lot of additional content that needs to display with and sometimes on top of the video - our interactive annotations, captions, and ads most notably. Maciej's proposal also looks fairly reasonable, though some thoughts on it: When limiting keyboard input, I'd suggest devices w/ onscreen keyboards simply disable the keyboard. Applications that work well with touch interfaces generally provide gesture alternatives for the limited set of keys that would be available. Alternately, devices could limit the keyboard to the set of allowed keys. Keyboard restrictions are better than not having fullscreen support, though they do limit functionality - it would prevent us from supporting search in fullscreen mode, for example. 6. Camera and Micrphone access As pointed out, this is not strictly an issue for tag, though certainly related especially for local preview. I have not been closely following the work on the element, though that seems to be where this is headed. -John
