Add Canvas writingMode and textOrientation#12153
Add Canvas writingMode and textOrientation#12153schenney-chromium wants to merge 3 commits intowhatwg:mainfrom
Conversation
|
cc @whatwg/canvas |
|
cc @fantasai |
| <p>Can be set, to change the writing mode. The possible values and their meanings are given | ||
| below. Other values are ignored. The default is "<code | ||
| data-x="dom-context-2d-writingMode-horizontal">horizontal</code>".</p> | ||
| </dd> |
There was a problem hiding this comment.
These domintro boxes are supposed to be self-contained. I see "given below" is an established pattern, but it seems wrong. Can we describe these new ones here and file an issue to redo the older ones?
The level of detail can be fairly low, just enough so someone knows what to do.
There was a problem hiding this comment.
I noticed this problem too. In particular the developer version of the spec does not include the "given below" descriptions. I started another PR at some point to address this but dropped it. I can pick it up again.
| object implementing the <code>CanvasTextDrawingStyles</code> interface is created, the <code | ||
| data-x="dom-context-2d-writingMode">writingMode</code> attribute must initially have the value | ||
| "<code data-x="dom-context-2d-writingMode-horizontal">horizontal</code>".</p> | ||
| </div> |
There was a problem hiding this comment.
We should make this modify an associated concept of the context instead of continuing to conflate public and private API. We should also use the modern "getter steps" and "setter steps" terminology.
|
|
||
| <div algorithm> | ||
| <p>The <dfn attribute for="CanvasTextDrawingStyles"><code | ||
| data-x="dom-context-2d-textOrientation">textOrientation</code></dfn> IDL attribute, on getting, |
| </dl> | ||
|
|
||
| <p>The <code data-x="dom-context-2d-writingMode">writingMode</code> attribute's allowed keywords | ||
| are as follows:</p> |
There was a problem hiding this comment.
I don't think this section adds much. Some of it should be inside the domintro and some of it should be part of the normative processing model probably.
There was a problem hiding this comment.
Got it. Will do.
| <tr> | ||
| <td><span>'writing-mode'</span></td> | ||
| <td><var>target</var>'s <code data-x="dom-context-2d-writingMode">writingMode</code> | ||
| using "vertical-rl" for <code data-x="dom-context-2d-writingMode-vertical">vertical</code>. |
There was a problem hiding this comment.
This should be marked up as a string. And maybe it should link back to its definition?
|
|
||
| <p>Horizontal position:</p> | ||
| <p>Apply the appropriate step from the following list to determine the value of | ||
| <var>inline offset</var>:</p> |
There was a problem hiding this comment.
We should use camel case for variable names. And I'd make the switch return a value. That seems clearer.
| </dl> | ||
| </li> | ||
|
|
||
| <li><p>Set the <var>anchor point</var> as follows:</p> |
There was a problem hiding this comment.
Wrapping is wrong here as the <li> has multiple children.
| <p>Vertical position:</p> | ||
| <li> | ||
| <p>Apply the appropriate step from the following list to determine the value of | ||
| <var>baseline offset</var>:</p> |
There was a problem hiding this comment.
Camel case plus return from the switch.
|
|
||
| <li><p>Return <var>result</var>, <var>physical alignment</var>, and the inline | ||
| box.</p></li> | ||
| <li><p>Return <var>result</var>, the inline box and <var>anchor point</var>.</p></li> |
|
I think it's worth considering whether the divergence from CSS (just (Is all canvas text today single-line? How likely is it to stay that way?) |
I've thought about these issues. My reasoning on
All canvas text right now is single line. If you want multi-line you put the There have been various proposals for more complex text styling in canvas including methods for laying out multiple lines, but they have all been made redundant by HTML-in-Canvas. We've even got TAG feedback on other canvas text features saying they would rather we moved HTML-in-Canvas forward due to the accessibility benefits. I'm not great at predicting the future but HTML-in-Canvas seems more likely than not. Once it exists I think the desire for new canvas APIs for styled and multi-line text will disappear. |
4 participants
Add canvas text style attributes for
writingModeandtextOrientation, as discussed in #issue11449The
writingModeattribute determines the orientation of the text string when measured and rendered, whiletextOrientationcontrols the orientation of individual glyphs within the string.In addition to documenting the attributes, this PR also updates the text preparation algorithm and the
measureTextalgorithm. Some other things are re-worded to make them direction agnostic, primarily by using CSS inline direction terminology.The choices made in defining behavior, particularly around the alignment attributes and the text metric bounding box attributes, are an attempt to capture the expectations of developers. Of particular concern is anything related to text baseline metrics which have no obvious interpretation for vertical text.
/canvas.html ( diff )
/infrastructure.html ( diff )