Re: Request to re-open issue 131

On Dec 18, 2011, at 10:39 AM, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote:

> On Sun, Dec 18, 2011 at 5:59 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> The HTML5 Editors draft uses scrollPathIntoView to accomplish the same thing as setCaretSelectionRect but with a broader goal and semantic. I've not been able to get its author to speak up on the issue...  They are both intended to fill in the caret tracking interfaces present at the OS level. These are used by zoom apps, but can also be used by heuristics in screen readers.
>> 
>> The HTML5 editor did not use the caretBlinkRate semantic.
> 
> Yes, likely influenced by implementor feedback. For example, Jonas
> Sicking has already indicated his opposition to Gecko implementing
> this:
> 
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0747.html


The two objections difficulty of implementation and fingerprinting are put forward without proportionality. The blink rate getter for platforms that have it is a trivial task. Jonas suggests otherwise. How do we talk about a disagreement like that? I don't mean to rebut, I want to have a constructive conversation.

As for fingerprinting, it's true that a blink rate API may expose that some users maybe running a popular AT screen reader. It's also the case that users of screen readers may benefit from the functionality. There are many many methods if fingerprinting, cache hit detection amongst the best examples. They are tolerated and somewhat reasonable when they exist as part of a purpose. The blink rate settings have a purpose for the minority of users that have adjusted them.


> 
>> If there are any ideas on how to salvage consensus on this maxFlashRate concept, it'd be nice to hear them. This is different than requestAnimationFrame use cases. This max flash rate is intended for on-screen position and progress indicators to help authors stay on the path to WCAG.
> 
> Aryeh Gregor has suggested:
> 
> "It seems like a small enough loss
> for canvas cursors to not respect user blink rate settings, but if
> it's not, could you work out some API that lets authors honor them
> without knowing them?  I.e., let the author say "I want this to blink
> at the user's blink rate setting", without letting them know what it"
> 
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0770.html
> 
> This is more complex to spec, but perhaps more likely to win acceptance.


I know I've had a difficult time with the "use case" system. I'm not the author behind the blink rate proposal. I believe the primary intent of the proposal is for WCAG first, then for AT screen reader heuristics.

http://www.w3.org/WAI/WCAG20/quickref/#seizure


I have no problem meeting that WCAG section without the API... Though I'd not be picking up on the system settings put forward by screen readers. Anyway... Afaik, Richard was fine with the blink rate returning a static 500ms in browsers.

This kind of opaque implementation is in line with Mozilla's stance on pixel ratios with zoomed content. Something they only recently exposed through CSS selectors. Mozilla treats the pixel ratio (think browser zoom) as static in the JS environment whereas MS and WebKit do not. It's a position they have taken and I'm at peace with the doing the same here.

I am not the right person to speak up for the blink rate proposal, but I hope I was able to share some more information about it.

-Charles

Received on Sunday, 18 December 2011 19:06:39 UTC