W3C home > Mailing lists > Public > public-tt@w3.org > December 2016

Re: Subtitle/caption styling + TTML + CSS

From: Pierre-Anthony Lemieux <pal@sandflow.com>
Date: Mon, 12 Dec 2016 17:11:21 -0800
Message-ID: <CAF_7JxCpLMWj6z9AvW45=NW_1n9o_d0Cq4qSLpqyxwX5ihbhyw@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: "public-tt@w3.org" <public-tt@w3.org>
Hi Glenn,

> since both of the examples you give, multiRowAlign and linePadding
>are in fact supported (semantically) by CSS.

I am not so sure.

>display: inline-block on span to obtain multiRowAlign semantics

I have not found a way to make this work without explicit <br>
elements -- see [1].

[1] https://codepen.io/palemieux/pen/yVxZWm

>use box-decoration-break: clone to obtain linePadding semantics.

I have not found a way to make this work if nested spans are used --
see [2] for HTML and attached for TTML. Specifically, linePadding
requires that the background of the first/last character of each line
be extended.

- "box-decoration-break: clone" extends the background of the <span>
at the end of each line, so the background of both outer and inner
spans are extended.

- CSS padding adds padding to both left and right of a span,
introducing additional spaces in the text

[2] https://codepen.io/palemieux/pen/vyzbqW

Perhaps you see another way. I would love to be proven wrong!

Best,

-- Pierre

