Minutes of joint meeting between CSS WG and TTWG 10th November 2017

Dear CSS WG,

Thank you to all who were able to attend the joint face to face meeting with TTWG at TPAC. Minutes are available in HTML format at: https://www.w3.org/2017/11/09-tt-minutes.html#item35

Relevant extract of those minutes in text format:


CSS WG and TTWG joint meeting

   nigel: Some quick introductions:
   ... Nigel Megitt, chair TTWG

   pal: Pierre Lemieux, Movielabs

   <cyril> Cyril Concolato, Netflix

   <tmichel> Thierry Michel, W3C

   <florian> Florian Rivoal, CSS-WG, Vivliostyle

   <wdh> wdh: Bill Hofmann, Dolby Labs, observer

   astearns: Alan Stearns, co-Chair CSS WG

   <ericc> Eric Carlson, Apple

   <Guest41> Chris Flick, Apple

   <Guest41> nick /flick

   fantasai: Elika Etemad, invited expert, editor of half the CSS
   WG's specs

   rossen: Co-chair of CSS WG, Microsoft

   hober: Theresa O'Connor, Apple

   nigel: High level picture is: how do we work together to get
   the styling features needed
   ... for captions and subtitles into CSS where there are gaps?

   florian: Not sure of the history here but it seems dangerous to
   map from TTML to CSS
   ... because if there are differences in semantics then it will
   be hard to identify.
   ... If the differences are subtle then it was not worth doing.
   If they are big then it is bad
   ... because there isn't a mapping.
   ... We need to work with you to look at the use cases we have
   and work out what is missing
   ... and add to CSS. From there we want to see is how you simply
   invoke CSS rather than
   ... define something close and map it. As long as TTML keeps
   defining something similar
   ... but not the same then we will have ongoing difficulties.
   Maybe in TTML3 just describe
   ... the minimal CSS properties and define the layout. I don't
   know how you get there but
   ... for the CSS side we need to work from use cases and look at
   where it's not adequate
   ... and go from there.

   pal: Emphasise that this is not about TTML, in terms of
   requirements, it is about subtitles
   ... and captions, and it can be used for example in WebVTT. The
   delta is for how we
   ... present subtitles and captions on the web.

   glenn: Agree with Pierre to focus on the bigger picture.
   ... In 2003 we adopted a policy of using camel casing so any
   CSS names we've taken have
   ... already changed so we can't back out of that.

   fantasai: I don't think we care about that.

   glenn: To the extent that we've pulled in CSS we've tried to do
   it without changing semantics
   ... but there are some edge cases where we've clarified and had
   to go beyond CSS. We want
   ... to minimise any differences. What florian said is true in
   the ideal world but we have
   ... practical constraints too such as timing.

   pal: This is not the topic today! The main question is about
   gap filling.

   nigel: I think there's recognition in TTWG that there may be
   input we can provide.

   florian: Concern about augmenting CSS - at some point it's
   possible that CSS will add
   ... something and it won't work for TTML because it went a
   different way.

   atai: Can we move to concrete cases?

   nigel: Cyril identified 3 buckets.

   cyril: The first bucket is related to Japanese subtitling,
   mostly described in the white paper
   ... I sent to the list.
   ... Second is line related properties, adding padding,
   extending background, aligning lines,
   ... defining lines better in relation to rubys maybe.
   ... Third is those where a mapping isn't clear, maybe most
   importantly textOutline.

   nigel: In that bucket is a recognised issue about white space
   handling at the ends of lines.

