Re: Solution to grammar, spelling, and

On Fri, Jan 14, 2011 at 8:54 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> Is it? Seems fairly crufty as markup for a selection to me. How do you
>> indicate the selection anchor and direction? How do you indicate
>> multiple ranges?
>
> It may be that "aria-selection" is a better title for it,

Yeah, also the use of an element plus an attribute rather than an
element, the bizarre aria- prefix, the fact that the attribute isn't a
normal HTML boolean attribute, the fact that the same markup is being
used to mean both a selection and a cursor …

If you want "clean", how about native <selection> and <caret> in
HTML mapping to role="selection" and role="caret" in ARIA?

> It's a start of a discussion.

It would be great if these discussions started with clearly stated
use-cases and case studies of existing practice rather than diving
straight into markup proposals. :(

e.g. it would have been useful to consider the Google Spreadsheets example
at the beginning, since the proposed markup doesn't seem to tackle that
example at all.

> Directionality would be inherited by the language / direction attributes.
> You can always insert xml "dir" and "lang" attributes.

That's script direction, not selection direction, which is the direction
(forwards or backwards) in which selection is expanded from the initial anchor.
Compare the ongoing discussion about standardizing the existing
selection API's direction features:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029814.html

> The anchor would be the empty <mark></mark>.

Would:

   The cat sat <mark aria-selected="true">on the mat<mark
aria-selected="true"></mark></mark> and was
<mark aria-selected="true">very happy</mark>.

imply a discontinuous selection with "very happy" selected, followed
by "on the mat", with the cursor just after "mat"?

>>> and in fact puts more control in the hands of cloud-based offerings
>>
>> What additional control does it provide?
>
> A standard method of serializing selected ranges.

What additional control does that provide? What information does it
give to AT that AT *cannot* already get? What functionality does it
provide to authors that authors *cannot* already access?

> Consider Google's spreadsheet offering, where the current cursor
> position of all members is shown on the screen. It's certainly handy,
> but it's not something spec'd anywhere.

Are you talking about indicating the cursor and selection of
contributors other than the user during collaborative editing?

I don't understand how this requires serialization. By "serializing"
do you just mean putting information in the DOM tree or are you talking
about round-tripping in markup?

I think it's a plausible application for the "mark" element, but I
don't see how "aria-selected" fits in at all.  "aria-selected" is
supposed to indicate the user's selection not other users' selections
and I haven't seen anything in the proposal so far to differentiate the
two. It's also unclear to me how other users' cursor operations should
be mapped to system accessibility APIs, and even more importantly
whether simply reporting cursor operations would be useful to the end
user. I suspect that the actual functionality of visually indicating
other contributors' cursor and selection is to highlight areas of the
document subject to change to minimize the chance of conflicts. It's
critical that new features solve actual end-user problems rather than
their shadows. There might be more direct ways to solve those problems
that would provide better usability than the proposed markup.

Even if it is provably useful and practical to report others' cursor and
selection operations, it's not obvious why this is best done by
declaratively by altering the document's structure rather than
programmatically with new DOM APIs. There's not much of a scriptless
use-case here, since cursor and selection operations are too
time-sensitive to be useful to report without JS.

>> 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.

>> New markup seems unnecessary for this use-case since authors can
>> roundtrip arbitrary data in HTML, including selection information.
>
> They can send arbitrary data, certainly, and use microformats.
>
> At present, there isn't one for selection. It seems there ought to be.
> The examples we've been discussing are an attempt at making one.

No. The proposals add to core vocabularies (HTML/ARIA), not metadata
vocabularies.

Nobody's stopping anyone creating a non-core vocabulary that can be
pulled in via HTML's metadata features.

--
Benjamin Hawkes-Lewis

Received on Sunday, 16 January 2011 10:43:19 UTC