(In reply to comment #0)
> This may seem like an acceptable alternative, but it requires extra machine
> resources, and playback may not be as smooth, depending on machine resources.
> It's an ugly kludge but it is the only way for an author or editor to have
> complete control over the playback of the video. 

It seems acceptable *because* it's not as good.  When we can't prevent authors from doing user-hostile things, making the user-hostile thing worse than the user-friendly thing is an acceptable fallback.  In this case we don't even have to do anything proactive - the clunkiness just happens for free.

In addition to being hostile to users in general, this seems to be *extra* bad for users with disabilities, who may need access to the video's playback to view the content effectively.

(The only case I can imagine where this isn't actively user-hostile is using a <video> to do some type of animation in a game.  It seems perfectly normal to draw it into the <canvas> then, so the "workaround" is actually just the standard procedure.)

(In reply to comment #1)
> (In reply to comment #0)
> > This may seem like an acceptable alternative, but it requires extra machine
> > resources, and playback may not be as smooth, depending on machine resources.
> > It's an ugly kludge but it is the only way for an author or editor to have
> > complete control over the playback of the video. 
> 
> It seems acceptable *because* it's not as good.  When we can't prevent authors
> from doing user-hostile things, making the user-hostile thing worse than the
> user-friendly thing is an acceptable fallback.  In this case we don't even have
> to do anything proactive - the clunkiness just happens for free.
> 
> In addition to being hostile to users in general, this seems to be *extra* bad
> for users with disabilities, who may need access to the video's playback to
> view the content effectively.
> 
> (The only case I can imagine where this isn't actively user-hostile is using a
> <video> to do some type of animation in a game.  It seems perfectly normal to
> draw it into the <canvas> then, so the "workaround" is actually just the
> standard procedure.)

Some would say embedding a complex image into a web page without providing a link to an in-depth textual description in a separate page is also "user hostile". The term "user hostile" is subjective. 

You're basing your disagreement with this request on a value judgment, but you're not providing a solid technical rationale why this additional control can't be provided. And you're making an assumption that a developer or author wants this capability because they're somehow hostile to users, which is, again, a very subjective assumption. 

There is no technical reason _not_ to provide this finer control. There are, however, sound technical reasons for providing this finer control--not the least of which not providing this functionality will either force the developer/author into relying on previous technology (such as Flash) or using a kludge to get the behavior they need.

In addition, continuing to allow playback options in the context menu when controls is not present also adds additional complexity to applications that provide custom controls. They not only have to listen for events triggered by their own custom controls, but also to handle events triggered by the menu.

(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > This may seem like an acceptable alternative, but it requires extra machine
> > > resources, and playback may not be as smooth, depending on machine resources.
> > > It's an ugly kludge but it is the only way for an author or editor to have
> > > complete control over the playback of the video. 
> > 
> > It seems acceptable *because* it's not as good.  When we can't prevent authors
> > from doing user-hostile things, making the user-hostile thing worse than the
> > user-friendly thing is an acceptable fallback.  In this case we don't even have
> > to do anything proactive - the clunkiness just happens for free.
> > 
> > In addition to being hostile to users in general, this seems to be *extra* bad
> > for users with disabilities, who may need access to the video's playback to
> > view the content effectively.
> > 
> > (The only case I can imagine where this isn't actively user-hostile is using a
> > <video> to do some type of animation in a game.  It seems perfectly normal to
> > draw it into the <canvas> then, so the "workaround" is actually just the
> > standard procedure.)
> 
> Some would say embedding a complex image into a web page without providing a
> link to an in-depth textual description in a separate page is also "user
> hostile". The term "user hostile" is subjective. 
> 
> You're basing your disagreement with this request on a value judgment, but
> you're not providing a solid technical rationale why this additional control
> can't be provided. And you're making an assumption that a developer or author
> wants this capability because they're somehow hostile to users, which is,
> again, a very subjective assumption. 
> 
> There is no technical reason _not_ to provide this finer control. There are,
> however, sound technical reasons for providing this finer control--not the
> least of which not providing this functionality will either force the
> developer/author into relying on previous technology (such as Flash) or using a
> kludge to get the behavior they need.

I think you are arguing for two things here, IIUC: one is a finer resolution of timeupdate, so the  developer has more control over what is happening with the video/audio, and a second one (below) about removing context menus. Right?


> In addition, continuing to allow playback options in the context menu when
> controls is not present also adds additional complexity to applications that
> provide custom controls. They not only have to listen for events triggered by
> their own custom controls, but also to handle events triggered by the menu.

They are the same events. I don't understand what issue the context menus are creating since they are not raising separate events, but the same ones that the JS needs to listen to already.

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > (In reply to comment #0)
> > > > This may seem like an acceptable alternative, but it requires extra machine
> > > > resources, and playback may not be as smooth, depending on machine resources.
> > > > It's an ugly kludge but it is the only way for an author or editor to have
> > > > complete control over the playback of the video. 
> > > 
> > > It seems acceptable *because* it's not as good.  When we can't prevent authors
> > > from doing user-hostile things, making the user-hostile thing worse than the
> > > user-friendly thing is an acceptable fallback.  In this case we don't even have
> > > to do anything proactive - the clunkiness just happens for free.
> > > 
> > > In addition to being hostile to users in general, this seems to be *extra* bad
> > > for users with disabilities, who may need access to the video's playback to
> > > view the content effectively.
> > > 
> > > (The only case I can imagine where this isn't actively user-hostile is using a
> > > <video> to do some type of animation in a game.  It seems perfectly normal to
> > > draw it into the <canvas> then, so the "workaround" is actually just the
> > > standard procedure.)
> > 
> > Some would say embedding a complex image into a web page without providing a
> > link to an in-depth textual description in a separate page is also "user
> > hostile". The term "user hostile" is subjective. 
> > 
> > You're basing your disagreement with this request on a value judgment, but
> > you're not providing a solid technical rationale why this additional control
> > can't be provided. And you're making an assumption that a developer or author
> > wants this capability because they're somehow hostile to users, which is,
> > again, a very subjective assumption. 
> > 
> > There is no technical reason _not_ to provide this finer control. There are,
> > however, sound technical reasons for providing this finer control--not the
> > least of which not providing this functionality will either force the
> > developer/author into relying on previous technology (such as Flash) or using a
> > kludge to get the behavior they need.
> 
> I think you are arguing for two things here, IIUC: one is a finer resolution of
> timeupdate, so the  developer has more control over what is happening with the
> video/audio, and a second one (below) about removing context menus. Right?
> 

No, this is about context menus, not timeupdate. 

> 
> > In addition, continuing to allow playback options in the context menu when
> > controls is not present also adds additional complexity to applications that
> > provide custom controls. They not only have to listen for events triggered by
> > their own custom controls, but also to handle events triggered by the menu.
> 
> They are the same events. I don't understand what issue the context menus are
> creating since they are not raising separate events, but the same ones that the
> JS needs to listen to already.


No, not really. 

If I create a custom control, I'm listening to the click even on the buttons not the play or pause events on the video object. 

If I'm enabling or disabling buttons based on play or not of the video, I have to listen to both sets of events. If removing the controls attribute also disabled the context menu, I'd only have to listen to the button events. 

My custom control is no longer the only place where the user can begin video playback.

What's the concrete suggestion? To add a nocontrols="" attribute to prevent browsers from exposing any UI, even in context menus? You can instead just prevent the context menu from appearing at all, using a variety of tricks.

Regardless of what is done, you can always write an extension to re-enable the browser-native UI, so I'm not sure what the point is.

(In reply to comment #5)
> What's the concrete suggestion? To add a nocontrols="" attribute to prevent
> browsers from exposing any UI, even in context menus? You can instead just
> prevent the context menu from appearing at all, using a variety of tricks.
> 
> Regardless of what is done, you can always write an extension to re-enable the
> browser-native UI, so I'm not sure what the point is.

I believe I made two concrete suggestions in my initial bug report. 

Suggestion 1: allow controls to have multiple settings, one of which is to remove the controls completely. And that the web page author/developer really means it: remove it completely. 

Suggestion 2: that when the author or developer does not provide the controls attribute, all of the media controls are removed or disabled. The UI is removed, the context menu options are disabled. 

There is no viable technical reason not to give the web page author/developer this level of control over the media elements. I have shown that there is a viable technical reason to ensure they have this level of control over the media elements.

Another way the web page author/developer can assert themselves: just provide a transparent div overlay over the media control. 

Simpler than the use of the canvas element, but still a kludge. Authors/developers shouldn't have to use these types of kludges.

Is the problem that a user can seek in the video or pause it? If so, what ill effects can come of that? When seeking, to the page it will just take a longer/shorter time before the ended event is fired, which should not typically be a problem. For playing/pausing, if the page assumed that it was in control, it wouldn't listen to the play/pause events at all, so it would presumably be just as if the network came to a halt.

Some details on "there may be a good reason" might help.

(In reply to comment #8)
> Is the problem that a user can seek in the video or pause it? If so, what ill
> effects can come of that? When seeking, to the page it will just take a
> longer/shorter time before the ended event is fired, which should not typically
> be a problem. For playing/pausing, if the page assumed that it was in control,
> it wouldn't listen to the play/pause events at all, so it would presumably be
> just as if the network came to a halt.
> 
> Some details on "there may be a good reason" might help.

Seems comments 2 and 4 above.

(In reply to comment #8)
> Is the problem that a user can seek in the video or pause it? If so, what ill
> effects can come of that? When seeking, to the page it will just take a
> longer/shorter time before the ended event is fired, which should not typically
> be a problem. For playing/pausing, if the page assumed that it was in control,
> it wouldn't listen to the play/pause events at all, so it would presumably be
> just as if the network came to a halt.
> 
> Some details on "there may be a good reason" might help.

And I'll ask in return: what was the technical reason for removing playback control for the media elements from the web page author/developer?

(In reply to comment #0)
> that a developer or author can also choose to remove playback functionality
> from the context menu in addition to the UI. Or the addition of the playback
> functionality to the context menu should be disabled when the controls
> attribute is not present on the element.

The author still doesn't have total control. Some user agents allow the user to bring up a list of media on the page. From there the user can control them, whether or not a controls attribute is present. Some user agents allow a 'web console' for a page to be displayed allow the user to access the media element and control it via the DOM. At what point do you choose to stop the user from controlling the software running on their machine?

(In reply to comment #11)
> (In reply to comment #0)
> > that a developer or author can also choose to remove playback functionality
> > from the context menu in addition to the UI. Or the addition of the playback
> > functionality to the context menu should be disabled when the controls
> > attribute is not present on the element.
> 
> The author still doesn't have total control. Some user agents allow the user to
> bring up a list of media on the page. From there the user can control them,
> whether or not a controls attribute is present. Some user agents allow a 'web
> console' for a page to be displayed allow the user to access the media element
> and control it via the DOM. At what point do you choose to stop the user from
> controlling the software running on their machine?

We cannot control what user agents do on their own. User agents will do what they'll do. Web page authors/developers have had to deal with "creative" user agents for the last 15 years. 

All we can control in this space is what is included in the W3C HTML5 specification.

(In reply to comment #9)
> (In reply to comment #8)
> > Is the problem that a user can seek in the video or pause it? If so, what ill
> > effects can come of that? When seeking, to the page it will just take a
> > longer/shorter time before the ended event is fired, which should not typically
> > be a problem. For playing/pausing, if the page assumed that it was in control,
> > it wouldn't listen to the play/pause events at all, so it would presumably be
> > just as if the network came to a halt.
> > 
> > Some details on "there may be a good reason" might help.
> 
> Seems comments 2 and 4 above.

So, "to allow playback options in the context menu when controls is not present also adds additional complexity to applications that provide custom controls. They not only have to listen for events triggered by their own custom controls, but also to handle events triggered by the menu."

As per above, it doesn't seem like this would actually be a problem. If a script assumes that it is the only thing in control of the video, then it won't be listening to seek events and the change in currentTime will most likely go unnoticed. Playing/pausing will appear mostly as if the browser had to stop for buffering.

Can you provide some real-world example of pages/scripts that don't intend the user to the play/pause/seek and that therefore makes assumptions that will break the page/script if the user actually does?

If more pages start to use audio/video and try hard to not make the user be able to interrupt it, then we're just going to add page-wide UI to pause or mute all media elements on a page. Why would we ever want a page to be able to override a user in these decisions?

(In reply to comment #10)
> And I'll ask in return: what was the technical reason for removing playback
> control for the media elements from the web page author/developer?

Do you mean why the controls attribute was omitted? Usually, because they look different in all UIs and don't match the design of the embedding page. If some page author thought it would also guarantee that the user couldn't pause their video, they were wrong.

(In reply to comment #13)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Is the problem that a user can seek in the video or pause it? If so, what ill
> > > effects can come of that? When seeking, to the page it will just take a
> > > longer/shorter time before the ended event is fired, which should not typically
> > > be a problem. For playing/pausing, if the page assumed that it was in control,
> > > it wouldn't listen to the play/pause events at all, so it would presumably be
> > > just as if the network came to a halt.
> > > 
> > > Some details on "there may be a good reason" might help.
> > 
> > Seems comments 2 and 4 above.
> 
> So, "to allow playback options in the context menu when controls is not present
> also adds additional complexity to applications that provide custom controls.
> They not only have to listen for events triggered by their own custom controls,
> but also to handle events triggered by the menu."
> 
> As per above, it doesn't seem like this would actually be a problem. If a
> script assumes that it is the only thing in control of the video, then it won't
> be listening to seek events and the change in currentTime will most likely go
> unnoticed. Playing/pausing will appear mostly as if the browser had to stop for
> buffering.

Let's see if I can make this more clear:

This is about play and pause. If the play and pause options are in the context menu, then when the user begins play or pause may now be happening in two different places: in the web developer's custom control and in the context menu. 

If the developer wants to do other activity based on a request to play the resource, they now have to capture the play event on the video as well as whatever events they need to capture in order to facilitate playing on their custom controls. 

More importantly, if the web developer or author wants to control if and when the user can start or pause playback, they have no way of doing so other than a hack, such as a transparent div over the video element in order to "disable" the context menu. 

If the web page author incorporates the video as part of the page presentation and playback is integral to the page's purpose, they have no way to absolutely control the playback because of the context menu option. 

> 
> Can you provide some real-world example of pages/scripts that don't intend the
> user to the play/pause/seek and that therefore makes assumptions that will
> break the page/script if the user actually does?
>

Consider a video with three buttons underneath: play, pause, and stop. Playback is controlled by the buttons. The code for the button's click event handler not only plays or pauses the video, but also enables and disables the buttons based on what action the user can take next. When the user clicks the play button, the stop and pause buttons are enabled, the play is disabled, and so on.

Instead of clicking the buttons, the user clicks the context menu play option.

Now, the developer not only has to listen for the button click events, but also the video play and pause events. They can code around the issue, except for one thing: they can't control the options that show in the context menu.

The custom control doesn't have a fullscreen option. The web page developer doesn't want the video to play fullscreen. Agree or not, the web page developer doesn't want the video to play fullscreen. 

The user agent provides fullscreen as an option in the context menu. There is no way for the developer to "code around" this problem, other than using a kludge such as a transparent div overlay over the video element.
 
The specification states that the controls attribute means that the web page author/developer is not providing a custom control. This is a bad way of defining this attribute. There may be more than one reason why a person would deliberately not add the controls attribute to the page--it's not up to the HTML5 specification to determine intent, only to describe consistent functional behavior. 

It could be that when the author or developer leaves off the controls attribute, they mean leave off the controls, period. For whatever reason. 

 
> If more pages start to use audio/video and try hard to not make the user be
> able to interrupt it, then we're just going to add page-wide UI to pause or
> mute all media elements on a page. Why would we ever want a page to be able to
> override a user in these decisions?
> 

Why would the HTML5 specification override the web page author and developer's wishes? They don't matter? Are web developers an encumbrance to be worked around?

We're forcing developers into using kludges because we're not giving developers options to completely control the media elements. 

> (In reply to comment #10)
> > And I'll ask in return: what was the technical reason for removing playback
> > control for the media elements from the web page author/developer?
> 
> Do you mean why the controls attribute was omitted? Usually, because they look
> different in all UIs and don't match the design of the embedding page. If some
> page author thought it would also guarantee that the user couldn't pause their
> video, they were wrong.

No, why was it decided that web developers cannot have complete control over the media element's playback? What was the technical reason to remove such control from the web developer?

Frankly, removing the ability for web developers and authors to control the playback of the media elements is a very author/developer hostile move.

And authors/developers are users, too. Just from a different perspective.

(In reply to comment #15)
> Frankly, removing the ability for web developers and authors to control the
> playback of the media elements is a very author/developer hostile move.
> 

Which part of the spec exactly does this? Can you show alternative text you'd prefer? Can't you just raise a bug with user agents saying they're providing controls when you've omitted the controls attribute and would expect no controls to appear?

(In reply to comment #16)
> (In reply to comment #15)
> > Frankly, removing the ability for web developers and authors to control the
> > playback of the media elements is a very author/developer hostile move.
> > 
> 
> Which part of the spec exactly does this? Can you show alternative text you'd
> prefer? Can't you just raise a bug with user agents saying they're providing
> controls when you've omitted the controls attribute and would expect no
> controls to appear?

http://dev.w3.org/html5/spec/the-iframe-element.html#attr-media-controls

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > Frankly, removing the ability for web developers and authors to control the
> > > playback of the media elements is a very author/developer hostile move.
> > > 
> > 
> > Which part of the spec exactly does this? Can you show alternative text you'd
> > prefer? Can't you just raise a bug with user agents saying they're providing
> > controls when you've omitted the controls attribute and would expect no
> > controls to appear?
> 
> http://dev.w3.org/html5/spec/the-iframe-element.html#attr-media-controls

Thanks, which part of that removes "the ability for web developers and authors to control the playback of the media elements" and how would you change it to fix it?

(In reply to comment #14)
> Why would the HTML5 specification override the web page author and developer's
> wishes? They don't matter? Are web developers an encumbrance to be worked
> around?

If we don't give users the ultimate control over if/when video and audio plays, they'll switch to a browser which does. If the spec tried to forbid implementors from doing this, then it will just be ignored.

> We're forcing developers into using kludges because we're not giving developers
> options to completely control the media elements. 

All cases of disabling the context menu that I'm aware of have been to make it harder to download the resource, not because the script was unable to deal with play/pause from scripts. Which real-word sites are using "kludges" because of the pause/play/seek problem?

> > (In reply to comment #10)
> > > And I'll ask in return: what was the technical reason for removing playback
> > > control for the media elements from the web page author/developer?
> > 
> > Do you mean why the controls attribute was omitted? Usually, because they look
> > different in all UIs and don't match the design of the embedding page. If some
> > page author thought it would also guarantee that the user couldn't pause their
> > video, they were wrong.
> 
> No, why was it decided that web developers cannot have complete control over
> the media element's playback? What was the technical reason to remove such
> control from the web developer?

It wasn't removed, it was never there. It's really the same situation with user style sheets, extensions, ad blockers, pop-up blockers, click-to-play plugins, etc. Sometimes users use these to override authors. Sometimes that breaks pages. The best way to avoid that happening is to not do things that users will want to override.

(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > (In reply to comment #15)
> > > > Frankly, removing the ability for web developers and authors to control the
> > > > playback of the media elements is a very author/developer hostile move.
> > > > 
> > > 
> > > Which part of the spec exactly does this? Can you show alternative text you'd
> > > prefer? Can't you just raise a bug with user agents saying they're providing
> > > controls when you've omitted the controls attribute and would expect no
> > > controls to appear?
> > 
> > http://dev.w3.org/html5/spec/the-iframe-element.html#attr-media-controls
> 
> Thanks, which part of that removes "the ability for web developers and authors
> to control the playback of the media elements" and how would you change it to
> fix it?

I believe I have answered these questions. I would suggest you read the previous comments.

(In reply to comment #19)
> (In reply to comment #14)
> > Why would the HTML5 specification override the web page author and developer's
> > wishes? They don't matter? Are web developers an encumbrance to be worked
> > around?
> 
> If we don't give users the ultimate control over if/when video and audio plays,
> they'll switch to a browser which does. If the spec tried to forbid
> implementors from doing this, then it will just be ignored.
> 

What you're saying is that the browser makers are indifferent to the needs of developers/authors? Well, there is some truth to this.  

The web developers can work around the intransigence of the browser makers if need be. However, it would be better if there were options that gave the developers the flexibility they need without having to use kludges. 


> > We're forcing developers into using kludges because we're not giving developers
> > options to completely control the media elements. 
> 
> All cases of disabling the context menu that I'm aware of have been to make it
> harder to download the resource, not because the script was unable to deal with
> play/pause from scripts. Which real-word sites are using "kludges" because of
> the pause/play/seek problem?

I'm not talking about disabling the context menu directly--I'm not talking about disabling the options. Gray them out. 

I don't believe there's a restriction on bugs that requires that we hunt down "real world" examples, especially for a specification that's still in LC status and still undergoing significant changes. 

I believe the purpose of these bugs is to create a specification that helps prevent future kludges.

 
> 
> > > (In reply to comment #10)
> > > > And I'll ask in return: what was the technical reason for removing playback
> > > > control for the media elements from the web page author/developer?
> > > 
> > > Do you mean why the controls attribute was omitted? Usually, because they look
> > > different in all UIs and don't match the design of the embedding page. If some
> > > page author thought it would also guarantee that the user couldn't pause their
> > > video, they were wrong.
> > 
> > No, why was it decided that web developers cannot have complete control over
> > the media element's playback? What was the technical reason to remove such
> > control from the web developer?
> 
> It wasn't removed, it was never there. It's really the same situation with user
> style sheets, extensions, ad blockers, pop-up blockers, click-to-play plugins,
> etc. Sometimes users use these to override authors. Sometimes that breaks
> pages. The best way to avoid that happening is to not do things that users will
> want to override.

But these actions are between the user and the user agent, and the developer and the user agent--these actions are not codified in the specification.

> What you're saying is that the browser makers are indifferent to the needs of
> developers/authors? Well, there is some truth to this.  

Not indifferent, but we have very strong incentives to put the wishes of users above the wishes of authors in cases where authors have the tools to do annoying things. Audio playback is definitely such a case.

> The web developers can work around the intransigence of the browser makers if
> need be. However, it would be better if there were options that gave the
> developers the flexibility they need without having to use kludges. 

The best way to "work around" the problem is to just handle the few extra events needed to make it work. Allowing pages to force audio/video playback without the option for users to override it is not an option, as users are asking us to add *more* such overrides, not remove them.

> But these actions are between the user and the user agent, and the developer
> and the user agent--these actions are not codified in the specification.

Neither is the context menu or UI to pause/mute all elements in a page.

(In reply to comment #22)
> > What you're saying is that the browser makers are indifferent to the needs of
> > developers/authors? Well, there is some truth to this.  
> 
> Not indifferent, but we have very strong incentives to put the wishes of users
> above the wishes of authors in cases where authors have the tools to do
> annoying things. Audio playback is definitely such a case.

But that's a subjective opinion, not a technique limitation. You're making assumptions about why the author or developer is choosing not to display the default controls (in UI or context menu)--to the point where you're abrogating their ability to have fine control over the media elements in their web pages and apps.

> 
> > The web developers can work around the intransigence of the browser makers if
> > need be. However, it would be better if there were options that gave the
> > developers the flexibility they need without having to use kludges. 
> 
> The best way to "work around" the problem is to just handle the few extra
> events needed to make it work. Allowing pages to force audio/video playback
> without the option for users to override it is not an option, as users are
> asking us to add *more* such overrides, not remove them.
>

The simplest and easiest "override" the user has is to leave the page and not come back. They've always had this option. 

And as I've shown, developers can apply hacks to work around the, well, for want of a better term, developer hostility that's embedded in HTML5. 

We don't want people to have to hack things. We want to provide granularity of control so that they have the ability to turn things on, and off, as needed. 

Then if they create an annoying page, well, users can blow the developers a bit raspberry, leave and never come back. 

It's not really the HTML5 spec's place to come between the users and the web developers. We're not the enemy. 

 
> > But these actions are between the user and the user agent, and the developer
> > and the user agent--these actions are not codified in the specification.
> 
> Neither is the context menu or UI to pause/mute all elements in a page.

Actually, it is, in the section I linked earlier. The problem is, the specification states user agents may or may not provide the context menu, but then left the implementation of such a menu to the user agent. The only requirement on the context menu items is which events the options fire. 

We developers and authors have no granularity of control of the media elements. We have only the illusion of control.

Sorry, typo:

users can blow the developers a big raspberry...

(and for those not familiar with the term, "raspberry" in this context is a derisive or contemptuous sound)

Question Philipe: how do you prevent the user from selecting fullscreen from the context menu of a video element in Firefox?

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Media element implementers from two major browsers have commented here questioning the utility of the proposed change.  The overriding principle guiding the development of web standards today is that they must match implementations.  If implementers are not interested in implementing the feature, it's a nonstarter.  Currently it seems that there's no implementer interest here.  If at least one major implementer is interested in implementing this feature, please reopen the bug.  Otherwise the spec will not change.  We do not spec features that will not be implemented, because it wastes everyone's time.

(In reply to comment #21)
> I don't believe there's a restriction on bugs that requires that we hunt down
> "real world" examples, especially for a specification that's still in LC status
> and still undergoing significant changes. 

Bug filers are not required to provide real-world use-cases for features they propose.  However, bugs that don't have clear use-cases are much more likely to be closed NEEDSINFO or WONTFIX, so it's wise to explain the use-cases you're trying to meet in as much detail and with as much supporting evidence as possible.  In addition to lacking implementer support, your comments here do not convincingly demonstrate that there are pages that need this feature.

(In reply to comment #26)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the Editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the Tracker Issue; or you may create a Tracker Issue
> yourself, if you are able to do so. For more details, see this document:
> 
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: Media element implementers from two major browsers have commented
> here questioning the utility of the proposed change.  The overriding principle
> guiding the development of web standards today is that they must match
> implementations.  If implementers are not interested in implementing the
> feature, it's a nonstarter.  Currently it seems that there's no implementer
> interest here.  If at least one major implementer is interested in implementing
> this feature, please reopen the bug.  Otherwise the spec will not change.  We
> do not spec features that will not be implemented, because it wastes everyone's
> time.
> 
> (In reply to comment #21)
> > I don't believe there's a restriction on bugs that requires that we hunt down
> > "real world" examples, especially for a specification that's still in LC status
> > and still undergoing significant changes. 
> 
> Bug filers are not required to provide real-world use-cases for features they
> propose.  However, bugs that don't have clear use-cases are much more likely to
> be closed NEEDSINFO or WONTFIX, so it's wise to explain the use-cases you're
> trying to meet in as much detail and with as much supporting evidence as
> possible.  In addition to lacking implementer support, your comments here do
> not convincingly demonstrate that there are pages that need this feature.


There are many different real world examples--all using Flash. Just check out the many movie-specific web sites. If you need a start, I would suggest the following:


http://www.transformersmovie.com/

http://thor.marvel.com/

Even the ever popular Harry Potter movie site

http://harrypotter.warnerbros.com/harrypotterandthedeathlyhallows/mainsite/index.html

And they'll most likely continue to use Flash, because HTML5 video too heavily restricts the web developer/author.

Again, does no good to do a TrackerRequest. The W3C cares little for the quality of the HTML5 specification.

mass-move component to LC1