Japanese features

   <fantasai>
   [88]https://lists.w3.org/Archives/Public/www-style/2017Nov/att-
   0006/Japanese_Subtitles_on_the_Netflix_Service.pdf

     [88] https://lists.w3.org/Archives/Public/www-style/2017Nov/att-0006/Japanese_Subtitles_on_the_Netflix_Service.pdf

   cyril: I sent the white paper to CSS.
   ... lists main features - boutens, rubies, slanted text.
   ... tate chu yoko
   ... We explain lambdaCap is not a standard, but we used it as
   the basis.
   ... I did not send the CSS properties to the group, please
   understand the context.
   ... fontShear - we use skewX() and skewY()

   fantasai: You can fall back to oblique or synthesise it if
   there are not obliques in the font.

   cyril: What would be the angle?

   fantasai: Undefined

   cyril: David Singer also mentioned font variations, I don't
   know how well they're supported.
   ... There is a slant axis.

   fantasai: That would presumably be usable to solve this case.

   florian: Do we slant the right way for vertical text? Oblique
   doesn't do that, I don't know
   ... what slant would do.

   cyril: For the TTML ruby properties, there are more TTML2
   properties than we currently use at Netflix.
   ... tts:ruby is strictly equivalent to what is defined in CSS.
   ... tts:rubyAlign is slightly different - it defines two
   additional keywords that TTWG is still
   ... discussing.

   fantasai: It's worth - the Ruby spec's distribution approach is
   partly based on justification
   ... opportunities that can be controlled by the text-justify
   properties in CSS 3.
   ... auto means normally justify, or you can say inter-character
   or spaces only, so you can
   ... achieve distribution of space you can do that, and control
   if the spaces are on the outside
   ... or not through the ruby-align property.

   cyril: tts:rubyPosition is very similar to the CSS property.
   ... At Neflix we think subtitles are better on fewer lines. For
   two lines, the best choice is
   ... on top for the upper line and beneath for the lower line.
   ... auto takes care of not knowing where the line breaks will
   be.

   florian: This auto value doesn't generalise well to more than 2
   lines.

   cyril: The preferred behaviour is above all the lines but the
   last one, and below for the
   ... last line.

   florian: That variant is not easy, but if you wanted the other
   way around, you could use
   ... the first line selector, but we don't have a last-line
   selector.

   pal: The point is not about hard or easy but the expectation of
   what people expect to see.

   florian: It is easy for two lines

   cyril: You don't always control how many lines you get

   astearns: In those cases, >2 lines, what does the "outside"
   value do?

   glenn: The first n-1 lines would be above, the last would be
   below

   astearns: That's what you want the auto to do?

   cyril: Yes, the idea is to use "outside" instead of "auto",
   which we have requested as the default
   ... for TTML2.
   ... Is "outside" supported?

   fantasai: No but we can add it

   astearns: Seems reasonable to add

   hober: Seems reasonable

   astearns: Best way to do this is to open an issue on CSS
   explaining what you need and the
   ... use cases, and it would be useful info to say what usage
   percentage.

   cyril: I'll take the action to add that

   pal: How does it get added to the agenda?

   rossen: We scan the issues before meetings and add an agenda+
   label

   fantasai: For specs in active editing they will get triaged in

   florian: For others you may need to push

   hober: The Chair is your escalation path!

   fantasai: Ask members to tag the issue with agenda+
   ... The Ruby spec is temporarily to one side while other things
   are being worked on, but
   ... we can make it happen if there are things that are urgent.

   cyril: Next one: rubyReserve is not yet ingested but we
   consider it an important feature.
   ... It is the ability to reserve space where there are no
   rubies to make sure that the line
   ... spacing stays consistent, we don't want the baselines to
   jump up and down.

   fantasai: Specify a big enough lineheight to deal with the ruby

   rossen: That's one of the frequent proposals is to set
   lineHeight >= 1.5em for Japanese so there is
   ... always enough space. Then you don't need anything else.

   <astearns> suggestion in the CSS spec is in this section:
   [89]https://drafts.csswg.org/css-ruby-1/#line-height

     [89] https://drafts.csswg.org/css-ruby-1/#line-height

   dbaron: The question is if there is a reliable way to do that
   in a way that is not font dependent.

   cyril: It is not clear to me how ruby contributes to line
   height.

   fantasai: Currently the content of the line is centered in the
   line box in CSS and the ruby
   ... needs to borrow the bottom part of the line height from the
   previous line, that will
   ... layout correctly as currently defined but if you put a
   background on the line box then
   ... that will be an issue.

   cyril: How do you apply a background to a ruby?

   fantasai: Apply it separately to the ruby annotation

   glenn: TTML2 has that now.

   fantasai: Increase the padding-top by the height of the ruby to
   increase the background area
   ... of the inline box.

   pal: It's like fillLineGap

   cyril: textCombine matches with text-combine-upright
   ... textEmphasis matches to three separate things in CSS.
   ... This paper doesn't mention rubyOffset, rubyOverflow

   glenn: rubyOverflow deals with ruby being taller or wider than
   the base characters so you
   ... have to introduce new space. For example if it is at a line
   edge boundary and you have
   ... alignment constraints on the line do you let the overflow
   go beyond the block boundary
   ... that contains the line, e.g. to the left, or do you bring
   in the ruby and then push out the
   ... base characters by adding space after them. They are
   discussed in the CSS ruby spec
   ... but it does not provide any control mechanisms.

   fantasai: Earlier drafts of rubies had some controls, but it
   was too advanced for level 1.
   ... We just said we would provide more controls for level 2.

   glenn: This came up because we were trying to mimic a
   particular implementation's behaviour
   ... that is commonly used for Japanese subtitle authoring. We
   wanted to support the right
   ... thing and also the possibly wrong default behaviour in that
   tool. It is too advanced for level 1.

   fantasai: I suggest deferring the controls for that until
   later.

   glenn: There is only partial implemetnation in TTML2 so that
   may be something we
   ... jettison before CR or mark as at risk.

   cyril: In particular overhang, is ...

   <fantasai> [90]https://drafts.csswg.org/css-ruby/#ruby-overhang

     [90] https://drafts.csswg.org/css-ruby/#ruby-overhang

   glenn: That's different, it's about deciding which classes of
   characters can be overhung.

   cyril: The basic overhang feature is not something we have
   found but we want to investigate
   ... further so that may be something we push further out.

   fantasai: There's a section on this in the CSS ruby spec, which
   says what you can't do,
   ... but mostly leaves it to the UA.
   ... We don't have a really clear idea what we want to do and it
   is more advanced and less
   ... critical. I recommend both of us leave it for the next
   level.

   cyril: writingMode - there's a difference in how it is
   specified, to do with the inline
   ... progression direction.

   fantasai: XSL-FO handled left to right columns in text was
   pretty broken and I know you
   ... don't have content that depends on that so if you don't use
   it then drop it.

   pal: In CSS you have to control both writing mode and
   direction.
   ... It seems to map to two things.

   florian: This is one of the bad things about mapping

   atai: TTML is 15 years old - at the time they began CSS wasn't
   ready, and we have to deal
   ... with the solution as is.

   plinss: Let's not revisit the past.

   pal: We want to identify things that should be possible but
   that are not possible. So far
   ... I have not found anything like that for writingMode.

   fantasai: Do you have a direction property?

   glenn: Yes, it's basically the same as in CSS

   <fantasai>
   [91]https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode

     [91] https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode

   fantasai: The writingMode mapping for SVG is as above. You will
   get better results if you
   ... map according to this.

   glenn: writingMode as specified was an additional parameter to
   unicodeBidi. There's always
   ... the override or embed (no isolate at that time) bidi
   context
   ... There was only one option to define the default bidi level,
   so that's what direction does
   ... for a paragraph. Those are the only semantics right now.

   fantasai: That's fine, it's what it should be.
   ... The writing-mode from 13 years ago was a shorthand that was
   harmfully controlling
   ... both direction and writing mode. I guess nobody is using
   writing mode for subtitles
   ... right now so that's not likely to be a problem.
   ... When we mapped to keywords I did not change the name of the
   property so that we
   ... would force implementations to change

   cyril: So writing mode only sets block progression direction
   and direction only sets inline?

   fantasai: Yes

   <fantasai> s/ writing modes for subtitles on Hebrew or Arabic
   on Hebrew / Arabic on Hebrew / Arabic/

   glenn: right now in TTML writingMode sets an "uber default".

   <inserted> Cyril: We can take an action to review that in TTML
   then

   dbaron: It's important that the direction property matches the
   underlying text, and where
   ... the logic is that embeds directionality allows
   implementations can work out the right way
   ... to display that regardless of block progression direction.

   pal: So far I have not run into issues. Suggest moving on.

   hober: Try the SVG mapping and let us know if you run into
   problems.

   cyril: That's about it for the first bucket.

