Re: [whatwg] make video always focusable and interactive content
On Wed, 20 Jun 2012 07:47:12 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: 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? This list? http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus I guess it should add media elements that are exposing a user interface and finally have a may for just about anything, since this is UI and browsers should be allowed to make things focusable if they want. It is unusual for the spec to have UI requirements at all. 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. Yeah, it might make sense for screenreaders to provide special access to video elements, to cater for pages that have inaccessible custom controls. They also make h1 focusable even though it isn't normally in browsers. 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? No, it's literally the spec's model. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#expose-a-user-interface-to-the-user is decoupled from the controls attribute. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-video-element says If the element has a controls attribute: Interactive content. Another case is when scripting is disabled, where video (without controls=) is not interactive content but still exposes a user interface to the user. I noticed the spec doesn't say that UAs are allowed to show controls on demand (from the context menu), so I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=17553 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. You can't change the content model of a document based on what the user is running. That doesn't make sense. Content model is about how authors are allowed to nest their elements. It doesn't apply to UAs at all. When the author is writing and validating the document, nobody knows whether the user is going to read the page with a screenreader or not, or have scripting enabled or not. Maybe you actually mean something different from the spec's interactive content term? -- Simon Pieters Opera Software
[whatwg] Web Notifications
Hi, The Web Notifications WG is planning to move Web Notifications to W3C Last Call meaning we don't intend to change it. But we might have missed something and would therefore appreciate your review of http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any comments you might have at public-web-notificat...@w3.org. Cheers, -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Web Notifications
On 20 June 2012 10:58, Anne van Kesteren ann...@annevk.nl wrote: Hi, The Web Notifications WG is planning to move Web Notifications to W3C Last Call meaning we don't intend to change it. But we might have missed something and would therefore appreciate your review of http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any comments you might have at public-web-notificat...@w3.org. My one comment was that it was not immediately obvious what the term 'tag' was meant to mean. It might just me, but tag is kind of an overloaded term on the web these days, I needed to drill down into the examples to get a good sense of it. Cheers, -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
Doesn't this section of the HTML spec already allow for what Scott wants: http://www.whatwg.org/specs/web-apps/current-work/#the-link-element For external resources that are represented in the DOM (for example, style sheets), the DOM representation must be made available even if the resource is not applied. To obtain the resource, the user agent must run the following steps: If the href attribute's value is the empty string, then abort these steps. Resolve the URL given by the href attribute, relative to the element. If the previous step fails, then abort these steps. Fetch the resulting absolute URL. User agents may opt to only try to obtain such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied. Looking at waterfalls for a page loading Android 2.3 and iOS 5, it appears that iOS does defer the non-applicable stylesheets - question is why don't more browsers? iOS 5 - http://www.blaze.io/mobile/result/?testid=120615_J6_927 Android 2.3 - http://www.blaze.io/mobile/result/?testid=120615_2D_929 Cheers Andy
Re: [whatwg] Undo Manager specs is confusing in the contenteditable section
Hi, *2.2.1 Undo scope and contenteditable* * * *When the contenteditable content attribute is added to an element, the user agent must remove all entries in the undo transaction histories of the editable undo scope hosts that are descendent of the element and have become editable without unapplying or reapplying the entries and disconnect the corresponding UndoManagers as if the undoscope content attribute was removed from all descendent nodes excluding undo scope hosts and their descendents.* What does editable undo hosts imply here? From my understanding they are the elements that were undo hosts but now, because the addition of contenteditable content attribute, became editable elements, so not undo hosts anymore. Also when contenteditable is added to an element all the descendant elements become editable, so none of the descendants should be a undo scope host as undoscope content attribute on an editable element is ignored. So is *excluding undo scope hosts and their descendents* valid? We can have non-editable elements that are descendents of an element with contenteditable=true. For example: div id=container div id=A undoscopeThis will be editable/div div id=B contenteditable=false undoscopeThis will remain not editable/div /div When div container gets contenteditable=true, the div A will have its undoManager disconnected, but not the div B, because its not editable. Would a non-normative box with an example like this one be helpful in the spec? Maybe we could change the second paragraph of 2.2.1 to make things clearer: 8--- When the contenteditable content attribute is added to an element, the user agent must remove all entries in the undo transaction histories of the descendents of the element that were undo scope hosts but have become editable without unapplying or reapplying the entries and disconnect the corresponding UndoManagers as if the undoscope content attribute was removed from the now editable descendent nodes. ---8--- What do you think? Cheers, -- Caio Marcelo de Oliveira Filho openBossa @ INdT - Instituto Nokia de Tecnologia
Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
On 6/20/12 3:16 PM, Andy Davies wrote: Looking at waterfalls for a page loading Android 2.3 and iOS 5, it appears that iOS does defer the non-applicable stylesheets - question is why don't more browsers? In Gecko's case it's as I said: stylesheet loads are often kicked off before media query information is available... We could probably redesign stylesheet loading to make it happen somewhat later or maybe redesign pageload to get media query information earlier, but it just hasn't happened yet. -Boris
Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
That'd be really great if Moz did head in that direction. Here's a post from one of the Webkit devs on how it works internally for that platform. http://www.igvita.com/2012/06/14/debunking-responsive-css-performance-myths/ On Jun 20, 2012, at 5:02 PM, Boris Zbarsky wrote: On 6/20/12 3:16 PM, Andy Davies wrote: Looking at waterfalls for a page loading Android 2.3 and iOS 5, it appears that iOS does defer the non-applicable stylesheets - question is why don't more browsers? In Gecko's case it's as I said: stylesheet loads are often kicked off before media query information is available... We could probably redesign stylesheet loading to make it happen somewhat later or maybe redesign pageload to get media query information earlier, but it just hasn't happened yet. -Boris
[whatwg] Two small typos in UndoManager spec
Hi, Found in 8/June/2012 version. Section 3.2: the first example box says In the following example, execute and undo attributes are modified: but executeAutomatic and undo are modified in the actual example. Section 3.4: user agnets should be user agents, it appear three times. -- Caio Marcelo de Oliveira Filho openBossa @ INdT - Instituto Nokia de Tecnologia
Re: [whatwg] make video always focusable and interactive content
On Wed, Jun 20, 2012 at 5:47 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: They are in Opera. The spec allows it. Yes, thankfully one browser has video keyboard interaction. I just tested Firefox and the keys work. See Media Shortcuts here: https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly I could tab to the video, a focus ring appears around it, and use the keys in that list. Did that not work when you tried it? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] make video always focusable and interactive content
On Thu, Jun 21, 2012 at 9:09 AM, Chris Double chris.dou...@double.co.nz wrote: On Wed, Jun 20, 2012 at 5:47 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: They are in Opera. The spec allows it. Yes, thankfully one browser has video keyboard interaction. I just tested Firefox and the keys work. See Media Shortcuts here: https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly I could tab to the video, a focus ring appears around it, and use the keys in that list. Did that not work when you tried it? You're right - it works when you use Firefox normally. It was when I used it with VoiceOver on the Mac. But that's indeed a screenreader issue. Sorry for being confusing. Cheers, Silvia.
Re: [whatwg] Undo Manager specs is confusing in the contenteditable section
I just realized I missed adding Ryosuke in my previous mail, CC'ing now. Hi, Thanks for your reply. On Thu, Jun 21, 2012 at 12:51 AM, Caio Marcelo de Oliveira Filho caio.olive...@openbossa.org wrote: Hi, *2.2.1 Undo scope and contenteditable* * * *When the contenteditable content attribute is added to an element, the user agent must remove all entries in the undo transaction histories of the editable undo scope hosts that are descendent of the element and have become editable without unapplying or reapplying the entries and disconnect the corresponding UndoManagers as if the undoscope content attribute was removed from all descendent nodes excluding undo scope hosts and their descendents.* What does editable undo hosts imply here? From my understanding they are the elements that were undo hosts but now, because the addition of contenteditable content attribute, became editable elements, so not undo hosts anymore. Also when contenteditable is added to an element all the descendant elements become editable, so none of the descendants should be a undo scope host as undoscope content attribute on an editable element is ignored. So is *excluding undo scope hosts and their descendents* valid? We can have non-editable elements that are descendents of an element with contenteditable=true. For example: div id=container div id=A undoscopeThis will be editable/div div id=B contenteditable=false undoscopeThis will remain not editable/div /div When div container gets contenteditable=true, the div A will have its undoManager disconnected, but not the div B, because its not editable. Would a non-normative box with an example like this one be helpful in the spec? Surely a example helps lot, may be a single example which covers most of the scenarios might may help. Maybe we could change the second paragraph of 2.2.1 to make things clearer: 8--- When the contenteditable content attribute is added to an element, the user agent must remove all entries in the undo transaction histories of the descendents of the element that were undo scope hosts but have become editable without unapplying or reapplying the entries and disconnect the corresponding UndoManagers as if the undoscope content attribute was removed from the now editable descendent nodes. ---8--- What do you think? Looks good to me. Cheers, -- Caio Marcelo de Oliveira Filho openBossa @ INdT - Instituto Nokia de Tecnologia -- Rakesh
