Confirmed users
61
edits
Canvas:Text: Difference between revisions
m
legitimate use case for non-selectable text, and why we need measureText
(→API) |
m (legitimate use case for non-selectable text, and why we need measureText) |
||
| Line 9: | Line 9: | ||
void pathText(in string textToDraw); | void pathText(in string textToDraw); | ||
Do we need measureText? | Do we need measureText? (myk: yes, so that you can resize the canvas to the size of the text, which is useful when you're using the canvas as an object representation of some text, f.e. in the microsummary editor, about which read more below) | ||
textStyle: [http://www.w3.org/TR/CSS21/fonts.html#font-shorthand CSS 2.1 "font" shorthand], e.g. "12pt bold Helvetica". Reading textStyle just returns the last string that was passed in. Defaults to whatever the user's default sans serif font is (maybe serif font? what's the default for text if no font is specified?). | textStyle: [http://www.w3.org/TR/CSS21/fonts.html#font-shorthand CSS 2.1 "font" shorthand], e.g. "12pt bold Helvetica". Reading textStyle just returns the last string that was passed in. Defaults to whatever the user's default sans serif font is (maybe serif font? what's the default for text if no font is specified?). | ||
| Line 26: | Line 26: | ||
* vlad: nope, this is an entirely un-accessability-non-graphical-browser-friendly way to draw text. The rationale, however, is that canvas as a whole has fallback when canvas isn't available, because even the graphics you draw may have just as much or more meaning than any text. There are plenty of ways to get around having a text-drawing API, they're just painful and annoying, but not impossible -- which means someone will wrap it in some JS and make it easy, just possibly slow. So if people are going to do it anyway, we may as well provide the API and make everyone happy. | * vlad: nope, this is an entirely un-accessability-non-graphical-browser-friendly way to draw text. The rationale, however, is that canvas as a whole has fallback when canvas isn't available, because even the graphics you draw may have just as much or more meaning than any text. There are plenty of ways to get around having a text-drawing API, they're just painful and annoying, but not impossible -- which means someone will wrap it in some JS and make it easy, just possibly slow. So if people are going to do it anyway, we may as well provide the API and make everyone happy. | ||
* myk: there are legitimate uses for non-selectable text. For example, the [[Microsummaries]] support I'm building for Firefox includes a microsummary editor that lets users mix snippets of text from a summarized page with arbitrary text.<br><br>Snippet text isn't editable by the user, since it's really just a user-friendly representation of an XPath expression that pulls content from the page, so the editor needs to represent snippets as objects which can be added, deleted, or moved around, not character data that can be selected and manipulated as individual characters.<br><br>My first thought was to use SVG to draw the text, but the SVG spec says that SVG text must be selectable. So now I'm rendering text in a hidden iframe and then drawing it onto a canvas, as roc suggests, and that works fine, but it's way overcomplicated for my simple needs. | |||