Platform/Features/Vertical text
Status
Vertical text | |
Stage | Draft |
Status | ` |
Release target | ` |
Health | OK |
Status note | ` |
Team
Product manager | Jet Villegas |
Directly Responsible Individual | ` |
Lead engineer | Simon Montagu |
Security lead | ` |
Privacy lead | ` |
Localization lead | ` |
Accessibility lead | ` |
QA lead | ` |
UX lead | ` |
Product marketing lead | ` |
Operations lead | ` |
Additional members | ` |
Open issues/risks
Specification is in flux.
Stage 1: Definition
1. Feature overview
Add support for vertical text layout.
Text for most scripts on the web today are laid out horizontally. However, Japanese, Chinese and to some degree Korean can also be laid out vertically. When laid out vertically, these languages use top-to-bottom, right-to-left flows. Classical Mongolian is generally considered a "vertical only" language, although in multi-script contexts it can also be drawn horizontally. Mongolian, along with Phags-pa flows top-to-bottom, left-to-right. Western text such as Latin, Greek and Cyrillic can also be displayed vertically, examples of this often appear on book spines and in signage.
2. Users & use cases
Users: publishers of vertically typeset content (e-publishing organisations, independent web authors, especially in East Asia)
Example use cases:
- Web-based e-readers for Japanese novels (especially on mobile devices)
- Web pages that use classical Mongolian script
3. Dependencies
`
4. Requirements
- Support vertical text for whole documents (i.e. initial containing block uses a vertical writing mode) and document fragments (i.e. orthogonal flows)
- Support both top-to-bottom, right-to-left (e.g. CJK) and top-to-bottom, left-to-right (e.g. Mongolian) writing modes.
- As far as possible (particularly given that the spec is in flux), conform to the relevant parts of CSS3 Writing Modes specification—most likely the
writing-mode
andtext-orientation
properties.
Non-goals
- Support all of the CSS Writing Modes specification
- For example, properties such as
unicode-bidi
,text-combine-horizontal
, andtext-combine-mode
are probably outside the scope of this feature
- For example, properties such as
- Support HTML ruby
- Support vertical text in SVG
Stage 2: Design
5. Functional specification
- Bug 0 - Prototype
- Bug 1 - Logicalize
- Bug 2 - Parse
- Bug 3 - Layout
- Bug 4 - Orthogonal Flows
- Bug 5 - UI
- Bug 6 - Text/Glyph Layout
6. User experience design
`
Stage 3: Planning
7. Implementation plan
- Prototype of a vertical text layout. This will include:
- logicalization of a minimum of frame types
- layout of a minimum of frame types
- Glyph layout of CJK only
- Parsing, orthogonal flows and UI will not be included
- Bug 1: Logicalization of layout parameters
- Renaming
- Note that not all properties get treated the same. For example, the offset of a
text-shadow
property is unaffected by writing mode. - Get all tests to pass with logical params in use
- Bug 2: Parsing of
writing-mode
andtext-orientation
(see Implementation below) - Bug 3: Layout
- i.e., in a document with a vertical writing mode, laying out the whole document with a horizontal block flow and vertical text flow
- Bug 4: Orthogonal flows
Unicode Technical Note #22 - Bug 5: UI features
- scrollbars
- mapping scrollwheel
- vertical text selection
- vertical text selection cursor
- caret browsing
- list boxes/combo boxes
- menus
- other?
- Bug 6: Glyph orientation
- Using character properties such as those defined in UTR-50 (currently under review)
- Supporting different modes as necessary (e.g. stacked vs default, cf.
text-orientation
which is in flux) - Glyph selection—choosing vertical variants, using vertical metrics
- OpenType model for vertical text needs to be flushed out a bit more (e.g. which features are on by default in the vertical case?)
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
- Need to investigate how to pref CSS keyword parsing (and all writing-mode processing) on and off. (This is relatively straightforward, now that bug 753522 is implemented. Just specify the pref in the property's chunk of nsCSSPropList.h, and use Preferences::GetBool() elsewhere if necessary.)
- Possibly want to be able to
#ifdef
it as well? Or just back out the changes after each uplift so we don't pay the perf cost until it's ready?
- Multi-column vertical layout
- Form controls
- Tables
- (Probably lots of other HTML elements that require special handling? e.g. list markers. Presumably images don't rotate (i.e. width/height are physical) but form controls do?)
- Pagination
- Implement
min/max/fit-content
,fill-available
Stage 5: Release
10. Landing criteria
`
Feature details
Priority | Unprioritized |
Rank | 999 |
Theme / Goal | ` |
Roadmap | Platform |
Secondary roadmap | ` |
Feature list | ` |
Project | ` |
Engineering team | Layout |
Team status notes
status | notes | |
Products | ` | ` |
Engineering | ` | ` |
Security | ` | ` |
Privacy | ` | ` |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | ` | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |