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

Re: Bug 11239

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Thu, 28 Apr 2011 23:46:41 +0100
Message-ID: <BANLkTi=3h_is3739LG=FxXwy8MWsRa1cYA@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Jonas Sicking <jonas@sicking.cc>, public-html@w3.org
On Thu, Apr 28, 2011 at 11:10 PM, Ian Hickson <ian@hixie.ch> wrote:
>> I can /imagine/ a concrete scenario. Does that count?
>>
>> What if a visual-rendering UA delegated drawing of widgets (e.g.
>> textareas) to the system and the system did not provide information
>> about caret blink rate back? Then the author would want to draw a
>> caret, but the UA would be unable to provide the correct blink rate
>> to use.
>
> What platform is like this?

Not claiming any are.

>From the perspective of developers like Charles Pritchard the browser
itself is a platform like this: hostile to developers trying to create
their own complex controls, unwilling to surface blink rates, and yet
exposing a direct draw API. So it's not an unfeasible thing for a
platform to do.

I guess Apple iOS may be the closest among major operating systems to
adopting something like this philosophy of nativism:

http://www.apple.com/hotnews/thoughts-on-flash/

But I suspect you can still access NSTextInsertionPointBlinkPeriod or
something (can't test this).

There's also the simpler case where a platform simply fails to surface a
blink rate. Android has carets, but can you access the blink rate? Can't
find anything about it on the developer site.

--
Benjamin Hawkes-Lewis
Received on Thursday, 28 April 2011 22:47:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:24 UTC