Warning:
This wiki has been archived and is now read-only.

User:Cpritcha/ISSUE-201-eoconnor-counter

From HTML WG Wiki
Jump to: navigation, search


Arguments against the Change Proposal: Path object and related alterations to the 2d Context API

Summary

There appear to be two proposals for addressing ISSUE-201 (canvas hit testing), a simple Canvas hit testing proposal and the more complex Path object and related alterations API. Both proposals recommend that a new hit testing method be added to the Canvas API to support binding complex shapes (regions) to the fallback DOM. This document argues against the Path object and related alterations proposal.

The Path object from the Path object proposal should be examined independently of ISSUE 201. It is not necessary for implementation of ISSUE 201. The lightweight nodes in this proposal may be insufficient for accessibility, thus failing to meet the goals of ISSUE 201.

Rationale

A point of consensus

From the other Change Proposal for ISSUE-201:

The best approach to solving the accessibility issues in these complex canvas user interfaces would be to map the individual user interface elements in the canvas bitmap to multiple tabbable/focusable/etc input elements in the fallback DOM. We should enable authors to easily define hit testing regions on the canvas and map events to the underlying elements in the fallback dom. This will reduce author burden, and also solve the issue of reporting meaningful position+size information to accessibility tools.

Problems with the Path object API proposal

DOM elements are expensive and can negatively impact the performance of Web applications when created in large numbers.

DOM elements are not expensive nor do they have any practical impact on the performance of Web applications when used in large numbers within the Canvas DOM. Implementations have very minimal overhead for non-rendered DOM nodes (something like 60 bytes).


Relying on the fallback DOM for hit testing is problematic when <canvas> is being used to represent something that would require a very large number of DOM elements to acheive an equivalent representation. In such cases, it should be possible to hit test and provide location and size information to AT while not bearing the performance and memory costs of an excessive number of DOM elements.


Both speed and memory usage are well within tolerance for thousands of DOM nodes. Further, there is no practical use for thousands of simultaneously clickable regions. Such interfaces require additional user interface settings to be useful. It is possible to do this while maintaining full semantics and using the DOM. Instances which have a large number of DOM elements should contain strong semantics so that AT users may navigate those DOM elements effectively. The use of aria-setsize is encouraged, so as to limit the number of DOM nodes active at any time. For example, a graph showing ten thousand elements may be better managed in the DOM and for AT users by pagination techniques, aria-flowto and aria-posinset.


lightweight objects which simply provide a label and a WAI-ARIA role.... [help] authors to make their canvas content accessible without incurring an unacceptable performance penalty.

Lightweight objects are poor in ARIA semantics and greatly limit the ability of authors and AT users to navigate content. There have not been any use cases or examples put forward for lightweight objects and the assertion of a performance penalty (or enhancement) is not backed by evidence. Many instances with a large number of objects, such as a chart, would be under-served by lightweight nodes. They require the semantics of ARIA to be navigable by web rotors (a common AT method of navigating between like objects) and to have linking to appropriate parent information (such as column headers or row headers).


Having an exposed Path object and encouraging authors to use such Path objects for describing hit regions helps authors to write accessible and maintainable canvas applications. Authors use the 2d context object's current default path for drawing operations, and the 2d context API is designed around the assumption that the current default path is used solely for drawing. Using the current default path to create paths used not for drawing but only for hit testing is awkward; it would be a cleaner, more comprehensible API for authors to be able to explicitly create a hit testing path without pretending that it will be used for drawing.

Path operations are used to create regions; it is the fill and stroke operations that are used solely for drawing. The proposal seems to have conflated those, trying to automatically bind fill and stroke operations to interactive regions. Authors often use path operations for hit testing, with isPointInPath, with bitmap backed hit testing and with author implemented testing (most common). Using the current default path is the current standard.

Both proposals allow for using the current default path. The path operations proposal attempts to bind rendering directly to hit testing. This will lead to extra work for authors as they will have to undo the work the automatically executed by the implementation. Authors would have to use transparent fill styles to setup hit testing as well as temporary canvas layers when creating text effects. This proposal will lead to a burden on authors, ironically, by automating hit testing actions that should not be automated.

Issue/Example: authors often run repeated calls, such as repeated calls to fillText in order to create effects. See the text effect examples in SVG serialization here: http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm. The proposal would create many unnecessary copies of the same text in the accessibility tree; authors would have to use additional temporary layers to handle their normal work; many would not even know that something has gone wrong with their use of fillText.


  • New text metrics allow authors to reliably know where text is drawn onto the canvas, for better hit testing and many other use cases.

There already exists a simple proposal for enhanced text metrics, adding only one attribute. This proposal has redundant attributes, using five attributes where one could and should be used. The proposal has no claim to creating benefits that already exist from prior proposals. The TextMetrics baseline proposal already addresses a good part of these properties and has a patch pending for one implementation. It is a superior proposal as it avoids redundancy.

Note the redundancy in the proposed Canvas API changes: "zero if textBaseline is top... zero if textBaseline is bottom... zero if textBaseline is hanging... zero if textBaseline is alphabetic... zero if textBaseline is ideographic"


  • Authors can easily draw dashed lines and ellipses.

This has nothing to do with ISSUE-201. There is no need to create a new Path object for accessibility. The new Path object is an addition which should be considered separately from ISSUE 201.


  • Existing implementations of the 2d Context API need to be updated to implement the new objects, interfaces, and methods.

The proposed changes are far reaching, creating a new Path object without consultation with the SVG2 WG nor WebGL groups. The changes are broad and would require a significant investment of time by implementer. The priority should be in addressing the accessibility needs common to both proposals.


  • As with all author-facing features, if mainstream User Agents do not implement these API enhancements, we would need to drop them in the future.

These changes were not made with input from the Canvas WG. One vendor has already objected to these changes. The changes are not particular to Canvas accessibility but are instead a new revision of the Canvas API. Many of the design choices have been explicitly ruled out as viable or helpful during discussions held by the Canvas WG. This change proposal risks the of the Canvas 2D API in relation to Last Call. The author of the proposal has limited experience in developing Canvas Web Applications. As evidence, the author of the proposal explicitly rejected the use case for Canvas API regions earlier in the process. Only with a great amount of assistance by the WG did the author come to understand why regions were necessary.