Line based styling

   <dbaron> slide showing
   [92]https://codepen.io/palemieux/pen/vyzbqW

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

   pal: ebutts:linePadding [shows slide]

   <dbaron> (although what the slide shows looks different from
   what I see in my browser)

   pal: What you'd like is padding on beginning and end of each
   line, makes it easier to read

   <dbaron> showing [93]https://codepen.io/palemieux/pen/MEvVjp

     [93] https://codepen.io/palemieux/pen/MEvVjp

   pal: This is in widespread use in subtitling and captioning and
   is not possible in CSS today.

   fantasai: Really demonstrates we can't use the box model - the
   padding is not just at the breaks.
   ... Here there is no fragmentation point, it is just the end of
   the block. That proves it is not
   ... related to the breaking controls.

   pal: When I played with this I noticed there is no control of
   padding or styling of a line area
   ... after the break has happened.

   nigel: These features are not layout affecting?

   pal: No because padding reduces the line width available so can
   move the breaks.
   ... fillLIneGap - style dependent, strong feelings both ways,
   no way in CSS to guarantee
   ... that the entire line area is filled with background

   astearns: It is undesirable to have differences in background
   height on a line?

   pal: exactly
   ... [shows examples from IMSC 1.0.1 spec]

   [94]IMSC 1.0.1 fillLineGap spec with examples

     [94] http://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html#itts-fillLineGap

   pal: ebutts:multiRowAlign - lay out all the lines, pick the
   longest line, align that according
   ... to textAlign, but then align all the other lines
   differently relative to that longest line.

   rossen: Why can't you do this with a block with alignment?

   fantasai: When you wrap with a block we don't shrink-wrap to
   the content. We don't trim
   ... extra space because that requires another layout pass.

   [95]codepen demonstrating this.

     [95] https://codepen.io/palemieux/pen/bgoLzb

   pal: [describes styling and the effect]

   fantasai: We have the same problem for headings and it doesn't
   show up so obviously
   ... right now because we don't have the balancing thing.
   ... Once you have the ability to balance the headings so the
   lines are equal, there's no current
   ... way to get a box that wraps to that balance.

   pal: Unless you put an explicit br

   fantasai: Exactly. As long as the max content size is larger
   than the containing block @ @
   ... We need to specify the need to shrink-wrap around the
   wrapped text.

   cyril: Is this intended behaviour?

   fantasai: It is, there may have been implementations that did
   shrink wrapping but its
   ... expensive.

   glenn: We couldn't find spec language to support the
   implementations.

   astearns: It is not straightforward if you don't know CSS
   layout backwards and forwards.

   fantasai: There is a max-min formula that gives the result,
   which doesn't do what we need.

   glenn: The inline block is expanded to the full containing
   block?

   fantasai: Right. This is a problem we need to solve.

   rossen: Is the intention to be able to support two different
   alignments?

   pal: yes

   fantasai: To do that you have to be able to calculate the width
   of the shrink-wrapped container

   hober: Please file an issue

   pal: Someone filed an issue for this, maybe dbaron
   ... Different UAs have different behaviours on spaces at the
   ends of lines, which is really
   ... annoying.

   <fantasai> [96]https://github.com/w3c/csswg-drafts/issues/191
   <- shrinkwrap issue

     [96] https://github.com/w3c/csswg-drafts/issues/191

   dbaron: The CSS spec defines this but implementations don't do
   things right.

   pal: The CSS spec is clear that spaces at the ends of lines
   should be surpressed - it is right
   ... in Firefox but not in Chrome. My read is the spec is clear,
   which should be confirmed.

   fantasai: [looks up spec]

   pal: My read is the space should be suppressed.

   <fantasai>
   [97]https://www.w3.org/TR/css-text-3/#white-space-phase-2

     [97] https://www.w3.org/TR/css-text-3/#white-space-phase-2

   <fantasai> Step 3 : “A sequence of collapsible spaces at the
   end of a line is removed. ”

   florian: I think so. In chrome there's a bigger thread on the
   handling of this and we're
   ... trying to get it fixed.

   fantasai: The spec is indeed clear

   [98]codepen showing this issue

     [98] https://codepen.io/palemieux/pen/PjeKyq

   pal: The behaviour depends on whether the space is in a span or
   not
   ... The last issue is textOutline
   ... textOutline is used on basically every single movie
   subtitle.

   fantasai: We used to have it in the text decoration spec and we
   were asked to remove it.
   ... Now we have a dedicated property text shadow and also a
   fill stroke module.

   hober: This is controlling the stroke.

   <fantasai> [99]https://drafts.fxtf.org/fill-stroke/

     [99] https://drafts.fxtf.org/fill-stroke/

   pal: The stroke model grows the stroke, partially filling
   inside, you only want to expand on
   ... the outside.

   <dbaron> SVG added
   [100]https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute
   /paint-order which could help here

    [100] https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/paint-order

   rossen: Isn't this the only feature that we pushed to level 4
   of text?

   fantasai: There was a spread radius idea

   rossen: Text spread is exactly the requested feature, right?

   fantasai: Depends what you want to do on sharp corners

   <fantasai> old text-outline property -
   [101]https://www.w3.org/TR/2011/WD-css3-text-20110412/#text-out
   line

    [101] https://www.w3.org/TR/2011/WD-css3-text-20110412/#text-outline

   <pal> [102]https://codepen.io/palemieux/pen/ZJpwxJ

    [102] https://codepen.io/palemieux/pen/ZJpwxJ

   <fantasai> Rossen mentioned the spread radius argument for
   text-shadow, which should probably be in the L4 draft

   dbaron: Two solutions that could help, paint order or text
   shadow spread

   pal: text-shadow is useful but this is also useful

   dbaron: paint order controls which of the fill or stroke paints
   first

   flick: We had some discussion - it depends on the colours being
   fully opaque

   fantasai: stroke-align would do this

   pal: That's what we really want

   <astearns> file an issue to fill out this section:
   [103]https://drafts.csswg.org/css-text-decor-4/#intro

    [103] https://drafts.csswg.org/css-text-decor-4/#intro

   pal: For stereoscopic rendering, the use case is only for those
   displays that are capable
   ... of stereoscopic presentation so you can decide how
   important it is. The TTML method
   ... is very simple, just a disparity value - render and offset
   the same image by some value.
   ... Don't do parallax or anything crazy like that, just render,
   offset.

   nigel: That matches broadcast TV standards.

   pal: And every other standard out there.
   ... Is that something worth adding to CSS today? I'm happy to
   file an issue. It's pretty
   ... straightforward.
   ... This is essential for subtitles or captions to be displayed
   over stereoscopic video.

   <fantasai> text-shadow with spread radius will be in text
   decoration L4 (there's a placeholder in the draft atm, but I
   should get that filled out in the next month or so)

   pal: .. Otherwise it is not watchable.

   fantasai: Is disparity inherited?

   pal: It's on a region, so effectively like a div

   dbaron: This is interesting because there are other pieces of
   tech around and questions
   ... about how it interacts with 3D, VR etc.

   pal: This is the minimal feature to avoid hurting brains of
   viewers watching movies.
   ... It's compatible with CTA, SMPTE standards etc.

   dbaron: We just have to make sure it's compatible with other
   emerging things.
   ... We need to reach out to the right people.

   fantasai: It would need to generate a stacking context.

   pal: No you render individually to two planes, the left eye and
   the right eye

   fantasai: For CSS if you set this property on an element it
   should set a stacking context

   dbaron: File an issue and we should all pile on.

Wrap up, next steps

   hober: Sounds like we have action items for every issue?

   nigel: I think so.

   cyril: Would be useful for Pierre to send those slides or push
   them online

   dbaron: Or put them in the minutes and send those.

   fantasai: The TTWG had filed some issues on these before and
   we'd asked about edge cases
   ... and we hadn't got clear responses but those slides really
   help explain all the use cases.

   nigel: Great!

   fantasai: Now we understand much more clearly.

   astearns: Those pictures and links to more would be very
   helpful.

   cyril: We have a way forward for the CSS properties, but the
   rant is still there about syntax etc

   florian: When CSS has all the properties then deal with that.

   nigel: Yes, not in TTML2 but we're open to it in the future.

   rossen: That was a very productive session for both groups.

   nigel: I think so, yes. Thanks everyone.

Received on Monday, 20 November 2017 12:12:06 UTC