Re: Subtitle/caption styling + TTML + CSS

On looking at your first example [1] a little more, I am wondering whey the
inline block is not centered, since there is obviously space available to
distribute equally on both sides, but for some reason it is distributing
all the excess space on the left side of the inline block in contradiction
to the text-align: center on the paragraph.

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

On Mon, Dec 12, 2016 at 6:11 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> 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)
> >>
> >
>