Re: Solution to grammar, spelling, and

On Thu, Jan 20, 2011 at 3:01 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
> aria-selected makes no claims as to who selected something.

So what use is it for text selection?

> However, I think all of us would be just has happy to have <selection> and
> <caret> elements in HTML vs.  <mark aria-selected="true">... </mark>
>
> We were just trying to minimize the impact to the spec by adding yet another
> set of elements to a spec that is already loaded with them.

Can you elaborate?

Against what measure is HTML "loaded" with elements?

The general goal of keeping things simple for authors and implementors is good.

But how does adding these new semantics in the form of attributes not elements,
forcing authors to seek semantics scattered randomly across multiple
specifications, and overloading an existing attribute with two new meanings
does not make things simpler.

> Browsers are already implementing aria-invalid="grammar" and
> aria-invalid="spelling".

I'm talking about the proposed selection markup, not the already existing
markup for proofing errors.

In passing, I'll note nobody has answered the implementation questions posed by
Maciej:

http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0003.html

> Also, a collapsed <mark> is not much different than an a collapsed selection
> in the script apis.

I think they are very different.

The caret and the selection are not distinct Selection instances in the DOM
APIs. Expanded selections have anchors and focuses that aren't represented in
the markup proposal on the table.

>> >> The only utility proposed for this markup so far is serialization.
>> >
>> > It may be a little easier than using DOM Ranges, from a programmers
>> > perspective, but that's debatable.
>>
>> Before you debate it, can you explain how the proposed feature even avoids
>> developers having to use DOM ranges? If aria-selection were not magically
>> synced with manual or programmatic selection by the browser altering the DOM
>> (because doing so would seem to break the ARIA conformance rule: "WAI-ARIA
>> processing by the user agent MUST NOT interfere with the normal operation of
>> the built-in features of the host language"), then developers will need to
>> use DOM ranges in order to determine where to place the "mark" elements. In
>> which case, "mark" is multiplying interface rather than adding
>> functionality.
>>
>> DOM ranges are how developers deal with carets and selection today.
>>
>> Methods on nodes interacting with ranges, rather than distinct nodes in the
>> accessibility tree, are how system accessibility APIs like Microsoft UI
>> Automation, the Apple Accessibility API, and AT-SPI deal with carets and
>> selection today.
>>
>> So I think the onus is on you to prove that moving away from this common
>> model would be workable and beneficial.
>>
> Our problem with this approach is that HTML WG members refused to expand the
> APIs on contenteditable sections for spelling and grammar because they were
> concerned about security and privacy issues related to contenteditable. We
> are offering an alternative.

Why are you responding to my concerns about the proposed introduction of
selection markup by talking about spelling and grammar features? The
security concerns you mention related to exposing incorrect spelling and
grammar errors detected by system services to authors. Those concerns are
irrelevant to the already existing practice of manipulating selections using
DOM ranges. Charles says this new selection markup should be introduced because
it enables serialization (which it doesn't) and it *might* be easier for
developers than using DOM ranges. Can anyone justify this later claim?

In passing, I'll note that you're mischaracterizing the discussion around
spelling and grammar APIs. There was some discussion involving HTML WG members
in a WHATWG context last month of adding API to expose proofing errors to
author scripts:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-November/029200.html

While security concerns were certainly raised, the discussion ran into the
ground because the features were not demonstrated to meet end-user
requirements.

--
Benjamin Hawkes-Lewis

Received on Sunday, 23 January 2011 15:20:20 UTC