A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Text in Canvas: Difference between revisions
Line 21: | Line 21: | ||
* http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-October/007363.html | * http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-October/007363.html | ||
* http://osteele.com/sources/javascript/docs/textcanvas | * http://osteele.com/sources/javascript/docs/textcanvas | ||
* http://canvaspaint.org/blog/2006/12/rendering-text/ | |||
=== Benefits === | === Benefits === |
Revision as of 21:49, 8 May 2007
Currently, the Canvas API does not include the ability to draw text strings. That makes several potential Canvas applications, such as dynamic graphs or maps, more complex than necessary. Instead of using the text facilities of the platform, Canvas applications need to bundle their own vector fonts or use inaccessible pre-rendered images for text display. Thus, using Canvas it is unattractive for authors and users are forced to use a proprietary plugin (Flash) for some applications.
Use Case Description
- Maps (Street names, ...)
- All kinds of graphs needing labels
- Games (High score, "Game Over" etc)
Current Limitations
Explanation of why the current markup is insufficient.
- Image workaround destroys potential accessibility options
Current Usage and Workarounds
Some evidence that this feature is desperately needed on the web. You may provide a separate examples page for listing these.
- http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-October/007363.html
- http://osteele.com/sources/javascript/docs/textcanvas
- http://canvaspaint.org/blog/2006/12/rendering-text/
Benefits
Explanation of how and why new markup would be useful.
Requests for this Feature
- Source
I would like this feature ...
Proposed Solutions
My Solution
- Brief description of the solution and of how it address the problem at hand.
Processing Model
- Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.
Limitations
- Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.
Implementation
- Description of how and why browser vendors would take advantage of this feature.
Adoption
- Reasons why page authors would use this solution.