Re: [whatwg] Simplified picture element draft
On Mon, Jan 6, 2014 at 6:47 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/6/14 12:42 PM, Yoav Weiss wrote: I don't know much about Gecko's implementation of the preloader, so I could be wrong, but from looking at nsHtml5TreeOpExecutor, it seems like in Gecko (similarly to current Blink) the preloader's products are sent to the main thread before the actual resource loading takes place. That's correct. But the main thread may _also_ not be in a position to evaluate, or even parse, a media query that early in the load process in Gecko Hmm. I'd love to get some more details regarding that. I'll start a mozilla.dev.platform thread on the subject, since it's Gecko specific.
Re: [whatwg] Simplified picture element draft
On 1/7/14 12:01 PM, Yoav Weiss wrote: I'd love to get some more details regarding that. I'll start a mozilla.dev.platform thread on the subject, since it's Gecko specific. It's actually not entirely Gecko-specific. Consider a display:none iframe. How should viewport-size-related media queries be evaluated in such a thing? The specs don't define it, as far as I can tell. In fact, the specs don't actually define anything useful for the viewport of a framed document at all, as far as I can see. CSS just assumes a viewport exists, and HTML doesn't define anything about frames setting up a viewport for the document inside them... But say they defined it. How would the viewport of a display:none iframe be defined, exactly? Last I checked, UAs just end up doing wildly different things in this situation. -Boris
Re: [whatwg] Simplified picture element draft
On Tue, 7 Jan 2014, Boris Zbarsky wrote: On 1/7/14 12:01 PM, Yoav Weiss wrote: I'd love to get some more details regarding that. I'll start a mozilla.dev.platform thread on the subject, since it's Gecko specific. It's actually not entirely Gecko-specific. Consider a display:none iframe. How should viewport-size-related media queries be evaluated in such a thing? The specs don't define it, as far as I can tell. In fact, the specs don't actually define anything useful for the viewport of a framed document at all, as far as I can see. CSS just assumes a viewport exists, and HTML doesn't define anything about frames setting up a viewport for the document inside them... But say they defined it. How would the viewport of a display:none iframe be defined, exactly? Last I checked, UAs just end up doing wildly different things in this situation. IMHO this should probably be in the CSS spec, but I'm happy to spec something if CSS doesn't want to pick this up. It's probably just a matter of saying, in the rendering section, that nested browsing contexts that aren't _being_rendered_ (or that are frames outside framesets) get a 0x0 viewport. (Viewports that are being rendered seem to have an unambiguous dimension, but let me know if I'm missing something here too.) Right now, Chrome and Firefox seem to report 0 as the body.offsetWidth for a hidden iframe. (Couldn't get a result for Safari; don't have IE here.) http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2725 For Chrome (since it puts data: in the wrong origin) http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2726 For Firefox (since for some reason the message in 2725 isn't sent?) Can you elaborate on the widly different things? What should I be testing? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Simplified picture element draft
On 1/7/14 2:24 PM, Ian Hickson wrote:
It's probably just a matter of saying, in the rendering section, that nested
browsing contexts that
aren't _being_rendered_ (or that are frames outside framesets) get a
0x0 viewport.
That doesn't seem unreasonable.
(Viewports that are being rendered seem to have an
unambiguous dimension
Actually, nothing defines this either. It should be the content box of
the iframe, assuming iframes can't get fragmented. If they can be
fragmented, I have no idea.
Right now, Chrome and Firefox seem to report 0 as the body.offsetWidth for
a hidden iframe. (Couldn't get a result for Safari; don't have IE here.)
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2725
For Chrome (since it puts data: in the wrong origin)
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2726
For Firefox (since for some reason the message in 2725 isn't sent?)
Can you elaborate on the widly different things? What should I be testing?
How about this testcase:
!DOCTYPE html
style
div { color: purple; }
/style
link rel=stylesheet href=data:text/css,%23one { color: yellow; }
media=(min-width: 300px)
link rel=stylesheet href=data:text/css,%23two { color: yellow; }
media=(max-width: 300px)
div id=one/div
div id=two/div
script
window.onload = function() {
alert(getComputedStyle(document.getElementById(one), ).color +
| +
getComputedStyle(document.getElementById(two), ).color);
}
/script
and variants on it. From my testing, in a display:none iframe:
1) Presto-based Opera treats the viewport width as 300px for purposes
of the media queries and reports a document.body.offsetWidth of 0.
2) Blink and WebKit both seems to treat the viewport width as 0 when
measured using either method.
3) Gecko doesn't allow creation of computed style objects in an iframe
that's not being rendered and reports a document.body.offsetWidth of 0.
4) IE11 seems to do what Blink/WebKit do.
-Boris
Re: [whatwg] Simplified picture element draft
On 1/7/14 3:06 PM, Boris Zbarsky wrote:
4) IE11 seems to do what Blink/WebKit do.
To test this, you'll need a testcase more like:
style
div { color: purple; }
@media (min-width: 300px) { #one { color: yellow; } }
@media (max-width: 300px) { #two { color: yellow; } }
/style
-Boris
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Wed, 16 Oct 2013, Dominic Mazzoni wrote: On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson i...@hixie.ch wrote: WCAG 2.0 claims that many platforms allow the user to customize the rendering of this focus indicator, though I admit that I don't see any references for this claim: http://www.w3.org/TR/WCAG-TECHS/G165.html IBM similarly claims users may customize the default indicator in Windows to a brighter color: http://www-03.ibm.com/able/guidelines/web/webfocusvisible_aa.html#tech3 I haven't been able to support those claims. However, Win32 in particular has some APIs for changing focus rings (see below for references). If the user changes the focus ring's color and/or width, then drawSystemFocusRing should draw using that style. Right. As far as I can tell, it's not generally the precise colour that a user picks. It's the dimension, and the rendering mode (high contrast vs normal). The issue is when the application wants to draw its own focus ring - should the system sometimes override that and draw its own focus ring instead? That's the argument I don't buy. If the user needs a big ring, it seems bad for us not to render one. Especially since we can know this. Respecting the system focus ring color but ignoring the rest of the system palette makes no sense. A single solid-colour focus ring does have that problem, yes. This is the case even without canvas; if you change your page colour scheme and don't override the focus outline colours, and the operating system's default focus rings are solid colour, then you can have this problem. The solution is for the focus rings not to be a solid colour. Mac OS, for example, makes them a gradient. Some vesions of Windows draw the focus ring using xor (I haven't checked modern Windows behaviour). Mouse cursors are commonly drawn using two levels of outlines to avoid the equivalent problem with mouse cursors. A high contrast focus ring should be visible regardless of the background. I am totally in favor of trying to provide a better experience for users who want a high-contrast theme and custom focus rings - I just don't think this API is the way to achieve that goal, and I think it would actually make things worse if user agents implemented it as specified. I don't understand why it would make things worse, but I'm certainly open to better suggestions. What's a better way to get authors who don't care about accessibility to honour high-contrast focus ring preferences? Perhaps this shouldn't even be solved as part of canvas. Maybe we should add web apis to indicate that the user prefers a custom color scheme that could be used for rendering the whole page, not just canvas. Most authors will just ignore this. That's why we have user style sheets that can override author sheets, for example. The name isn't ideal, it's true. I don't know what a better name should be, though. It's really let me know if I should draw a focus ring, and if I should, then take the opportunity to also notify the accessibility tools, which doesn't make for a very pithy method name. What would you call it if it never draws, but just notifies the UI? At that point, it would just be the addHitRegion() API, with a check for whether the control is focused. Not much point having that as a single rolled-up API, IMHO. It's canvas-specific because in the non-canvas state, the browser already does this, in theory. The focus in the non-canvas case is drawn by the browser using the :focus rules, which, in principle, are set to the user's preferred state. In practice this doesn't necessarily work for the same reason I gave above: the system focus ring might look terrible in particular UIs. The point isn't for it to be aesthetically pleasing, the point is for it to be more obviously visible to the user. If we added a canvas fallback element as a parameter to scrollPathIntoView, I don't think we'd need drawCustomFocusRing. I don't understand how this would work. Suppose you have a control that is floating around the screen. You need the keyboard-focus-driven magnification to follow this control while it's focused. You don't want to scroll to that control every time it moves, you only want to scroll to it when it's focused. So what you do is when it's focused, you scrollPathIntoView(), and then every 16 milliseconds you move the control and redraw its focus ring, by calling drawCustomFocusRing() (or drawSystemFocusRing() if you don't care exactly what it looks like), and that updates the AT. Wait, so what's wrong with calling scrollPathIntoView on it every 16 milliseconds, only when it's focused? It would prevent the user from scrolling the page, which seems like a pretty serious problem. drawCustomFocusRing() and drawSystemFocusRing() shouldn't cause anything to scroll. That would be very confusing, IMHO. (When would you
Re: [whatwg] Simplified picture element draft
On Tue, Jan 7, 2014 at 6:20 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/7/14 12:01 PM, Yoav Weiss wrote: I'd love to get some more details regarding that. I'll start a mozilla.dev.platform thread on the subject, since it's Gecko specific. It's actually not entirely Gecko-specific. Consider a display:none iframe. How should viewport-size-related media queries be evaluated in such a thing? The specs don't define it, as far as I can tell. In fact, the specs don't actually define anything useful for the viewport of a framed document at all, as far as I can see. CSS just assumes a viewport exists, and HTML doesn't define anything about frames setting up a viewport for the document inside them... But say they defined it. How would the viewport of a display:none iframe be defined, exactly? Last I checked, UAs just end up doing wildly different things in this situation. I agree that iframes complicate things, since the parent document's external CSS can modify their viewport dimensions, so there's an inherent race condition there. But this is an issue that applies to any solution that relies on viewport dimensions for resource loading. Since this case is not the majority case, we could bail out of it by delaying the iframe's subresource loading that rely on viewport dimensions until the parent's layout is considered done (e.g. all its head CSS was parsed and applied)
Re: [whatwg] Simplified picture element draft
On 1/7/14 4:28 PM, Yoav Weiss wrote: Since this case is not the majority case, we could bail out of it by delaying the iframe's subresource loading that rely on viewport dimensions until the parent's layout is considered done That seems fairly undesirable, actually, though limiting it only to the things that have media queries might be better... (e.g. all its head CSS was parsed and applied) And all its HTML parsed (including whatever onload scripts it runs) and layout on that completed, right? This seems like it serializes things a lot... But also some of the same constraints apply to the toplevel viewport, not just subframes (e.g. its dimensions can change based on what the browser UI does, etc). At some point you just accept that the dimensions you have are what you have, even if they might change in the future. -Boris
Re: [whatwg] Simplified picture element draft
On Tue, Jan 7, 2014 at 1:53 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/7/14 4:28 PM, Yoav Weiss wrote: Since this case is not the majority case, we could bail out of it by delaying the iframe's subresource loading that rely on viewport dimensions until the parent's layout is considered done That seems fairly undesirable, actually, though limiting it only to the things that have media queries might be better... Yoav said [resources] that rely on viewport dimensions, so yes, it would only be MQs that query viewport size (or sizes='' attribute that use vw/vh units). (e.g. all its head CSS was parsed and applied) And all its HTML parsed (including whatever onload scripts it runs) and layout on that completed, right? This seems like it serializes things a lot... Only to the extent necessary. If you're relying on viewport information, you gotta wait for your viewport to get sized. There's no way around that, except not relying on viewport information. The most common use-cases of picture don't use viewport info, and so are friendly to this stuff. But also some of the same constraints apply to the toplevel viewport, not just subframes (e.g. its dimensions can change based on what the browser UI does, etc). At some point you just accept that the dimensions you have are what you have, even if they might change in the future. Indeed, and that's also fine. Small changes in viewport size from browser UI should only rarely have an impact on which resource is downloaded, anyway. (And adding a bit of hysteresis would solve those, too.) ~TJ
Re: [whatwg] Simplified picture element draft
On Tue, Jan 7, 2014 at 11:13 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Jan 7, 2014 at 1:53 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/7/14 4:28 PM, Yoav Weiss wrote: Since this case is not the majority case, we could bail out of it by delaying the iframe's subresource loading that rely on viewport dimensions until the parent's layout is considered done That seems fairly undesirable, actually, though limiting it only to the things that have media queries might be better... Yoav said [resources] that rely on viewport dimensions, so yes, it would only be MQs that query viewport size (or sizes='' attribute that use vw/vh units). (e.g. all its head CSS was parsed and applied) And all its HTML parsed (including whatever onload scripts it runs) and layout on that completed, right? This seems like it serializes things a lot... Only to the extent necessary. If you're relying on viewport information, you gotta wait for your viewport to get sized. There's no way around that, except not relying on viewport information. The most common use-cases of picture don't use viewport info, and so are friendly to this stuff. One addition - Waiting for the parent document's onload seems a little too careful to me. At least some of the onus can also be on authors embedding the iframe (e.g. authors can declare the iframe's dimensions relatively early in the parent document's CSS, or at least avoid modifying its dimensions later on). But also some of the same constraints apply to the toplevel viewport, not just subframes (e.g. its dimensions can change based on what the browser UI does, etc). At some point you just accept that the dimensions you have are what you have, even if they might change in the future. Indeed, and that's also fine. Small changes in viewport size from browser UI should only rarely have an impact on which resource is downloaded, anyway. (And adding a bit of hysteresis would solve those, too.) ~TJ
Re: [whatwg] Simplified picture element draft
On Sat, 04 Jan 2014 06:36:27 -, Adam Barth w...@adambarth.com wrote: In order for the HTMLPreloadScanner to issue preload requests for picture elements, the HTMLPreloadScanner would need to be able to evaluate arbitrary media requests. That's difficult to do without joining the main thread because the media query engine works only on the main thread. Solution I've suggested originally was that when the selection algorithm encounters a media query it cannot evaluate yet, it aborts selection, waits until conditions change and retries selection form the beginning. This means that: * all images that can be selected by the preloader will be selected, and they'll be selected as soon as it is possible, * browser will never load any irrelevant image, * browsers can optimize when and which MQs match without affecting correctness. For example: picture source media=resolution:2dppx src=first source media=max-width:px src=second source media=super-complex-media-query-to-evaluate: on-main-thread-only src=third /picture in an iframe without layout. 1. If you know resolution and the first MQ matches, then load src=first immediately. Done! 2. If you don't know viewport size then wait until any conditions change (i.e. either viewport size becomes known OR resolution changes) and go to step 1. 3. If the second MQ matches then load src=second immediately (might still happen in the preloader). Done! 4. If you can't evaluate complex MQ in the preloader, then wait until control goes back to the main thread and go to step 1. By wait here I mean the selection algorithm is deferred for the given picture only, and nothing else is blocked. Equivalent of it in the current spec would be something like this: Before step 7 in http://picture.responsiveimages.org/#update-source-sets add: 6b. If child has a media attribute, and its value is a valid media query which UA temporarily cannot evaluate then exit this sub-algorithm and /select an image source/ again after a UA-specific delay. temporarily cannot evaluate is completely up to UA. It may mean unknown sizes in iframes, it may mean non-trivial queries in the preloader, etc. UA-specific delay could be waiting for any media query in the picture to change, or it could simply mean ignoring the picture in the preloader and doing evaluation properly on the main thread/when layout is calculated, etc. exit this sub-algorithm will either cause an earlier source that has unambiguously matched to be loaded or empty source set will cause selection algorithm to do nothing. -- regards, Kornel
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch wrote: I don't see that as an argument against caching the last known location of an object too. If you want to store state, that's what addHitRegion() is for. It's the retained mode API for canvas. The draw*FocusRing() methods are direct-mode APIs. There's no expiry logic, there's no API contract that implies that the calls will be made, or made correctly, if the element isn't focused. I believe this is where part of our confusion/disagreements come from. The draw*FocusRing methods are NOT direct-mode APIs for *a11y*. By calling draw*FocusRing on a fallback element, the a11y software will now associate that element (and its aria rules) with the path that was in the canvas' state. This HAS to be stateful because the a11y software queries the browser for the bounds of the fallback element to draw its own focus rectangle. For the blink and firefox implementations (and the webkit patch) informing the user [1] means telling the DOM about the region of the fallback element so the a11y software can query it later. Because of this, there also needs to be a way to disassociate the region from the fallback element (ie by having no current path when you call draw*FocusRing) As a meta-point: when you, as an implementor, disagree with the spec, the right way to approach this is to report the problem, describe the use cases, and so forth. If you want to implement something different, the way to do that is to design a coherent API, and make sure this new API doesn't conflict with the specced API, and then implement that new API. Implementing something that is inspired by, and conflicts with, what the spec proposal suggests, is not going to lead to a coherent platform, because it is is essentially just mixing in multiple people's designs and goals without coming up with a coherent single vision. To clarify, I'm not saying implement what the spec says. I'm just saying, if you don't want to implement what the spec says, please do actually design a coherent complete solution. Otherwise we'll end up with things like a direct-mode API that acts like a retained-mode API but lacks core retained-mode features like expunging expired data. I completely agree. I *think* I'm on the same page as Rich and Dominic but we're all a bit fuzzy on the details/edge cases. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#inform
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, 7 Jan 2014, Rik Cabanier wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch wrote: I don't see that as an argument against caching the last known location of an object too. If you want to store state, that's what addHitRegion() is for. It's the retained mode API for canvas. The draw*FocusRing() methods are direct-mode APIs. There's no expiry logic, there's no API contract that implies that the calls will be made, or made correctly, if the element isn't focused. I believe this is where part of our confusion/disagreements come from. The draw*FocusRing methods are NOT direct-mode APIs for *a11y*. Right. They're not really APIs for accessibility at all. They're about drawing focus rings. By calling draw*FocusRing on a fallback element, the a11y software will now associate that element (and its aria rules) with the path that was in the canvas' state. This is non-conforming behaviour that is incompatible with the API design. Doing this will cause harm, because the API is incapable, as designed, of being used in this manner correctly without causing bugs. For example, if, when an element is not focused, it's split into four parts, there's no way to draw a single focus ring around it. Thus the data about that control's position _will be incorrect_ if the UA relies on this method for this data. This is why addHitRegion() exists; it provides this data in a usable manner. This HAS to be stateful because the a11y software queries the browser for the bounds of the fallback element to draw its own focus rectangle. The paths provided by the draw*FocusRing() methods aren't useful for this purpose. Using them for this purpose is bogus. The paths provided to those methods are only useful for direct-mode painting and direct-mode notification to an AT API if such an API accepts direct-mode notifications. If it doesn't, then the addHitRegion() API is what should be used to send the notifications. For the blink and firefox implementations (and the webkit patch) informing the user [1] means telling the DOM about the region of the fallback element so the a11y software can query it later. That's not conformant, and will lead to accessibility problems. Informing the user is an imperative action, not an indirect action involving caching state over multiple frames. Because of this, there also needs to be a way to disassociate the region from the fallback element (ie by having no current path when you call draw*FocusRing) Yes, if draw*FocusRing() were the API you describe, we would need such a thing. The API you describe, however, is not draw*FocusRing(), it's addHitRegion(), and it already has such a thing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch wrote: If the user needs a big ring, it seems bad for us not to render one. Especially since we can know this. Yes, there are users who need extra high-contrast focus rings. But no, they don't get that from an operating system setting that the app queries, I think that's the source of the confusion. Try checking the Make the focus rectangle thicker checkbox in Windows. Any time where a single-pixel dotted outline was shown before, you'll now see a 2-pixel dotted outline. However, in every application I tried, when previously you saw a custom focus highlight (which is the majority of the time - the dotted outline looks very dated), there's no change - including in Windows explorer, Office, IE, Firefox, etc. - I just don't see any precedent for applications that already provide custom focus highlighting to do something different when the Make the focus rectangle thicker option is checked. A number of third-party accessibility tools for Windows draw their own highlight around the current focused object for users who need it. They usually draw it in a transparent floating window above the current app - so it doesn't matter what the app does. If you want to give the AT position information when there's no visible focus ring, that's what addHitRegion() is for. For the record, I like addHitRegion and I'd like to go forward with implementing it too. Do you consider it ready for implementation? Have any other browsers expressed interest? The impression I got a while back was that there were still concerns from some people. We should probably start a new thread on addHitRegion if there's anything to discuss, and keep this one focused on drawSystemFocusRing, since that's the one that it appears three browsers have implemented now. (I'm assuming IE is implementing it, given that Microsoft has publicly commented on the spec.) As a meta-point: when you, as an implementor, disagree with the spec, the right way to approach this is to report the problem, describe the use cases, and so forth. If you want to implement something different, the way to do that is to design a coherent API, and make sure this new API doesn't conflict with the specced API, and then implement that new API. Implementing something that is inspired by, and conflicts with, what the spec proposal suggests, is not going to lead to a coherent platform, because it is is essentially just mixing in multiple people's designs and goals without coming up with a coherent single vision. To clarify, I'm not saying implement what the spec says. I'm just saying, if you don't want to implement what the spec says, please do actually design a coherent complete solution. Otherwise we'll end up with things like a direct-mode API that acts like a retained-mode API but lacks core retained-mode features like expunging expired data. It wasn't my intent to implement something different than the spec. The spec only talks about the accessibility part of the implementation in a Note explaining the meaning of Inform the user, which I didn't think was normative. I took the language in that note as a guide but ultimately tried to implement something that actually works. I made a simple demo app to demonstrate the use of this API, and tested it with three screen magnifiers while developing it. If we can come up with another implementation strategy that's more in line with you intended that actually works, that's great, I'm happy to change the implementation, it's not too late. Alternatively, I'd be happy to help draft normative language that more precisely spells out how it needs to be implemented in order to work in practice.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, Jan 7, 2014 at 9:45 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 7 Jan 2014, Rik Cabanier wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch wrote: I don't see that as an argument against caching the last known location of an object too. If you want to store state, that's what addHitRegion() is for. It's the retained mode API for canvas. The draw*FocusRing() methods are direct-mode APIs. There's no expiry logic, there's no API contract that implies that the calls will be made, or made correctly, if the element isn't focused. I believe this is where part of our confusion/disagreements come from. The draw*FocusRing methods are NOT direct-mode APIs for *a11y*. Right. They're not really APIs for accessibility at all. They're about drawing focus rings. No. The only reason for this API is accessibility. An author could just check the focused state and draw the ring himself; there's no need for an API to do this. By calling draw*FocusRing on a fallback element, the a11y software will now associate that element (and its aria rules) with the path that was in the canvas' state. This is non-conforming behaviour that is incompatible with the API design. Doing this will cause harm, because the API is incapable, as designed, of being used in this manner correctly without causing bugs. For example, if, when an element is not focused, it's split into four parts, there's no way to draw a single focus ring around it. Thus the data about that control's position _will be incorrect_ if the UA relies on this method for this data. I don't understand. The path for the focus ring can be anything, including multiple closed paths. The data for the a11y software won't be wrong, it will be the boundingbox of those paths. This is why addHitRegion() exists; it provides this data in a usable manner. This HAS to be stateful because the a11y software queries the browser for the bounds of the fallback element to draw its own focus rectangle. The paths provided by the draw*FocusRing() methods aren't useful for this purpose. Using them for this purpose is bogus. The paths provided to those methods are only useful for direct-mode painting and direct-mode notification to an AT API if such an API accepts direct-mode notifications. If it doesn't, then the addHitRegion() API is what should be used to send the notifications. No, the AT API is not direct mode. For the blink and firefox implementations (and the webkit patch) informing the user [1] means telling the DOM about the region of the fallback element so the a11y software can query it later. That's not conformant, and will lead to accessibility problems. Informing the user is an imperative action, not an indirect action involving caching state over multiple frames. If that is the case, we should drop focus ring support. There's no point to just draw rings. Because of this, there also needs to be a way to disassociate the region from the fallback element (ie by having no current path when you call draw*FocusRing) Yes, if draw*FocusRing() were the API you describe, we would need such a thing. The API you describe, however, is not draw*FocusRing(), it's addHitRegion(), and it already has such a thing. addHitRegion is a much bigger implementation burden for authors and browser vendors. My fear is that given their complexity, authors will not provide a11y support.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, Jan 7, 2014 at 9:18 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch wrote: I don't see that as an argument against caching the last known location of an object too. If you want to store state, that's what addHitRegion() is for. It's the retained mode API for canvas. The draw*FocusRing() methods are direct-mode APIs. There's no expiry logic, there's no API contract that implies that the calls will be made, or made correctly, if the element isn't focused. I believe this is where part of our confusion/disagreements come from. The draw*FocusRing methods are NOT direct-mode APIs for *a11y*. By calling draw*FocusRing on a fallback element, the a11y software will now associate that element (and its aria rules) with the path that was in the canvas' state. This HAS to be stateful because the a11y software queries the browser for the bounds of the fallback element to draw its own focus rectangle. Yes. A11y APIs on every platform I'm familiar with (Windows, Mac, Linux/ATK, Android, iOS) are essentially retained-mode. When focus changes, the application notifies the system and gives it an ID or reference that identifies the focused object. Assistive technology may query the bounds of this object immediately, or at any time in the future. If you restart or load a magnifier while the browser is already running, it will explore the tree, discover the object that has focus, and zoom the screen and/or draw its own ring around it at that time.
