Working Group Decision on ISSUE-205: caret-location-api

The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic as there were no
additional responses in the poll itself.

*** Question before the Working Group ***

There is a basic disagreement in the group on whether additional 
accessibility functionality for canvas text editing, tracked as ISSUE 
205. We have two distinct proposals for this question, and a straw poll 
for objections.

http://www.w3.org/html/wg/tracker/issues/205
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelectionRevised
http://www.w3.org/wiki/No_edit_change_proposal_for_canvas_text_editing
http://www.w3.org/2002/09/wbs/40318/issue-205-objection-poll/results


== Uncontested parts of the proposals:

The following points were made and not disputed, and in some cases
explicitly stipulated by both proposals:

- There exist some applications which do in-canvas text editing
  (specific examples: Ludicart Drawing Tool, LibreOffice Online)
- In-canvas text editing is lacking in accessibility.
- Combining text editing with canvas is a valid use case (though how
  best to do it is disputed).
- The "CaretSelectionRevised" proposal provides sufficient
  functionality to support accessibility of in-canvas text editing.
- Superimposing text fields on top of the canvas is an existing
  alternative approach to meeting these use cases (though it is
  disputed whether it is complete, or the best approach).
- Superimposing text fields is sufficient for simple use cases, though
  whether it is sufficient for more advanced use cases is disputed.
- In-canvas text editing has many weaknesses and limitations,
  requiring significant reimplementation and making it challenging
  (perhaps in somc cases impossible), to deliver some
  non-accessibility editing capabilities.

They are assumed valid in the analysis below.


== Use cases for in-canvas text editing:

It is not disputed that canvas-based applications which also do text
editing are a valid use case and are actually used in the wild. It is
also accepted that such applications must be made accessible. This
would form a strong objection to any proposal that does not address
these use cases. This is not disputed for the "CaretSelectionRevised"
proposal, but it is disputed for the
"No_edit_change_proposal_for_canvas_text_editing" proposal. So we must
examine the latter proposal in more detail to fully evaluate this
objection.


== Superimposing text fields as an alternative:

Superimposing text fields over a canvas is conceded to be sufficient
for simple use cases, such as editing a label on a graph.

However, one proposal argued that superimposing text fields is
insufficient for rich text editors using "embedded font layout, custom
fonts, and arbitrary objects and glyphs". No supporting evidence was
given for this claim. The other proposal says that superimposing a rich
text editing control is sufficient for more complex use
cases. Microsoft Office online and SkyDrive were cited as examples
using this technique.

On the whole, it seems like overlaying a text field or a rich text
control is a viable alternative; no evidence is provided otherwise. In
fact, a specific example is provided of the rich text case. Thus, the
objection to the overlay solution is taken to be a very weak objection
for lack of evidence.


== New vs existing features:

We conclude that both proposals meet the required use cases. Normally
the presumption is against adding new features when existing features
would satisfy the use cases in question. The new feature would have to
show compelling benefits that make it far better for at least some
uses, and which are not offset by the disadvantages.


== Argument from existing use of canvas-based editing:

One survey objection states, with regard to the
"No_edit_change_proposal_for_canvas_text_editing" proposal:

    As already noted, this stricture has not worked. There's no
    evidence this will change. We have not heard that LibreOffice will
    withdraw, nor have we any evidence that some author will not ask
    something as simple as "Enter your name here:" in canvas.  So, if
    the WG cannot prevent text editing in canvas, it should recognize
    that a11y will be harmed if the technology to support assistive
    technologies is excluded. Please do not undermine a11y over an
    unwinnable preference.

Considering this statement generally, it doesn't seem to be the case
that *no* canvas-based editor will change its approach. This seems to
be false as a universal claim. Mozilla Bespin (later Skywriter and
then Ace) was a frequently cited canvas-based text editor which has
moved to non-canvas-based editing.

To interpret this argument in the strongest possible way, let us take
it as a claim specifically with regards to LibreOffice Online, a
product that has been cited directly. No technical reason is provided
for why LibreOffice Online could not use existing HTML features to
achieve accessibility. No technical obstacles are cited.

This is on some level a valid objection. However, LibreOffice Online
is not a released product; it exists (as far as can be determined)
only as a prototype, and can be seen only in the form of a demo
video. As seen in the cited email announcement, this product was
created with the knowledge that canvas text editing was controversial,
and that accessibility functionality was missing. Given this, the
argument based on inconvenience of change can only be given limited
(moderate) weight.


== Non-accessibility Limitations of direct in-canvas text editing:

As noted above, in-canvas text editing has many weaknesses and
limitations, requiring significant implementation work to provide
various non-accessibility features. Examples include international
text input (IMEs) and system spellchecking.

The caret/selection API would not address these, as the warning text
and the alternative technique of overlaying a text field or rich text
control does.

One survey objection counters this, saying "Yet, LibreOffice has
already built a rich text editor in canvas that supports multiple
languages." This statement is vague as written. It's not clear if this
means that LibreOffice supports all or most of the challenging text
editing features, a subset including all the features related to
internationalization (including IMEs), or merely some form of
multi-language support.

The interpretation as "some form of multi-language support" would not
rebut the argument that canvas-based text editing is deficient in
crucial ways. It is too limited a claim. Therefore let us examine the
stronger forms.

If the claim is that LibreOffice Online supports all
internationalization-related text editing features, including support
for system-built in international text input methods, then this is an
extraordinary claim. Such an extraordinary claim would require
extraordinary evidence. Because LibreOffice Online is only a prototype
and not yet (apparently) available online, it is impossible to check
the claim directly. A vague claim that LibreOffice Online "supports
multiple languages" is not sufficient evidence for this type of claim,
if that is indeed the claim being made.

Overall, then, the severe limitations of canvas text editing form a
moderately strong objection to the CaretSelectionRevised
proposal. Since (apparently) the use cases for accessible editing in
canvas-based apps can be otherwise met with the overlay technique, the
fact that the direct in-canvas technique would omit key functionality
is an important point to consider.


== Arguments that were given no weight:

- "I object to having this text in the HTML5 spec. as it states that
  authors should not do rich text editing using canvas because it is
  technically hard..." -- Neither proposal suggests removing the
  warning text in the HTML5 spec. Thus, this argues for a proposal
  that is not on the table.

- "..the company advocating this change proposal is the largest
  producer of rich text editing products brings into question, for me,
  the motivation for making this change proposal." -- Ad hominem.

- "If it were not technically feasible to produce a rich text editor
  in canvas or it were proven that we could not produce an accessible
  rich text editor with canvas then those arguments would be grounds
  for having this text in the document..." -- No one made either of
  the claims rebutted here.


*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the <data> element change
proposal:

   http://www.w3.org/wiki/No_edit_change_proposal_for_canvas_text_editing

Of the Change Proposals before us, this one has drawn the weaker objections.


== Next Steps ==

Since the prevailing Change Proposal does not call for a spec change,
no further action is required. ISSUE 205 will now be closed.


== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.


== Revisiting this Issue ==

This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* Identification of one or more actual tools (more is better) with
  requirements that can't reasonably (as determined by the authors of
  these tools) by satisfied by the existing HTML Canvas functionality,
  potentially augmented by techniques such as superimposing text
  fields; explicit identification of these requirements and
  limitations; identification of features which specifically address
  these limitations; and an indication by the authors of the tools
  cited that they would actually use these features if they were
  provided.

* Stronger, verifiable evidence that applications based on pure-canvas
  text editing can overcome the many cited limitations.

Received on Wednesday, 18 July 2012 01:56:57 UTC