- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 12 Dec 2016 18:55:23 -0700
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- Cc: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <CACQ=j+faJLiD_EedENzKZk3St3MM3s9dQ6ZYZf0Ju9kAJ6_hVA@mail.gmail.com>
On Mon, Dec 12, 2016 at 6:43 PM, Pierre-Anthony Lemieux <pal@sandflow.com> wrote: > > have you tried a combination of {min,max}-width on the span > > No. How would it work? > for example, you might specify min-width: 50% and max-width: 80% to ensure that length of lines in the inline-block are more balanced (in length); i haven't actually tried this, but it sounds like it should work > > > you probably should include references to these examples in your message > to CSS; let's see what input they might have > > Ok. > > On Mon, Dec 12, 2016 at 5:26 PM, Glenn Adams <glenn@skynav.com> wrote: > > > > > > 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:56:19 UTC