Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On Fri, 08 Jun 2012 05:05:11 +0200, Mark Callow callow_m...@hicorp.co.jp wrote: On 08/06/2012 06:09, Ian Hickson wrote: The dire warning doesn't work. I'm just saying that's the direction that operating system vendors have been going in; that disallowing it in the browser case is not a different direction, it's consistent with the industry's direction as a whole. The platform providers want control so they can extract money from application developers; Sure. Although in most cases they are not in a position to enforce this. You *can* choose another browser - or even make your own. If you don't, then you're failing to keep your side of the freedom bargain (the price of freedom is eternal vigilance) they do it under the guise of safety security so people will go along with it. Governments get control over people in the same way. The comment is sometimes true. It is also true that users get very upset *at the browser* when it permits things to happen that theyhadn't expected. The same-origin security policy that is rampant on the Web is clearly unhelpful in many ways. And doesn't have any particular benefit for browser manufacturers, except that it protects users. In both cases it is an existential threat to freedom and civil liberties. I think that is overstating the case. A *lot*. Nobody forces you to follow the way this is specified. You can just implement something different, and nobody will stop you. That happens all the time, for different issues. It is simply untrue to say that nobody will *let* you make your own browser. We write the spec so you can more easily figure out how to make it compatible with the web - in other words, to *help* you do so. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. Firefox appears to allow cross-origin windows find each other by name. This is actually necessary for web compat, last I checked, if the cross-origin window is one that you opened or one that you are framing. Do other UAs not allow navigating the cross-origin window in those situations? There are lots of cases in which cross-origin windows in fact cannot find each other by name in Firefox. Perhaps that's the bug you're referring to? No, I'm talking about the fact that Firefox just has no concept of related browsing context and treats them all as related. -Boris
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, Jun 19, 2012 at 11:38 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. Then the wording should be changed. However, that belongs in a different proposal than this one. Firefox appears to allow cross-origin windows find each other by name. This is actually necessary for web compat, last I checked, if the cross-origin window is one that you opened or one that you are framing. Do other UAs not allow navigating the cross-origin window in those situations? Those cases are explicitly allowed in http://dev.w3.org/html5/spec/single-page.html#allowed-to-navigate, and other user agents also support that case. (I tested by navigating a named window I had opened and navigated cross-origin. I confirmed that Chrome, Safari, Firefox, and Opera all let the opener window find the named cross-origin window. IE doesn't work in that case, though.) There are lots of cases in which cross-origin windows in fact cannot find each other by name in Firefox. In my earlier email, I was testing a case where window A opens a named window B. I then navigate B to a different origin and create window C from scratch. C is able to find B by name in Firefox, but not in other user agents. (That's consistent with your description that Firefox considers all windows related.) Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, 19 Jun 2012, Charlie Reis wrote: On Tue, Jun 19, 2012 at 11:38 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. Then the wording should be changed. However, that belongs in a different proposal than this one. The way the process here works is that Hixie reads these emails agrees that the change is a good idea (hopefully; in this case it seems likely since we seem to have three implementors in agreement) and it happens. There isn't any need for seperate proposals. Of course it is also possible to file a bug if you want to track this specific point. (I sort of thought I had already filed a bug here but I can't find it now so maybe I imagined it). (aside: your mail client seems to be mangling quotes in plaintext mail. This makes your replies very hard to follow).
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, Jun 19, 2012 at 2:16 PM, James Graham jgra...@opera.com wrote: The way the process here works is that Hixie reads these emails agrees that the change is a good idea (hopefully; in this case it seems likely since we seem to have three implementors in agreement) and it happens. There isn't any need for seperate proposals. Sounds good. This is my first proposal to the group, so I wasn't familiar. Just didn't want to get too sidetracked from the main feature, since I imagine there could be other opinions about narrowing the scope of window names. Of course it is also possible to file a bug if you want to track this specific point. (I sort of thought I had already filed a bug here but I can't find it now so maybe I imagined it). (aside: your mail client seems to be mangling quotes in plaintext mail. This makes your replies very hard to follow). Sorry about that. It seems to have come out ok in the web archive (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-June/036442.html), but I'm trying Gmail's Plain Text mode here to see if that helps. Charlie
[whatwg] make video always focusable and interactive content
Hi all, I recently experimented with keyboard accessibility of media elements. I found that browsers don't provide a default tabfocus on media elements nor do they provide keyboard interactivity. I had to put explicit @tabindex attributes onto the media elements to allow them to at least receive focus. This is particularly irritating in a screenreader. As the video is specified right now, it is not a tabfocusable element [1] and only interactive [2] when it has controls. This is sufficient for audio elements, which have no visual representation without controls, but isn't right for video, which always renders at least a poster (or a black area). Also, if there are controls specified, they should actually be tabfocusable. Even video without controls should allow keyboard focus and should provide for default keyboard interaction: at minimum it should allow for ENTER and/or SPACE to toggle play/pause - and clicking on it should work, too. Potentially it should have up/down arrows to change the volume and left/right arrows to seek back/forward by e.g. 10sec. As it's currently specified, browser cannot provide such interaction when there are no controls, since the element is not generally specified as an interactive element [2]. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focusable [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#interactive-content-0 There is also a bug in the W3C wiki for this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17463 Cheers, Silvia.
Re: [whatwg] make video always focusable and interactive content
IE has lead the way. Thanks for your contributions to the Chrome/WebKit process. I've setup a webapps-UI CG at the W3C to help track these efforts. I suspect we'll see more traffic from authors as web components grow out of their development/experimental status in WebKit. On Jun 19, 2012, at 8:43 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi all, I recently experimented with keyboard accessibility of media elements. I found that browsers don't provide a default tabfocus on media elements nor do they provide keyboard interactivity. I had to put explicit @tabindex attributes onto the media elements to allow them to at least receive focus. This is particularly irritating in a screenreader. As the video is specified right now, it is not a tabfocusable element [1] and only interactive [2] when it has controls. This is sufficient for audio elements, which have no visual representation without controls, but isn't right for video, which always renders at least a poster (or a black area). Also, if there are controls specified, they should actually be tabfocusable. Even video without controls should allow keyboard focus and should provide for default keyboard interaction: at minimum it should allow for ENTER and/or SPACE to toggle play/pause - and clicking on it should work, too. Potentially it should have up/down arrows to change the volume and left/right arrows to seek back/forward by e.g. 10sec. As it's currently specified, browser cannot provide such interaction when there are no controls, since the element is not generally specified as an interactive element [2]. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focusable [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#interactive-content-0 There is also a bug in the W3C wiki for this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17463 Cheers, Silvia.
Re: [whatwg] make video always focusable and interactive content
On Wed, 20 Jun 2012 05:43:20 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi all, I recently experimented with keyboard accessibility of media elements. I found that browsers don't provide a default tabfocus on media elements nor do they provide keyboard interactivity. I had to put explicit @tabindex attributes onto the media elements to allow them to at least receive focus. This is particularly irritating in a screenreader. As the video is specified right now, it is not a tabfocusable element [1] and only interactive [2] when it has controls. This is sufficient for audio elements, which have no visual representation without controls, but isn't right for video, which always renders at least a poster (or a black area). Also, if there are controls specified, they should actually be tabfocusable. They are in Opera. The spec allows it. Even video without controls should allow keyboard focus and should provide for default keyboard interaction: at minimum it should allow for ENTER and/or SPACE to toggle play/pause - and clicking on it should work, too. Why? Video without controls is expected to have author-provided controls. Trying to squeeze in hard-to-discover invisible browser-provided controls in that case would likely just confuse users and make authors curse browsers and try to preventDefault() and tabindex=-1 their video elements (or switch back to Flash) so that their own controls is what their users interact with. Potentially it should have up/down arrows to change the volume and left/right arrows to seek back/forward by e.g. 10sec. As it's currently specified, browser cannot provide such interaction when there are no controls, since the element is not generally specified as an interactive element [2]. It can, actually. interactive content is just a category for the purpose of the content model, it doesn't have implications like the above. (For instance, if you have a video without controls attribute, and the user enables the controls from the context menu, the element still isn't interactive content but it shows controls.) [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focusable [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#interactive-content-0 There is also a bug in the W3C wiki for this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17463 Cheers, Silvia. -- Simon Pieters Opera Software
Re: [whatwg] make video always focusable and interactive content
On Wed, Jun 20, 2012 at 2:51 PM, Simon Pieters sim...@opera.com wrote: On Wed, 20 Jun 2012 05:43:20 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi all, I recently experimented with keyboard accessibility of media elements. I found that browsers don't provide a default tabfocus on media elements nor do they provide keyboard interactivity. I had to put explicit @tabindex attributes onto the media elements to allow them to at least receive focus. This is particularly irritating in a screenreader. As the video is specified right now, it is not a tabfocusable element [1] and only interactive [2] when it has controls. This is sufficient for audio elements, which have no visual representation without controls, but isn't right for video, which always renders at least a poster (or a black area). Also, if there are controls specified, they should actually be tabfocusable. They are in Opera. The spec allows it. Yes, thankfully one browser has video keyboard interaction. Video is not listed in the tabfocusable list, though. How does the spec allow/encourage that? Even video without controls should allow keyboard focus and should provide for default keyboard interaction: at minimum it should allow for ENTER and/or SPACE to toggle play/pause - and clicking on it should work, too. Why? Video without controls is expected to have author-provided controls. Trying to squeeze in hard-to-discover invisible browser-provided controls in that case would likely just confuse users and make authors curse browsers and try to preventDefault() and tabindex=-1 their video elements (or switch back to Flash) so that their own controls is what their users interact with. Hmm... I guess so. The problem that I have is that it's not guaranteed that there are accessible controls when there is no @controls attribute. That means that screen readers don't even see the image, nor would they provide access to the context menu, through which play is usually possible. But maybe that's a bug on the screenreaders rather than the spec - they should always have video as an interactive element. Potentially it should have up/down arrows to change the volume and left/right arrows to seek back/forward by e.g. 10sec. As it's currently specified, browser cannot provide such interaction when there are no controls, since the element is not generally specified as an interactive element [2]. It can, actually. interactive content is just a category for the purpose of the content model, it doesn't have implications like the above. (For instance, if you have a video without controls attribute, and the user enables the controls from the context menu, the element still isn't interactive content but it shows controls.) That's a browser-specific hack, though, and not quite in the spirit of the spec, isn't it? Maybe the answer is in general: it's an implementation issue. However, the spec doesn't really encourage such implementations/interpretations. The spec should then say something like: if there is a screenreader running or a context menu available that provide for controls, then the elements are also regarded as interactive content. Thanks, Silvia.
