Style.CSS - OPEN
- 1 Style.CSS - OPEN
- 2 Issues Addressed
- 3 Summary and Change details
- 3.1 margin
- 3.2 padding
- 3.3 box-decoration-break
- 3.4 border
- 3.5 line stacking strategy
- 3.6 region anchor points
- 3.7 text outline
- 3.8 text shadow
- 3.9 shrink fit
- 3.10 font face rule
- 3.11 multiple row alignment (flex box in CSS mapping)
- 3.12 superscript and subscript (font-variant-position in CSS mapping)
- 4 Dependencies on other packages
- 5 Edits to be applied
- 6 Edits applied
- 7 Impact
- 8 References
- ISSUE-20 - Region border - Closed - .
- ISSUE-21 - Region anchor - Open.
- ISSUE-24 - Subscript and superscript - Pending Review - .
- ISSUE-168 - Content padding - Closed - .
- ISSUE-176 - Inline region - Closed - .
- ISSUE-193 - Character edges - Closed - No Action.
- ISSUE-209 - Line stacking strategy - Closed - .
- ISSUE-213 - Deprecate tts:textOutline - Open.
- ISSUE-234 - Drop shadow - Open.
- ISSUE-235 - Feathering (blur) shadow - Open.
- ISSUE-273 - External font mapping - Open.
- ISSUE-284 - Value of line height - Open.
- ISSUE-285 - Multiple row align - Open.
- ISSUE-286 - Line (row) padding - Open.
Summary and Change details
TTML 1.0 did not adopt a number of properties that have subsequently been found to important.
the margin property was omitted since it was felt that positioning could generally be made explicit using origin and extent, however a common practice in television content is to indent the second and subsequent lines in a multi line caption. This is hard to replicate in TTML 1.0, as it requires explicit positioning of two relative lines, and only regions may be positioned. It can be approximated by using explicit space characters and xml:space preserve, however this is an inaccurate and not a very elegant solution.
This change proposal adds the margin property as a style properties admissible on block level and inline elements.
The padding property was omitted on all elements except the region. This leads to ugly captions if the only opaque background is in the spans.
This change proposal adds the padding property as a style properties admissible on block level and inline elements.
[GA] Implemented in https://dvcs.w3.org/hg/ttml/rev/edf3344d2924.
This is ISSUE-286.
Padding can be applied to text in a span to improve readability when text is displayed over a background colour. However if a line break is inserted because the text doesn't fit on a single line the padding does not apply. This change proposal adds the box-decoration-break property to allow the padding to apply at line breaks.
- tight alignment of background area with text can be hard to read
Left and right padding
- padding on left and right makes it easier
Left and right padding
broken across a line
- but in the simple form doesn't apply across line breaks
Left and right padding
broken across a line with decoration=clone
- "box-decoration-break: clone" is intended to solve this problem
- NB this last example is a mock-up only because
box-decoration-break: cloneis not supported on all browsers
Note that EBU-TT-D specifies a syntax for this behaviour as a style attribute,
ebutts:linePadding that takes a single length parameter and applies it as inline-progression padding on either end of each wrapped line, i.e. roughly equivalent to specifying start and end padding on a
box-decoration-break: clone. This prior work should be taken as a starting point for developing a syntax in TTML2, which ideally will be a superset of (or identical to) the EBU-TT-D syntax.
tts:linePadding applies to block-level elements
tt:p. Has no effect when declared solely on a
Value permitted is a single
<length>. Percentages are relative to the width of the region. Length values must be zero or positive.
Every line area created to contain the text contained in a paragraph with a non-zero
linePadding will be inset at the start and end by the specified length. The background color at the start and end of each line will be extended into this inset space.
PAL: Are TTML 1 processors expected to ignore TTML 2 attributes that are in the same namespace at TTML 1? Is this the case in practice?
tts:linePadding style is illustrated by the following example:
<p tts:color="white" tts:linePadding="0.5em"> <span tts:backgroundColor="black"> Left and right padding broken across a line </span> </p>
Use of linePadding results in the properties
box-decoration-break: clone being set on a span around the text, with an anonymous span being introduced if necessary. The previous example thus results in the following example code when mapped to HTML5/CSS:
<p style="color: white;"> <span style="background-color: black; padding-left: 0.5em; padding-right: 0.5em; box-decoration-break: clone;"> Left and right padding broken across a line </span> </p>
This produces an output similar to:
Left and right padding
broken across a line
NB the wiki source for this example differs from the mapping provided above because browser support for
box-decoration-break: clone is not yet available
the border property was omitted, as it was felt that a similar effect could be achieved with the padding applied to regions allowinf the background colour to be visible
This however fails to replicate some effects achievable in 708 window styles.
This change proposal adds the border property as a style properties admissible on region elements.
[GA] Implemented in https://dvcs.w3.org/hg/ttml/rev/9b0f69325bde.
line stacking strategy
the line stacking strategy property was omitted for simplicity, and the XSL:FO default was assumed, this however is a barrier to mapping the style properties onto CSS, as this is felt to be a larger use case today than when TTML 1.0 was designed, the line stacking property is added. A ttp:parameter can be used to set the appropriate default for this property to override the default. Thus content authored to TTML 1.0 will retain the original stacking semantics, new content has the option of setting the default to that of CSS.
This change proposal reintroduces the line stacking strategy property as a style properties admissible on block level elements.
region anchor points
TTML 1.0 has a single anchor point for regions (namely the top left corner). This suffices for content where the size is known ahead of time, however very often content is required that may have a variable width or height (so called shrink-to-fit) layouts. In such a case it is not possible with any degree of accuracy to create center, bottom or right aligned regions.
This proposal allows the author greater control to define the anchor point on the region by extending the extent attribute to allow two optional additional values to represent 'right' and 'bottom', and to allow both the origin attribute and extent attributes to admit 'auto' as a value. The default will be 0, 0 thus old content will continue to work as before, but new content will be able to take advantage of the new styles.
For example, a region centered around the 50% vertical, which is 90% of the screen width and 20% of the screen height and placed flush on the bottom screen edge:
<region tts:origin="5% auto" tts:extent="auto 20% 5% 0%"
At the time TTML 1.0 was authored, the CSSWG was working on an outline property. This property was never finished, and has since been dropped. A similar effect can be approximated using the text-shadow property. Such an effect is important to reproduce TV content. Thus this change proposal re-defines the text outline property in terms of the text shadow property which is also added (see below).
See above for rationale. In addition the text-shadow property may be used to create the text raised and lowered effects as well as drop shadows and feathering asked for by SMPTE and the FCC regulations for internet delivered TV. Thus this change proposal adds the text shadow property.
It is sometimes adventageous to be able to define regions such that their width and height is not determined in advance, but is determined instead by the length of the longest natural linebox created by the content. This change proposal allows the values auto to be used in the extent property to achieve this.
font face rule
This is ISSUE-273
In order to present a document as intended when the document was authored some shared knowledge of the fonts that will be used to render is advantageous. It would reduce the likelihood that rendered text will not fit within the allocated region, and increase the likelihood that the font will be displayed as intended. Another use case is to ensure that all the glyphs required are present: an author may wish to provide a reference to a font resource that is known to include those glyphs. The CSS3 mechanism to provide access to downloadable font resources, which can then be referenced by tts:fontFamily is the @font-face rule. This change proposal allows multiple font-face to be used in the <styling> element to achieve this.
Example TTML (suggested syntax - for review):
<styling> <fontFace fontFamilyName="myNiceFont"> <fontFaceSource fontFaceUrl="myNiceFont.woff" fontFaceFormat="woff"> <fontFaceSource fontFaceUrl="myNiceFont.ttf" fontFaceFormat="opentype"> </fontFace> <style id="s1" tts:fontFamily="myNiceFont"/> </styling> </styling>
multiple row alignment (flex box in CSS mapping)
This is ISSUE-285
A common captioning presentation style requires the alignment of displayed rows of text relative to each other, and alignment of the set relative to a region. This can be achieved using the flex property in CSS.
For example (when mapped to HTML/CSS):
<div style="display: flex; justify-content: center; width: 75%;"> <p style="text-align: left;"> Beware the Jubjub bird, and shun<br/> The frumious Bandersnatch! </p> </div>
This example renders as:
The above example would be expressed in EBU-TT (omitting irrelevant bits) as:
<styling> <style id="s2" textAlign="center" ebutts:multiRowAlign="start"/> </styling> ... <body> <div> <p style="s2"> <span>Beware the Jubjub bird, and shun<br/>The frumious Bandersnatch!</span></p> ...
The mapping of
multiRowAlign to the
justify-content property applied to a HTML
div with the
display property set to
superscript and subscript (font-variant-position in CSS mapping)
This is ISSUE-24
Dependencies on other packages
As the effects that the new properties allow are not in general achievable using TTML 1.0 properties authors are potentially faced with a dilemma in creating content which will work adequately on older processors while still taking advantage of the new properties. The Conditional Styling proposal will allow graceful forward compatibility to the extent possible.
Edits to be applied
- Simplifies conversion from 608 and 708 content.
- Fixes incompatibilities with CSS
- Allows greater control of margins within a paragraph.
- Allows more flexible content to be authored
- Allows greater control of rendered appearance of text