- From: Glenn Adams <glenn@skynav.com>
- Date: Fri, 16 Jan 2015 07:18:08 -0700
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <CACQ=j+eMbarCt-btkw0ZMRhD9htRWZfdv5ELpm7pFmUKV7Tq8w@mail.gmail.com>
On Fri, Jan 16, 2015 at 2:52 AM, Timed Text Working Group Issue Tracker < sysbot+tracker@w3.org> wrote: > ISSUE-366 (condition vs xml:id): xml:id uniqueness needs to be broken for > some uses of condition [TTML2] > > http://www.w3.org/AudioVideo/TT/tracker/issues/366 > > Raised by: Nigel Megitt > On product: TTML2 > > Consider the use case in which an author wishes to permit the viewer of a > TTML2 document to select from one of a number of style choices, either > depending on a parameter or a media query, for example choices that vary > tts:fontSize and tts:extent to accommodate 'normal size font', 'large size > font' and 'small size font' options. > > > The condition attribute can only be used to omit an element from semantic > processing, not to change its behaviour. One might imagine that the > following is a way to proceed: > > ... > <layout> > <region xml:id="r1" condition="parameter(text_size)=='large size font'" > tts:extent="95vw 30vh" .../> > <region xml:id="r1" condition="parameter(text_size)=='normal size font'" > tts:extent="80vw 20vh" .../> > <region xml:id="r1" condition="parameter(text_size)=='small size font'" > tts:extent="60vw 15vh" .../> > </layout> > <styling> > <style xml:id="sFontSize" condition="parameter(text_size)=='large size > font'" tts:fontSize="15vh"/> > <style xml:id="sFontSize" condition="parameter(text_size)=='normal size > font'" tts:fontSize="10vh"/> > <style xml:id="sFontSize" condition="parameter(text_size)=='small size > font'" tts:fontSize="7.5vh"/> > <style xml:id="sDefaultFont" style="sFontSize" > tts:fontFamily="myFontFamily"/> > </styling> > > ... > > <body> > <div region="r1" style="sDefaultFont"> > ... > </div> > </body> > Condition is not intended to be used like #ifdef | #ifndef, i.e., as a syntactic inclusion/exclusion system, but as semantic inclusion/exclusion only. There are perfectly good alternatives to the above that do not require duplicating ids, such as: <styling> <style xml:id="s0" tts:fontFamily="myFontFamily"/> <style xml:id="s1" condition="parameter(text_size)=='large size font'" tts:fontSize="15vh" tts:extent="95vw 30vh"/> <style xml:id="s2" condition="parameter(text_size)=='normal size font'" tts:fontSize="10vh" tts:extent="80vw 20vh"/> <style xml:id="s3" condition="parameter(text_size)=='small size font'" tts:fontSize="7.5vh" tts:extent="60vw 15vh"/> </styling> <layout> <region xml:id="r1" style="s0 s1 s2 s3"/> </layout> > > However this construct, which requires use of xml:id for style and region > reference, breaks xml:id uniqueness rules, resulting in invalid documents. > What options are there for achieving this use case? I can see: > > a) repeating all the content in the document with different style and > region references and specifying condition only on the content, > > b) basing everything on the initial element and making that conditional > (since nothing needs to refer to initial by xml:id), and specifying all > regions inline - unfortunately this may be very verbose in terms of > repeating regions on many content elements, but it could work for cases > where there are only a few regions and they can be associated with body or > div elements. > > Neither of these two options is particularly attractive - a) is highly > repetitious and offers no advantage over the provision of multiple > documents with any associated costs for asset management and distribution > there. b) is limited in basing style on initial so it is a 'one chance' > condition, and it is potentially repetitious in region definition. > > > By the way, there are at least three audience groups for which this use > case exists: 1) Those who have reading difficulties with normal size text; > 2) users of different devices, where it has been established that text > needs to be rendered at different sizes on large screen televisions from > smartphones for example; 3) those who just want to be able to customise the > display. > > > It would be great if the condition construct could be used to allow some > predefined viewing options to be authored into the document, i.e. in a > controlled way by the document author. I can't see how this can be achieved > at present though. > > > What solution choices are there? Perhaps the easiest is to redefine the > condition construct so that it also includes an 'if then else if' syntax in > which attributes can be defined, so you might end up with, for example: > > <region xml:id="r1" condition="if parameter(text_size)=='large size font' > then (tts:extent='95vw 30vh' elseif parameter(text_size)='normal size font' > then (tts:extent='80vw 20vh') elseif parameter(text_size)='small size font' > then (tts:extent='60vw 15vh') else (tts:extent='80vw 20vh')"/> > > Then xml:id rules are not broken and region r1 can be referenced safely > with the attribute evaluation only being conditional. I'd advocate > retaining the ability to specify a condition that can be used to exclude > the entire element from semantic processing, as now. > > > Another solution to this problem might be to define some preprocessing > using XPath to select specific elements and/or attributes and set values on > the basis of the same condition functions that have already been specified, > i.e. parameter, media, supports. Something like: > > <tt:tt [parameters etc]> > <preprocess> > <rule condition="parameter(text_size)=='large size text'" > path="//region[@xml:id='r1']"> > <attributes tts:extent="95vw 30vh"> > </rule> > </preprocess> > <head> > <layout><region xml:id="r1"/></layout> > ... > > It would be an error for a path attribute to refer to anywhere except > <head> or <body> or their descendants. > > This option would also have the incidental effect that it would provide > similar functionality to declarative styling. All the rules would be > executed in document order prior to processing the <head>. Preprocessing > could of course also be performed externally to the document before > processing, if a 'user style' is desirable (as is the case for any XML > document) . > > > >
Received on Friday, 16 January 2015 14:18:56 UTC