W3C home > Mailing lists > Public > public-html@w3.org > August 2012

Re: CfC: Close ISSUE-131: caret-location-api by Amicable Resolution

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 22 Aug 2012 09:30:00 -0700
Message-ID: <50350908.6030105@jumis.com>
To: Sam Ruby <rubys@intertwingly.net>
CC: Richard Schwerdtfeger <schwer@us.ibm.com>, "public-html@w3.org WG" <public-html@w3.org>, Frank Olivier <Frank.Olivier@microsoft.com>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
On 8/22/2012 6:07 AM, Sam Ruby wrote:
> On 08/02/2012 12:59 PM, Richard Schwerdtfeger wrote:
>>
>> */For these reasons I would ask that the chairs move issue 131 to
>> HTML.next and save proposal
>> /*http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelectionRevised*/ 
>> for
>> review at that time. This will give more time for canvas,
>> contenteditable, web-based IME support, and cross-cutting accessibility
>> support to develop and mature. If the chairs agree to then I would
>> support the chairs decision for HTML5 as a temporary one requiring
>> greater view in the next version, otherwise I will need to formally
>> object to the chairs decision.
>
> We previously vacated the original issue 131 decision, reopened the 
> issue, and allowed changes to be made:
>
> http://lists.w3.org/Archives/Public/public-html/2011Dec/0059.html
>
> Now Richard is asking that we effectively consider his proposal 
> withdrawn for the HTML5 time frame.  Frank has also agreed to postpone 
> this to HTML.next:
>
> http://www.w3.org/2012/08/16-html-wg-minutes.html#item09
>
> Given that no active proposals remain, the chairs are now asking if 
> there is consensus to roll back the hit testing proposal and to defer 
> the feature to HTML.next.  If anybody would like to raise an objection 
> during this time, we will require them to accompany their objection 
> with a concrete and complete change proposal.

For those following the caret-location-api thread: there are two 
positive developments in this area.

First, there is a reasonable low level IME API:
http://www.w3.org/TR/ime-api/

Second, the basic "scrollPathIntoView()" method of the Canvas 2D API 
allows UAs to treat the current path as a caret and/or selection area.
http://www.w3.org/TR/2dcontext/#dom-context-2d-scrollpathintoview

The critical issue in implementations, currently, is that Range objects 
do not seem to work within the Canvas sub-tree. This may have already 
been addressed in some implementations.
By using Range and scrollPathIntoView it seems that authors can define 
caret location both semantically and spatially. Further, the IME API 
with appropriate baseline information and focus allows for high quality 
IME construction.

It's been several years since this issue was brought up, and many 
lengthy threads about the validity of use cases.

I'm glad to report that the feature-set has made it into W3C specifications.

-Charles
Received on Wednesday, 22 August 2012 16:30:31 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:26 UTC