Re: Request to re-open issue 131

Charles Pritchard writes:

> The blink rate getter ... users of screen readers may benefit from the
> functionality.

In order for a user to benefit from a web page author getting the system
blink rate both of the following would need to apply:

  1 The author is aware of the problems that can be caused by fast blink
    rates for some users.

  2 The author wishes to set a particular fast blink rate for users who
    don't have a problem with fast blink rates, and therefore is
    prepared to have code which explicitly checks for this and goes to
    the bother of setting the blink rate differently depending on the
    user.

Note that if only condition 1 above applies then the author can easily
avoid the problem by simply using a slow blink rate for all users, since
that's simpler. It's only if condition 2 applies as well that an API for
getting the system blink rate could possibly be useful.

So evidence that this problem needs solving needs to show that there are
situations in which condition 2 above applies -- that there are web
authors out there who desire particularly fast blink rates on their
pages (except for users for whom this is a problem).

> I know I've had a difficult time with the "use case" system.

In what way? It seems to make sense to me that features are only
designed once it's clear what problems they are solving.

> Anyway... Afaik, Richard was fine with the blink rate returning a
> static 500ms in browsers.

In that case would you, and Richard, be fine with the spec simply having
a definition like this?

  caretBlinkRate() is a function which always returns the value 500.

Cheers

Smylers

Received on Monday, 19 December 2011 10:05:04 UTC