Style.CSS - OPEN
- 1 Style.CSS - OPEN
- 2 Issues Addressed
- 3 Summary and Change details
- 3.1 margin
- 3.2 padding
- 3.3 line (row) padding
- 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 - Pending Review - , .
- ISSUE-24 - Subscript and superscript - Closed - .
- 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 - Pending Review - No Action.
- ISSUE-234 - Drop shadow - Open.
- ISSUE-235 - Feathering (blur) shadow - Open.
- ISSUE-273 - External font mapping - Pending Review - .
- ISSUE-284 - Value of line height - Open.
- ISSUE-285 - Multiple row align - Pending Review - .
- ISSUE-286 - Line (row) padding - Pending Review - .
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.
[GA] Above description appears to describe hanging indent, not margin. WebVTT doesn't have margin, not sure that use case is adequately motivated. Propose WONTFIX as resolution for time being until a better motivated use case is document and an issue is raised.
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.
line (row) padding
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.
[GA] Simple solution: simply define padding on inline elements to use cloned padding at line breaks, i.e., as if box-decoration-break: clone applied. Since padding on content wasn't supported in TTML1, this does not produce a backward compatibility problem.
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, which are raised, depressed, uniform, and drop shadow.
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. This resolution supports the 'border' property on region *and* all content element types except br. However, it does so by using the shorthand version of the property which simultaneously to all edges.
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.
[GA] Propose no action at this time, but re-review for certainty.
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%"
[GA] Add tts:position property for use on root (tt) and other region defining elements, as an alternative way to express position by anchoring to a specific point or from an edge. Add tts:width,height which accepts fitContent value (as well as minContent, maxContent, available, etc) for use on div, p, span, and image, thus supporting shrink fit. Upgrade tts:extent to accept measure expression to do same on regions.
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).
[GA] Review and determine if textOutline can have its syntax/semantics enlarged to include the semantics of text-shadow. Do not eliminate textOutline for backward compat reasons.
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.
[GA] Add tts:width,height which accepts fitContent value (as well as minContent, maxContent, available, etc) for use on div, p, span, and image, thus supporting shrink fit. Upgrade tts:extent to accept measure expression to do same on regions.
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.
[GA] Add font element definition, though different in syntactic details from the following.
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>
EBU-TT proposal (advisory, under discussion, not formally proposed to TTWG yet)
[Update]: this proposal is in flux - it is likely that a data structure closer to the CSS @font-face rule and to the ARIB-TT structure will be proposed in place.
An alternative syntax has been proposed for EBU-TT, including fontWeight, fontStyle and fontUnicodeRange to allow for more granularity:
<fontFace fontFamilyName="Tiresias"> <fontFaceSource uri="http://typo.com/tiresias-bold" fontWeight="bold"/> <fontFaceSource uri="http://typo.com/tiresias-italic" fontStyle="italic"/> <fontFaceSource uri=”http://typo.com/tiresias-euro” fontUnicodeRange =”U+20AC“/> <fontFaceSource uti="http://typo.com/tiresias"/> </fontFace>
The elements are:
- Content: 1 or more
fontFace element has a single required attribute.
<familyName> | <genericFamilyName>
- Description: this is used to match the tts:fontFamily attribute value with this element.
fontFace element has a required child element.
- Child of
- Content: none
- Description: The fontFaceSource element allows the author to identify a resource for a font used during authoring text for a particular fontFamily.
fontFaceSource element has a single required attribute.
- Description: this is used to specify a location for the referenced fontFace.
fontFaceSource element has three optional attributes.
- Description: this is used to qualify the referenced fontFace as specific for text that has bold styling applied.
- Description: this is used to qualify the referenced fontFace as specific for text that has italic styling applied.
xs:string(The value is a comma-delimited list of Unicode range (<urange>) values. Each <urange> value is a UNICODE-RANGE token made up of a "U+" or "u+" prefix followed by a codepoint value as either: a single decimal codepoint (e.g. U+416) represented as one to six hexadecimal digits; or an interval range (e.g. U+400-4ff) represented as two hyphen-separated Unicode codepoints indicating the inclusive start and end codepoints of a range. Note: Multiple single codepoints and ranges may occur within the fontUnicodeRange value.)
- Description: this defines the set of Unicode codepoints that may be referenced from the fontFaceSource for which it is declared. If this attribute is absent then all codepoints may be (attempted to be) referenced from the fontFaceSource. If this attribute is present then, if a codepoint in text content falls within the range(s) of Unicode codepoints specified, then glyphs from the referenced source URI may be used as reference when processing the document.
fontFaceSource child elements must be interpreted as follows. A
fontFaceSource element with
fontUnicodeRange qualifying attributes should be used as a reference for a specific
fontFamily if the codepoints (and applied styling) of any text within the document match the
fontUnicodeRange qualification and any other specified qualifying attributes on this
fontFaceSource element. If multiple
fontFaceSource child elements match a given codepoint by
fontUnicodeRange qualification, then any additional qualifying attributes are examined and the
fontFaceSource child element with the closest matching qualifying attributes is used as reference, or in the event of multiple matches, the first declared
fontFaceSource child element is used as a reference. Closeness is defined using in decreasing order of precedence 1) a unicode range match 2) count(matches([fontWeight, fontStyle])) 3) document order (earlier is preferred).
<fontFace fontFamilyName=”Tiresias”> <fontFaceSource uri=”http://typo.com/tiresias”/> !- Would match a NON bold and NON italic Euro symbol < fontFaceSource uri=”http://typo.com/tiresias-euro-bold” fontWeight =”bold” fontUnicodeRange =”U+20AC“/> !- Would match a bold Euro symbol < fontFaceSource uri=”http://typo.com/tiresias-euro-italic” fontStyle =”italic” fontUnicodeRange =”U+20AC“/> !- Would match an italic Euro symbol < fontFaceSource uri=”http://typo.com/tiresias-bold” fontWeight =”bold” /> < fontFaceSource uri=”http://typo.com/tiresias-italic” fontStyle =”italic” /> </fontFace>
<fontFace fontFamilyName=”Tiresias”> < fontFaceSource uri=”http://typo.com/tiresias”/> !- Would match all codepoints except between 2000-20FF < fontFaceSource uri=”http://typo.com/tiresias-range1” fontUnicodeRange =”U+2000-20FF“/> !- Would match all codepoints between 2000-20FF except italics (this should be used for bold!) < fontFaceSource uri=”http://typo.com/tiresias- range1-italic” fontStyle =”italic” fontUnicodeRange =”U+2000-20FF“/> !- Would match all italics codepoints between 2000-20FF < fontFaceSource uri=”http://typo.com/tiresias-bold” fontWeight =”bold”/> !- Would match all bold codepoints except between 2000-20FF < fontFaceSource uri=”http://typo.com/tiresias-italic” fontStyle =”italic”/> !- Would match all italic codepoints except between 2000-20FF </fontFace>
The ARIB-TT format (PDF) also defines an element
font-face element of type
This is defined as:
<xsd:element name="font-face" type="arib:font-faceType"/> <xsd:complexType name="font-faceType"> <xsd:sequence> <xsd:element name="src" type="arib:font-face-srcType" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="font-family" type="xsd:string" use="required"/> <xsd:attribute name="unicode-range” type="xsd:string"/> <xsd:attribute name="id" type="xsd:ID"/> </xsd:complexType> <xsd:complexType name="font-face-srcType"> <xsd:attribute name="url" type="xsd:anyURI" use="required"/> <xsd:attribute name="format" type="xsd:string"/> <xsd:attribute name="id" type="xsd:ID"/> </xsd:complexType>
- translate the accompanying prose into English (at least for English readers!)
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
[GA] Allow tts:textAlign on span which causes it to use inline-block display formatting semantics, thus supporting a distinct alignment from outer paragraph block.
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