On Mon, Dec 12, 2016 at 4:12 PM, Glenn Adams <glenn@skynav.com> wrote:
> You are likely to receive pushback on your email, since both of the examples
> you give, multiRowAlign and linePadding, are in fact supported
> (semantically) by CSS.
>
> Use display: inline-block on span to obtain multiRowAlign semantics and use
> box-decoration-break: clone to obtain linePadding semantics.
>
> As far as I know, none of TTML1 or IMSC1 presentation semantics is not
> supported by some CSS mapping (whether simple or complex), but that doesn't
> hold for TTML2, where there are indeed some semantic gaps in CSS.
>
> On Mon, Dec 12, 2016 at 3:21 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
>>
>> FYI. My input to the www-style list re: TTML and CSS.
>>
>> Best,
>>
>> -- Pierre
>>
>>
>> ---------- Forwarded message ----------
>> From: Pierre-Anthony Lemieux <pal@sandflow.com>
>> Date: Sun, Dec 11, 2016 at 9:04 PM
>> Subject: Subtitle/caption styling + TTML + CSS
>> To: "L. David Baron" <dbaron@dbaron.org>
>> Cc: Thierry MICHEL <tmichel@w3.org>, Bert Bos <bert@w3.org>, Chris
>> Lilley <chris@w3.org>, www-style list <www-style@w3.org>, Nigel Megitt
>> <nigel.megitt@bbc.co.uk>
>>
>>
>> Hi David et al.,
>>
>> > I don't think TTML1 was designed in a
>> > way that would fit well in browser implementations.
>>
>> I have been working on an open source JavaScript library [1] for
>> rendering TTML1 documents to HTML5 fragments.
>>
>> [1] https://github.com/sandflow/imscJS
>>
>> TTML is based on XSL, which is based on CSS, and so the mapping has
>> been straightforward. [ed.: I am not sure what you mean by "does not
>> fit well", perhaps you can elaborate.]
>>
>> The most significant challenge has been supporting two features
>> (linePadding and multiRowAlign [2]), which are not supported in CSS,
>> but have been identified as essential to captioning in Europe by the
>> TTWG (and EBU).
>>
>> [2] https://www.w3.org/TR/ttml-imsc1/#linepadding
>>
>> I would think that features that are important to
>> subtitling/captioning should be considered for CSS, regardless of the
>> ultimate timed text format (TTML, WebVTT, etc...)
>>
>> Best,
>>
>> -- Pierre
>>
>> On Wed, Nov 23, 2016 at 3:33 PM, L. David Baron <dbaron@dbaron.org> wrote:
>> > On Friday 2016-11-18 17:48 +0100, Thierry MICHEL wrote:
>> >> CSS colleagues,
>> >>
>> >> The Timed Text Working Group (TTWG) published yesterday an ordinary
>> >> Working
>> >> Draft of Timed Text Markup Language 2 (TTML2)
>> >> W3C Working Draft 17 November 2016
>> >> https://www.w3.org/TR/2016/WD-ttml2-20161117/
>> >>
>> >> FYI, this publication is not the last publication before requesting
>> >> transition to Candidate Recommendation. The TTWG plans to publish a
>> >> final WD
>> >> soon. We will let you know.
>> >>
>> >> Meanwhile, the TTWG invites you to review this TTML2 WD.
>> >>
>> >> The horizontal review should focus only on the new features
>> >> introduced in TTML2.
>> >> Please refer to the section for changes between Timed Text Markup
>> >> Language
>> >> (TTML) Version 1 (TTML1) and Version 2 (TTML2).
>> >>
>> >> https://www.w3.org/TR/2016/WD-ttml2-20161117/#changes-from-ttml1-vocabulary
>> >>
>> >> Please send your comments to  TTWG Public mailing list
>> >> <public-tt@w3.org>.
>> >
>> > So it's worth noting that the styling section of the draft:
>> >   https://w3c.github.io/ttml2/spec/ttml2.html#styling
>> > has considerable new additions relative to TTML1.  This section
>> > contains a vocabulary that is rather similar to many CSS properties,
>> > but also contains significant divergence.
>> >
>> > In particular, TTML1 had in
>> > https://www.w3.org/TR/ttaf1-dfxp/#styling-attribute-vocabulary
>> > the following styling attributes that appear to match CSS at first
>> > glance, at least in semantics:
>> >   backgroundColor
>> >   color
>> >   direction
>> >   display (only auto vs. none)
>> >   extent (a shorthand for width and height)
>> >   fontFamily
>> >   fontSize
>> >   fontStyle
>> >   fontWeight
>> >   lineHeight
>> >   opacity
>> >   overflow
>> >   padding
>> >   textAlign
>> >   textDecoration (but with extra values)
>> >   unicodeBidi
>> >   visibility
>> >   wrapOption (like text-wrap in css-text-4)
>> >   writingMode (but using old values)
>> >   zIndex
>> > and the following styling attributes that do not match CSS:
>> >   displayAlign
>> >   origin (a bit like x and y in SVG)
>> >   showBackground
>> >   textOutline
>> >
>> > TTML2 introduces the following new properties that appear to have
>> > similar CSS properties at first glance:
>> >   backgroundClip (with different names for the values)
>> >   backgroundExtent (equivalent to background-size)
>> >   backgroundImage
>> >   backgroundOrigin (with different names for the values)
>> >   backgroundPosition
>> >   backgroundRepeat
>> >   border (with border-radius included in the property)
>> >   bpd (equivalent to block-size in css-logical-properties)
>> >   fontKerning (though without CSS's initial value, which is auto!)
>> >   ipd (equivalent to inline-size in css-logical-properties)
>> >   letterSpacing
>> >   ruby (this is done using the display property in CSS)
>> >   rubyAlign (with additional auto, end, and withBase values)
>> >   rubyPosition (with before/after names instead of over/under)
>> >   textCombine (equivalent to CSS text-combine-horizontal)
>> >   textEmphasis
>> >   textOrientation (but retaining the sidewaysLeft and sidewaysRight
>> >     values that CSS removed)
>> >   textShadow
>> > and the following that appear not to have corresponding CSS properties:
>> >   disparity
>> >   fontSelectionStrategy
>> >   fontShear
>> >   fontVariant (this is a property name used in CSS, but with a
>> >     different meaning!)
>> >   position (this is a property name used in CSS, but with a
>> >     different value, "center", although one that has been proposed
>> >     to be added to the CSS property)
>> >   rubyOffset
>> >   rubyOverflow
>> >   rubyOverhang
>> >   rubyOverhangClass
>> >   rubyReserve
>> >
>> >
>> > My opinion on this is that this seems like a lot of divergence from
>> > CSS.  It's divergence in naming (using different names for the same
>> > thing and the same names for different things), divergence in value
>> > spaces, and given that everything is redefined in the TTML spec
>> > (although often non-normatively "based on" CSS specs), almost
>> > certainly massive divergence in semantics.
>> >
>> > I think TTML and CSS have largely been implemented in separate
>> > implementations (which means that TTML has largely not been
>> > implemented in browsers), and I don't think TTML1 was designed in a
>> > way that would fit well in browser implementations.  That's why
>> > browsers implemented WebVTT instead.  I think continuing to diverge
>> > from CSS to this degree simply makes TTML implementation in browsers
>> > even less likely than it already was (which was already unlikely).
>> >
>> > On the flip side, I don't think fixing that divergence is
>> > particularly valuable (at least to browsers) since the communities
>> > are already separate, and I think the chance of getting substantial
>> > TTML implementation in browsers is low even without additional
>> > divergence.
>> >
>> > -David
>> >
>> > --
>> > 𝄞   L. David Baron                         http://dbaron.org/   𝄂
>> > 𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>> >              Before I built a wall I'd ask to know
>> >              What I was walling in or walling out,
>> >              And to whom I was like to give offense.
>> >                - Robert Frost, Mending Wall (1914)
>>
>

Received on Tuesday, 13 December 2016 01:12:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:44:04 UTC