- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 12 Dec 2016 18:26:25 -0700
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- Cc: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <CACQ=j+cGDjZf3-eWKGXCmNEkzWrC7AEBtWk4z-hVh5kzTA+xqg@mail.gmail.com>
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
have you tried a combination of {min,max}-width on the span
>
>
> >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!
>
hmm, you may have a counterexample here
you probably should include references to these examples in your message to
CSS; let's see what input they might have
>
> 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:27:21 UTC