CSS: current status and future directions for global languages
for EPUB EGLS Sapporo F2F
MURAKAMI Shinyu (Antenna House, W3C CSSWG)
General
- What is CSS2.1 and when will it be completed?
- What is CSS3 and when will each module is expected to be completed?
- W3C process (editor's draft, working draft, CRs, Proposed RECs, REC, etc.)
- Why is CSS development so slow?
- Overview of CSS3 modules: which one is relevant to EGLS?
What is CSS2.1 and when will it be completed?
- CSS2.1 = CSS Level 2 Revision 1
- CSS2.1 fixes errors in CSS2, removes poorly-supported features and adds already-implemented browser extensions to the specification.
- CSS2.1 is now a Candidate Recommendation, effectively the same level of stability as CSS2, and should be considered to obsolete the CSS2 Recommendation.
History of CSS Level 2
- 1998 CSS2 Recommendation
- 2002- CSS2.1 Working Draft
- 2004, 2007- CSS2.1 Candidate Recommendation
- 2010(?) CSS2.1 Proposed Recommendation
- 2011(?) CSS2.1 Recommendation
What is CSS3 and when will each module is expected to be completed?
- CSS Level 3 builds on CSS Level 2 module by module. Each module adds functionality and/or replaces part of the CSS2.1 spec.
- From this level modules are levelled independently:
for example Selectors Level 4 may well be defined before CSS3 Line module. - Experimental implementations of features in CSS Working Drafts should use vendor-prefixed property names.
- Once a specification reaches the Candidate Recommendation stage, implementors should implement the non-prefixed syntax.
- Some CSS3 modules already have reached the Candidate Recommendation stage.
The following CSS3 modules already have reached the Candidate Recommendation stage (almost finished):
- CSS3 Backgrounds and Borders
(was reverted to a working draft but it is expected to return to CR) - CSS3 Paged Media
(was reverted to a working draft but it is expected to return to CR) - CSS3 Multi-column Layout
- CSS3 Color
- CSS3 Basic User Interface
- CSS3 Marquee
- CSS3 Namespaces
- CSS3 Selectors
- CSS3 Media Queries
- CSS3 Ruby (currently CR, but next will be reverted to a working draft)
But many other modules are far from finished...
W3C Process
- Call for Implementations
- CR exit criteria: There must be at least two independent, interoperable implementations of each feature, passing the respective test cases in the official CSS test suite.
- There was no CR stage when CSS2 REC (1998) was published.
- Call for Review to the Advisory Committee for final endorsement.
Why is CSS development so slow?
- The CR exit criteria are severe: There must be at least two interoperable implementations of each feature, passing the respective test cases in the test suite.
- Official W3C CSS Test Suites: Currently, the CSS2.1 Conformance Test Suite, under developing in Beta phase, contains about 10,000 test cases. Developing test suites is tough work. Many interoperability issues are found by test cases.
“Interoperability is important to web designers. Better interoperability among CSS implementations means designers can write their CSS for one browser and see that it works predictably well on the other browsers. It means reducing the incompatibilities in the way CSS implementations interpret CSS.”
Overview of CSS3 modules: which one is relevant to EGLS?
- CSS3 Text Layout
- vertical text
- CSS3 Text
- Line breaking restrictions
- Justification method
- Punctuation kerning
- Hanging punctuation
- Emphasis marks
- CSS3 Ruby
- Ruby positioning
- Ruby alignment
- CSS3 Basic Box Model
- differs from the model described in the CSS2.1, because it is generalized to apply also to vertical text...
CSS3 Text Layout
CSS3 Text Layout describes the properties that control text direction.
- Inline Direction and Bidirectionality (almost same as CSS2.1)
- Block Flow Direction: the 'block-flow' property
- block-flow: tb (top to bottom) → horizontal writing
- block-flow: rl (right to left) → vertical writing, CJK
- block-flow: lr (left to right) → vertical writing, Mongolian
- The 'writing-mode' shorthand property
- writing-mode: lr-tb → direction: ltr; block-flow: tb
- writing-mode: rl-tb → direction: rtl; block-flow: tb
- writing-mode: tb-rl → direction: ltr; block-flow: rl
- writing-mode: tb-lr → direction: ltr; block-flow: lr
Schedule: First Public Working Draft will be published on October 2010
Problems with the CSS3 Text Layout 'writing-mode' property
- CSS3 Text Layout is still at a very early stage.
There's no official W3C Working Draft yet, only an Editor's Draft exists.
http://dev.w3.org/csswg/css3-text-layout/ - MS IE is the only major browser that supports the writing-mode which is based on old CSS3 drafts (since IE5.5, 2000). Other major browsers are unlikely to implement it.
- In vertical writing mode, the 'margin-left' is absolutely the left side, or the top side? -- The W3C CSSWG's answer is currently
the 'left' is absolutely the left side
, but it causes difficulty: we have to specify different margin/border/padding properties for each writing mode. - The specification may be revised drastically to resolve the problem. (Some proposals are described in the current CSS3 Text Layout Editor's Draft "Proposals for Dealing with Writing Mode Switching" section)
horizontal writing mode | vertical writing mode |
---|---|
h1 { border-left: 12pt solid; margin-bottom: 12pt; } blockquote { margin-left: 3em; } |
h1 { border-top: 12pt solid; margin-left: 12pt; } blockquote { margin-top: 3em; } |
vertical writing mode | if vertical writing mode is not supported |
---|---|
h1 { border-top: 12pt solid; margin-left: 12pt; } blockquote { margin-top: 3em; } |
A style sheet intended for vertical writing mode provides miserable results for horizontal writing mode. |
Requirements for Writing Mode Switching
E-book viewers supporting vertical writing often have the writing mode switching feature. See such example, Lovely Reader's screen shots:
We expect e-books intended for vertical writing mode work reasonably with horizontal. Note that many viewers only support horizontal writing.
Proposals for Dealing with Writing Mode Switching
There are several proposals for dealing with writing mode switching.
- Use alternate style sheets for both writing modes
- Pseudo class selectors: :ltr, :rtl, and :ttb
- Add a Media Query: @media (vertical-text)
- Logical properties: margin-before/after/start/end, etc.
- Directional-mode switch (physical/logical): in logical directional-mode, treat 'top' as the 'before' side.
- Change directional definitions: treat 'top' as always the 'before' side.
[Proposals for Dealing with Writing Mode Switching]
Use alternate style sheets for both writing modes
Style sheets:
/* horizontal.css */ html { writing-mode: lr-tb } h1 { border-left: 12pt solid; margin-bottom: 12pt; } blockquote { margin-left: 3em; } ... |
/* vertical.css */ html { writing-mode: tb-rl } h1 { border-top: 12pt solid; margin-left: 12pt; } blockquote { margin-top: 3em; } ... |
(X)HTML:
<link rel="stylesheet" href="horizontal.css" type="text/css" title="Horizontal"/> <link rel="alternate stylesheet" href="vertical.css" type="text/css" title="Vertical"/>
Advantages of using alternate style sheets for both writing modes
- Alternate style sheets are a standard mechanism defined in HTML4/XHTML1.
- We can write best suited styles for each writing mode.
Disadvantages
- The vertical style sheets can't be default since browsers not supporting vertical writing can't deal with.
- We have to write both horizontal and vertical versions of style sheets with all different margin/border/padding properties.
[Proposals for Dealing with Writing Mode Switching]
Pseudo class selectors: :ltr, :rtl, and :ttb
- :ltr
- horizontal writing is supported and @dir has been set to 'ltr'
- :rtl
- horizontal writing is supported and @dir has been set to 'rtl'
- :ttb
- vertical writing is supported and the initial value of 'writing-mode' is 'tb-rl'
Here @dir is the 'dir' attribute in (X)HTML. In this proposal, the initial value of the 'writing-mode' property can be set by user preference.
Example:
blockquote:ltr { margin-left: 3em; } blockquote:rtl { margin-right: 3em; } blockquote:ttb { margin-top: 3em; }
Advantages of the :ltr/rtl/ttb pseudo classes proposal
- We can write best suited styles for each writing mode.
Disadvantages
- We have to write both horizontal and vertical versions of style rules with all different margin/border/padding properties.
- Standardizing new pseudo classes will take long time, possibly we have to wait CSS Selectors Level 4.
[Proposals for Dealing with Writing Mode Switching]
Add a Media Query: @media (vertical-text)
Example:
h1 { border-left: 12pt solid; margin-bottom: 12pt; } blockquote { margin-left: 3em; } ... @media (vertical-text) { /* if vertical writing is supported: */ html { writing-mode: tb-rl } h1 { border-left: none; border-top: 12pt solid; margin-bottom: 0; margin-left: 12pt; } blockquote { margin-left: 0; margin-top: 3em; } ... }
Advantages of the vertical-text Media Query proposal
- We can write best suited styles for each writing mode.
Disadvantages
- We have to write both horizontal and vertical versions of style rules with all different margin/border/padding properties.
- Standardizing new Media Query will take time.
[Proposals for Dealing with Writing Mode Switching]
Logical properties: margin-before/after/start/end, etc.
writing-mode: lr-tb | writing-mode: tb-rl |
---|---|
↑before=top
←
start =left→ end =right ↓after=bottom
|
↑start=top
←
after =left→ before =right ↓end=bottom
|
h1 { border-start: 12pt solid; margin-after: 12pt; } blockquote { margin-start: 3em; } |
Same margin/border/padding properties can be used for both writing modes. |
Advantages of the logical properties proposal
- We can use same margin/border/padding properties for all writing modes.
- Style sheets intended for vertical writing mode work reasonably with horizontal writing mode, and vice versa.
- Logical (writing mode relative) properties are standardized in W3C XSL-FO spec (another style sheet language) and we can use same directional terms (before/after/start/end).
Disadvantages
- If new properties are direction-dependent aliases of existing ones, the cascading process has to consider the computed value of 'writing-mode'.
If they are not, CSS implementations will have to maintain many more properties. - Unlike other possibilities, this proposal cannot control other properties. Thus, it does not allow best suited styles for both writing modes.
[Proposals for Dealing with Writing Mode Switching]
Directional-mode switch (physical/logical): in logical directional-mode, treat 'top' as the 'before' side
horizontal writing mode | vertical writing mode, logical |
---|---|
↑top (before)
←
left (start)→ right (end) ↓bottom (after)
|
↑left (start)
←
bottom (after)→ top (before) ↓right (end)
|
h1 { border-left: 12pt solid; margin-bottom: 12pt; } blockquote { margin-left: 3em; } |
Same properties can be used for both writing modes. In vertical writing mode with 'directional-mode: logical', the directions are rotated 90deg. |
Advantages of the directional-mode switch proposal
- We can use same existing properties for both horizontal and vertical writing modes.
- Style sheets intended for vertical writing mode work reasonably with horizontal writing mode, and vice versa.
- The default directional-mode is physical ('left' is absolutely the left) and it is compatible with the current CSS3 writing-mode draft spec and MS IE's implementation.
Disadvantages
- It distorts the meanings of directional words: in vertical mode, 'left' means top, 'top' means right, etc.
- It has a very disturbing effect on the cascade -- parts of the cascade that assume one directional mode will break horribly when that assumption is changed later in the cascade.
[Proposals for Dealing with Writing Mode Switching]
Change directional definitions: treat 'top' as always the 'before' side.
horizontal writing mode | vertical writing mode |
---|---|
↑top (before)
←
left (start)→ right (end) ↓bottom (after)
|
↑left (start)
←
bottom (after)→ top (before) ↓right (end)
|
h1 { border-left: 12pt solid; margin-bottom: 12pt; } blockquote { margin-left: 3em; } |
Same properties can be used for both writing modes. In vertical writing mode, the directions are rotated 90deg. |
Advantages of the changing directional definitions proposal
- We can use same existing properties for both horizontal and vertical writing modes.
- Style sheets intended for vertical writing mode work reasonably with horizontal writing mode, and vice versa.
- By adopting this change, the vertical writing mode will be similar to 2D transforms rotate(90deg) that modern browsers already support, that is, implementing vertical writing mode will become easier.
- There are already several implementations (vertical browsers, EPUB viewers) supporting vertical writing mode with this method.
Disadvantages
- It distorts the meanings of directional words: in vertical mode, 'left' means top, 'top' means right, etc.
- It is not compatible with the current CSS3 writing-mode draft spec and MS IE's implementation.
CSS3 Text
- Line breaking restrictions: the 'word-break' property
- Justification method: the 'text-justify' property
- Punctuation kerning: the 'punctuation-trim' property
- punctuation-trim: start end adjacent → fullwidth punctuation character is trimmed (kerned) if it appears at the start or end of a line, or adjacent to another fullwidth punctuation character.
- Hanging punctuation: the 'hanging-punctuation' property
- hanging-punctuation: allow-end → Punctuation (specifically, full stops 。 . and commas 、 ,) may hang outside the end edge of all lines if the punctuation does not otherwise fit prior to justification.
- Emphasis marks
- text-emphasis: accent → 強調
CSS3 Text has been severely revised since it was reverted to a working draft from 2003 CSS3 Text CR. Many sections intended for this module are not yet represented in the current draft. The spec is far from finished.
Options: Should EPUB adopt CSS3 features?
- Wait until CSS3 is finished. Don't adopt unfinished CSS3 features.
- Adopt CSS3 properties in draft specs with a prefix (e.g. -idpf-writing-mode, -idpf-text-emphasis).
- Introduce EPUB specific CSS properties.
- Use style specification other than CSS3 (XSL-FO, or EPUB specific style language).
- Add style info (especially, horizontal/vertical text direction) in OPF package document.
- Add 'text-direction' and 'page-progression-direction' attributes in OPF
- Introduce EPUB specific class names and define their styles instead of using CSS3 properties.
- Define class names for emphasis marks
[Options: Should EPUB adopt CSS3 features?]
Add 'text-direction' and 'page-progression-direction' attributes in OPF
Advantages: It can avoid using unfinished CSS3 properties; The viewer can determine directions without accessing CSS files.
'text-direction' attribute
Value: | auto | ltr | rtl | ttb-rtl | ttb-ltr |
Default: | auto (both ltr and ttb-rtl are possible) |
'page-progression-direction' attribute
Value: | auto | ltr | rtl |
Default: | auto (depends on 'text-direction') |
These attributes should be able to specify for the whole book and for individual OPS content documents.
How to specify Horizontal in Vertical text
The followings are proposals for specifying horizontal text within vertical text layout:
Proposal: Use XHTML 'dir' attribute. Treat elements with dir="ltr" or dir="rtl" in vertical text mode as horizontal text.
e.g., 縦中横<span dir="ltr">22</span>年
<table dir="ltr">
...
Another proposal: Define a class name for specifying horizontal in vertical text
- idpf-horizontal
e.g., 縦中横<span class="idpf-horizontal">22</span>年
<table class="idpf-horizontal">
...
[Options: Should EPUB adopt CSS3 features?]
Define class names for emphasis marks
e.g. <em class="idpf-sesame-dot">圏点つきのテキスト</em>
Aozora Bunko's XHTML uses this way.
See: http://kumihan.aozora.gr.jp/emphasis.html
Predefined class names for emphasis marks:
- idpf-sesame-dot (﹅)
- idpf-white-sesame-dot (﹆)
- idpf-black-circle (●)
- idpf-white-circle (○)
- idpf-black-up-pointing-triangle (▲)
- idpf-white-up-pointing-triangle (△)
- idpf-bullseye (◎)
- idpf-fisheye (◉)
Ruby - XHTML simple ruby or HTML5 ruby?
The Ruby Annotation (XHTML Ruby) spec will be replaced by (X)HTML5.
- XHTML simple ruby
-
<ruby><rb>漢字</rb><rp>(</rp><rt>かんじ</rt><rp>)</rp></ruby>
- XHTML5 ruby
-
<ruby>漢<rt>かん</rt>字<rt>じ</rt></ruby>
A transitional solution:
- The content author use (conventional) XHTML simple ruby in marking-up.
- On the other, the viewer developer must support both XHTML simple ruby and HTML5 ruby in their products.