Closed Bug 1217757 Opened 4 years ago Closed 4 years ago

Update text selection spec for vertical writing mode

Categories

(Core :: DOM: Selection, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: TYLin, Unassigned)

References

(Blocks 2 open bugs, )

Details

Attachments

(2 files)

The UX spec and visual design in bug 921965 does not consider vertical writing mode. We should update them, and implement the support for AccessibleCaret.

Test case:
http://www.mongolfont.com/test/firefox/div.html
Flags: needinfo?(tchen)
See Also: → 1217841
I'll leave this bug for update the UX spec. The implementation for AccessibleCaret will be in bug 1217841.
Depends on: 921965
Summary: Support vertical writing mode for AccessibleCaret → Update text selection spec for vertical writing mode
UX will update the spec accordingly, target two weeks later.
Flags: needinfo?(tchen)
Jonathan provided some ideas about caret on the vertical text. See https://bugzilla.mozilla.org/show_bug.cgi?id=1217841#c0
Blocks: 1217841
Hi, here is the UX spec for vertical writing mode. Please refer to Page 30.

Let me know if you have any questions or there's a use case I missed, thanks!
Flags: needinfo?(tlin)
The spec does not specify the caret direction of vertical text between left-to-right (e.g. mongolian) and right-to-left (e.g. Chinese). If they are the same (both designed for right-handed), it would be better to specify that. Thanks.

Jonathan, do you have any comments?
Flags: needinfo?(tlin) → needinfo?(jfkthame)
That's an interesting question. I guess I had assumed the caret "drop" shapes would naturally appear on the block-end side of the text (i.e. "logical downwards"), like they do in horizontal writing; so the appearance shown in the spec from comment 4 is what I'd expect for vertical-lr (Mongolian), but for vertical-rl (Chinese, Japanese) it would be the opposite.

But I can see that for a right-handed user, it may be better to have the drops on the right-hand side of the text, regardless of the block-progression direction, because this makes it easier to see the text while manipulating the carets. Presumably that is what has driven the design choice here? I think, as you say, that it would be good to make this explicit.

If that's so -- the orientation of the carets is designed for the typical user's handedness, not controlled by the direction of the content -- then perhaps we should also implement a "left-handed" option within the AccessibleCaret code, which would reverse the carets so that they appear to the left of the text. (Whether/how to expose this as a user preference would be a product design decision. I could imagine a setting "[x] Use left-handed selection carets in vertical text" somewhere in Fennec and FirefoxOS settings...)
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #6)
> But I can see that for a right-handed user, it may be better to have the
> drops on the right-hand side of the text, regardless of the
> block-progression direction, because this makes it easier to see the text
> while manipulating the carets. Presumably that is what has driven the design
> choice here? I think, as you say, that it would be good to make this
> explicit.

Yes, from UX perspective, the direction of caret should be same for vertical-lr and vertical-rl, since most users are right-hander. I'll note this in the spec.

> If that's so -- the orientation of the carets is designed for the typical
> user's handedness, not controlled by the direction of the content -- then
> perhaps we should also implement a "left-handed" option within the
> AccessibleCaret code, which would reverse the carets so that they appear to
> the left of the text. (Whether/how to expose this as a user preference would
> be a product design decision. I could imagine a setting "[x] Use left-handed
> selection carets in vertical text" somewhere in Fennec and FirefoxOS
> settings...)

Good point. I can add this.
Duplicate of this bug: 1217693
Depends on: 1249548
The spec had been updated.
Status: NEW → RESOLVED
Closed: 4 years ago
No longer depends on: 1249548
Resolution: --- → FIXED
Duplicate of this bug: 1256233
You need to log in before you can comment on or make changes to this bug.