Re: Request to re-open issue 131

On Sun, Dec 18, 2011 at 7:06 PM, Charles Pritchard <chuck@jumis.com> wrote:
> 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?

Well you could provide evidence about its triviality rather than
making assertions.

Even establishing whether a platform has such a getter is part of the
task. Does Android have one? I looked and asked before:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0736.html

Windows has GetCaretBlinkTime:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms648401(v=vs.85).aspx

Apple Cocoa has an undocumented per-application
"NSTextInsertionPointBlinkPeriod" configuration property:

http://hintsforums.macworld.com/archive/index.php/t-63718.html

It's not clear that's there's any way to get at some sort of
system-wide setting.

GTK has some documented configuration settings that can be queried:

http://www.gtk.org/api/2.6/gtk/GtkSettings.html#GtkSettings--gtk-cursor-blink

http://www.gtk.org/api/2.6/gtk/GtkSettings.html#GtkSettings--gtk-cursor-blink-time

QT has a cursorFlashTime property on QApplication:

http://developer.qt.nokia.com/doc/qt-4.8/qapplication.html#id-c2df98d1-409c-4bcd-ac65-b3eb4f2b6c55

Interestingly, Firefox already knows about a caret blink rate in the
form of the undocumented ui.caretBlinkTime setting in about:config:

http://www.jurta.org/en/prog/noblink

If not explicitly set, it either uses a default or queries the
underlying system. If I'm reading the source right:

   * For Windows it uses GetCaretBlinkTime:

http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsLookAndFeel.cpp#340

   * For Apple Cocoa it uses a hardcoded value 567 ms:

http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/nsLookAndFeel.mm#319

   * For GTK it spelunks inside gtk_settings:

http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsLookAndFeel.cpp#417

   * For QT it uses a hardcoded value 500 ms:

http://mxr.mozilla.org/mozilla-central/source/widget/src/qt/nsLookAndFeel.cpp#356

   * For Android it uses a hardcoded value 500 ms:

http://mxr.mozilla.org/mozilla-central/source/widget/src/android/nsLookAndFeel.cpp#386

WebKit's source has a similar concept in the form of
WebCore::RenderTheme::caretBlinkInterval, defaulting to 500 ms:

http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderTheme.h#L160

Only in the case of Windows does it actually query the underlying
platform, again using GetCaretBlinkTime:

http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderThemeChromiumWin.cpp#L225

> 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.

It is not the case that browsers will implement anything that allows
fingerprinting so long as someone can think of a purpose for them.

Cacheing has far-reaching advantages that blink rate exposure does not
(q.v. REST). A browser that did not cache content would be at a
significant market disadvantage to one that did not. This is also true
of a lot of legacy features that can be used to leak information, like
cookies, as Jonas mentioned before:

http://lists.w3.org/Archives/Public/www-archive/2011Apr/0096.html

>> 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.

Is this sentence a response to Aryeh's suggestion?

> 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.

   * I don't think it's safe for authors to display flashing content
higher than that suggested by WCAG, regardless of what caretBlinkRate
reports. (I don't think it's a good idea to cause epileptic fits in
public libraries, Times Square displays, etc.)

   * If in practice, implementors choose to return a static 500ms in
all cases, then authors might as well have just followed WCAG's advice
in the first place.

I'm not clear what caretBlinkRate has to do with "screen reader heuristics".

I believe the original intent was that hand-drawn carets - which are
presumably only needed for text editing - should be drawn with an
appropriate blink rate if the user has set one. I don't see why
Aryeh's suggestion couldn't be made to work for this.

--
Benjamin Hawkes-Lewis

Received on Sunday, 18 December 2011 21:09:17 UTC