From W3C Wiki
Jump to: navigation, search

< Change Proposal Index

Conditional styling and processing based on UA conditions - CLOSED-IMPLEMENTED

  • Owner: Glenn Adams.
  • Started: 14/06/13

Issues Addressed


The profile mechanism introduced in TTML 1.0 has been widely misunderstood, due probably in part because of its unfortunate naming. It was never intended, and does not function as a player profiling mechanism, but rather as a conditional mechanism similar to that afforded by @supports and @media in CSS.

[GA] There is a subtle distinction between defining what support must be required by a player and a general profile of a player. It is sufficiently subtle that it is difficult to distinguish the two. In my mind, the profiling of players (processors) is the same thing as defining a set of features that must be supported by those processors. So I would have to disagree with the above characterization by [SH].

This work package would extend the conditional aspect of the profiling mechanism so that it is clearer that is about what parts of the document get processed, improve the mechanism whereby the profiles are combined together to allow content that can be adaptable to a wider range of conditions, for example one specific issue that has been raised is the importance of authoring one piece of content that adapts appropriately to a 16 by 9 aspect ratio as well as a 4 by 3 aspect ratio.

[GA] The existing profiling mechanism has never been used as a means for conditionally including or excluding parts of a document. Its goal (in TTML1) was to make a GO or NO-GO decision about processing a document at all. In contrast, a conditionalization mechanism operates at a much finer granularity, allowing the inclusion/exclusion of document fragments (from a semantic perspective).

Outline of Requirements

Assume an author wishes to create content that takes advantage of smooth animation and adjusts appropriately to a 16 by 9 layout.

A possible solution might look like:

  <ttp:profile id ="smoothAnimation">

  <ttp:profile id ="baseprofile">

    <style id="s4x3" where="supports(*) and media(min-width: 1.332vh and max-width: 1.334vh)"/>
    <style id="s16x9" where="supports(*) and media(min-width: 1.778vh and max-width: 1.776vh)" />
    <style id="stylebase" style="s16x9 s4x3" />
    <region style="stylebase">

  <body where="supports(smoothAnimation or baseprofile)">
    <div where="supports(smoothAnimation)">
   <div where="supports(not smoothAnimation)">

Key features:

  • profiles should be named using an id (this is present in TTML 1.0)

[GA] not relevant to drafted conditionalization support.

  • a profile should be referenceable in a conditional (e.g. @where attribute), so that the adorned element can only become active if the conditionalis satisifed

[GA] The drafted condition mechanism defines a supports() condition function that takes a single feature or extension designator. As such, it is independent of profile specifications, but instead, conditionalizes at a fine grained level on support for a specific feature/extension.

  • styles can be guarded with a @where attribute too, the inline and referenced styles are only added to a computed style set if the where clause is satisfied

[GA] supported, since all core vocabulary elements can be conditionalized.

  • The conditional would support referencing one or more profile ids in a boolean phrase, and a media component which contains a media query.

[GA] There is no need to reference a profile ID, given the drafted supports() condition function. An additional media() condition function is also included that takes a MQ argument.

Since style reference is cumulative and proceeds left to right, in the above example a 1.0 processor would simply overwrite the 16 x 9 settings with the 4x3 ones However a media aware processor would not add the 4x3 settings and so the 16x9 ones would remain active.

On a TTML 1.0 processor the body element essentially behaves as if the @where attribute ands together all of the profiles given in the head, and thus will not render anything for this content.

Edits to be applied

Edits applied

Define new generic 'condition' attribute. See [2].


  • Forward compatibility