Platform/Features/Vertical text

Please use "Edit with form" above to edit this page.

Status

Vertical text
Stage	Draft
Status	`
Release target	`
Health	OK
Status note	`

{{#set:Feature name=Vertical text

|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature 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	`

{{#set:Feature product manager=Jet Villegas

|Feature feature manager=` |Feature lead engineer=Simon Montagu |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature 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 and text-orientation properties.

Non-goals

• Support all of the CSS Writing Modes specification
  • For example, properties such as unicode-bidi, text-combine-horizontal, and text-combine-mode are probably outside the scope of this feature
• Support HTML ruby
• Support vertical text in SVG

Stage 2: Design

5. Functional specification

• Bug 0 - Prototype
• Bug 1 - Parse writing mode and text-orientation
• Bug 2 - Logicalize Reflow APIs
• Bug 3 - Logicalize Reflow for all frame classes
• Bug 4 - Refactor and extend logical CSS properties
• 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 2: Parsing of writing-mode and text-orientation
  (see Implementation below)

The above is done. Steps to implement (parallelizable steps preceded by --> to indicate possible forking-off):

• --> Bug 4 - Refactor existing logical CSS properties
• Bug 1 - Parse writing mode and text-orientation
• --> Extend logical CSS properties to handle vertical text (depends only on Bugs 1 and 4)
• Bug 2: Logicalization of layout parameters
  • May involve some renaming across the layout engine, but shouldn't affect logic at this point
  • Note that some frame classes will continue to be physical, e.g. images, even after full logicalization
• Bug 3: Logicalize Block and Inline layout
  • Logicalize nsBlockFrame. Get vertical-only/horizontal-only documents consisting of only block frames working/tested
  • Note that not all properties get treated the same. For example, the offset of a text-shadow property is unaffected by writing mode.
  • Logicalize nsLineLayout, nsInlineFrame, nsTextFrame, etc. Get inline layout working for vertical-only documents. Make the text just draw sideways for now.
• --> After block and inline layout, other frame classes can be converted set by set, e.g.
  • Tables
  • Flexbox
  • etc.
• --> Bug 4: Orthogonal flows
  • Probably requires a lot of rework of intrinsic sizing. This is a complicated task!
• --> Bug 5: UI features
  • scrollbars
  • mapping scrollwheel
  • vertical text selection
  • vertical text selection cursor
  • caret browsing
  • list boxes/combo boxes (initial implementation should just transform the control; next pass does actual vertical layout)
  • 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

Main bugzilla entry

• 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? [There shouldn't be any perf cost.]

• 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

` {{#set:Feature open issues and risks=Specification is in flux. |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. |Feature users and 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

|Feature dependencies=` |Feature 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 and text-orientation properties.

|Feature non-goals=* Support all of the CSS Writing Modes specification

• • For example, properties such as unicode-bidi, text-combine-horizontal, and text-combine-mode are probably outside the scope of this feature
• Support HTML ruby
• Support vertical text in SVG

|Feature functional spec=* Bug 0 - Prototype

• Bug 1 - Parse writing mode and text-orientation
• Bug 2 - Logicalize Reflow APIs
• Bug 3 - Logicalize Reflow for all frame classes
• Bug 4 - Refactor and extend logical CSS properties
• Bug 4 - Orthogonal Flows
• Bug 5 - UI
• Bug 6 - Text/Glyph Layout

|Feature ux design=` |Feature 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 2: Parsing of writing-mode and text-orientation
  (see Implementation below)

The above is done. Steps to implement (parallelizable steps preceded by --> to indicate possible forking-off):

• --> Bug 4 - Refactor existing logical CSS properties
• Bug 1 - Parse writing mode and text-orientation
• --> Extend logical CSS properties to handle vertical text (depends only on Bugs 1 and 4)
• Bug 2: Logicalization of layout parameters
  • May involve some renaming across the layout engine, but shouldn't affect logic at this point
  • Note that some frame classes will continue to be physical, e.g. images, even after full logicalization
• Bug 3: Logicalize Block and Inline layout
  • Logicalize nsBlockFrame. Get vertical-only/horizontal-only documents consisting of only block frames working/tested
  • Note that not all properties get treated the same. For example, the offset of a text-shadow property is unaffected by writing mode.
  • Logicalize nsLineLayout, nsInlineFrame, nsTextFrame, etc. Get inline layout working for vertical-only documents. Make the text just draw sideways for now.
• --> After block and inline layout, other frame classes can be converted set by set, e.g.
  • Tables
  • Flexbox
  • etc.
• --> Bug 4: Orthogonal flows
  • Probably requires a lot of rework of intrinsic sizing. This is a complicated task!
• --> Bug 5: UI features
  • scrollbars
  • mapping scrollwheel
  • vertical text selection
  • vertical text selection cursor
  • caret browsing
  • list boxes/combo boxes (initial implementation should just transform the control; next pass does actual vertical layout)
  • 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?)

|Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=Main bugzilla entry

• 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? [There shouldn't be any perf cost.]

• 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

|Feature landing criteria=` }}

Feature details

Priority	Unprioritized
Rank	999
Theme / Goal	`
Roadmap	Platform
Secondary roadmap	`
Feature list	`
Project	`
Engineering team	Layout

{{#set:Feature priority=Unprioritized

|Feature rank=999 |Feature theme=` |Feature roadmap=Platform |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=Layout }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	`	`
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}