W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > April 2011

[Bug 11239] Canvas support accessible caret tracking independent of Focus Ring tracking

From: <bugzilla@jessica.w3.org>
Date: Wed, 27 Apr 2011 02:45:14 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QEukc-0000YJ-1o@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239

--- Comment #24 from Maciej Stachowiak <mjs@apple.com> 2011-04-27 02:45:13 UTC ---
(In reply to comment #23)
> (In reply to comment #22)
> > Blink rates on all OS platforms return a rate in milliseconds. They do not
> > return two values. 
> 
> A time in milliseconds is not a rate. It's an interval. Rates are in Hertz (or
> some other unit with dimension [1/T]). The proposal doesn't say what the return
> value is other than to say it must be a rate and must be in milliseconds, which
> is self-contradictory and leaves the reader wondering what the number means:
> the complete period, a half period, the time the caret is on, the time the
> caret is off, the frequency? It's simply not defined well enough to be
> interoperably implementable.
> 

For what it's worth, the relevant setting on Mac OS X is called
NSTextInsertionPointBlinkPeriod and on Windows it's called CursorBlinkRate.
There are also APIs that call it "CaretBlinkTime". This seems to be informally
referred to as the "caret blink rate" in developer docs, even though logically
that may be a misnomer.

Though no one objected on the basis of interval vs. rate, if you and Rich agree
that the property should be named something with Time, Period or Interval
rather than Rate, then I don't foresee a problem with that.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 27 April 2011 02:45:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:08 UTC