W3C home > Mailing lists > Public > www-style@w3.org > December 2019

[CSSWG] Minutes Fukuoka F2F 2019-09-17 Part II: Joint Meeting with Timed Text Group

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 3 Dec 2019 18:13:14 -0500
Message-ID: <CADhPm3vrh5YU0cqJWGO0+m15=tWdCt=A2QPgcu2gfimC30CyXg@mail.gmail.com>
To: www-style@w3.org
Cc: public-timed-text@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Timed Text Working Group Joint Meeting

  - The proposal "not within an EM" for text-combine-upright and
      tts:textCombine for 縦中横 'tate-chu-yoko' will be raised as an
      issue against Writing Modes L4 with addition of examples of
      common problems.
  - It was agreed that CSS needs to solve per-character shearing for
      issue #2983 (Support for shearing of lines and inline elements).
      The block sheering is already possible, though there is a chance
      for improving so background is not also impacted.
  - The next step to getting the text-group-align property
      ( https://drafts.csswg.org/css-text-4/#text-group-align-property )
      implemented (Issue #1975) is to write tests and add images to
      the spec.

===== FULL MINUTES BELOW =======

Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda

Scribe: birtles

Timed Text Working Group Joint Meeting

  nigel: Hi, I'm Nigel
  nigel: part of this group and the timed text group
  nigel: there are other members of the timed text group here
  <nigel> -> https://github.com/w3c/ttwg/issues/52 Joint TTWG/CSS
  nigel: I want to go through the issues in the order they're listed

縦中横/'tate-chu-yoko' extending beyond 1em

  <nigel> -> https://github.com/w3c/tt-module-cjk-ext-1/issues/1
  nigel: This is about text-combine-upright, tatechuyoko / 縦中横
  nigel: The request was to say not to squeeze it into 1em
  nigel: rather to take up more than 1em
  nmccully: The normal way of spacing these characters is that the
            first two kanji should be flush
  nmccully: In the example on the screen, when the characters can't be
            included in the line height, they might be allow to
            intrude into the sides of the line without making the line
            any taller
  nmccully: then the line won't be any further away than it is
  nmccully: The other way is to scale the glyphs

  <fantasai> testcase:

  koji: This feature was being considered in writing modes level 3
  koji: but we didn't include it because it makes it more complicated
        particularly when ruby is included
  koji: It complicates the spec and it's not clear how it should work
  koji: and the author can work around using inline blocks
  koji: The layout is slightly different from the optimized
        text-combine-upright but it's almost the same using an
        alternate flow
  nmccully: This is a common thing though so to reject it for the case
            of decoration being difficult
  nmccully: makes it difficult for the 80~90% case
  nmccully: by requiring authors to do a workaround
  nmccully: It seems like a lot to ask for the non-decorated case
  <dbaron> I'd note 民國108年 is a good real example (and common in
           Taiwan) for the 3-digit case.

  myles: Ruby has this concept of overhang too
  myles: and that's not controllable by css
  myles: Is this a similar thing that the browser should just do?
  fantasai: It's not a new CSS property, it's just a different way of
            doing text-combine
  florian: Is this an author choice? Or the browser does the right
           thing thing?
  fantasai: An author choice
  AmeliaBR: The current spec gives a limit for how many characters to
            combine, but then beyond that it goes to vertical, not
            horizontal overflow

  glenn: The question was "how does the author express a preference"?
  koji: They can currently use an inline block to do this
  nmccully: Can you still get the same width of the line block doing
  nmccully: or will there be some small space that messes up the
  stantonm: There are two ways you could do it.. you could compress
            the font size
  myles: My question is this additive or a bug we're fixing?
  nmccully: The scaling is a less desired behavior from a
            typographer's point of view
  nmccully: we've also tried to work out what the default should be
  nmccully: Most of the time you see this in dates
  nmccully: and dates often use scaled glyphs
  nmccully: With variables going forward we hope font designers can be
            more involved with scaling glyphs so they scale well and
            don't disturb the line height
  nmccully: For the Web the preference you currently have--biasing to
            make everything fit--it fine
  nmccully: overhang is more of a print thing

  <fantasai> testcase:
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%3B%20height%3A%2010em%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%E4%B8%AD%3Cspan%20style%3D%22display%3A%20inline-block%3B%20line-height%3A%201%3B%20writing-mode%3A%20horizontal-tb%22%3E333%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E
  AmeliaBR: This suggested layout is going to affect your line-spacing?
  fantasai: Because it's an inline block it doesn't include the extra
            line-spacing so it might fit within the line height
  nmccully: So this shows it is possible in the browser

  florian: This example doesn't show where ruby goes
  pal: Not scaling is very common practice
  pal: In 100% of Japanese subtitles it doesn't scale
  fantasai: One of the bad things about this is text-emphasis doesn't
            work how you would want with the inline-block approach
  koji: This is not too rare in publishing
  koji: Compression doesn't give good glyph shapes
  koji: Some authors prefer not to compress
  koji: In a single page, authors don't compress
  koji: but when the text has ruby or decorations, that do compress
  koji: if they don't have decorations, they use inline-block,
        otherwise they use text-combine

  <dbaron> I wonder if that underline behavior is just the result of
  <heycam> with text-emphasis and text-decoration:

  pal: I'd like an action item / next steps
  AmeliaBR: File an issue on the CSS repo
  fantasai: Against writing modes level 4
  nigel: Also an action to go back to reporter and suggest the best
         practice we discussed
  pal: text-combine-upright covers 0% of use cases within the domain of
  florian: An inline block is a reasonable thing to use when you
           don't need emphasis, but if we put something in the spec,
           we need it to work in all cases
  AmeliaBR: If you can get pictures of actual typography that does
            those things, that would be wonderful
  pal: So ruby, emphasis on both sides
  florian: Maybe background colors
  iank: Does it contribute to the scrollable overflow?
  myles: I think CSS should have facilities for this
  <AmeliaBR> Agree that the basic feature request, for a new
             text-combine-upright value for a common typographic
             pattern, is strong

  nigel: Moving on to issue 2983

Support for shearing of lines and inline elements
  github: https://github.com/w3c/csswg-drafts/issues/2983

  nigel: this is about CJK and supporting shearing
  pal: Today there's the ability to specify slant on individual
       characters using oblique
  pal: or italic
  pal: Sometimes it's useful to apply shear not on
       character-by-character but entire line
  pal: That's desirable to apply alignment between ruby and base text
  pal: It's subtle but really matters to folks that care
  pal: Separate issue about whether or not we should be able to
       specify the angle of shear per-character
  pal: Issue here is applying by the whole line
  nmccully: In print, it's not keeping the height/width of the line
            when you shear it
  nmccully: You change the shape of the box of each character to a
  nmccully: It's call shatai in Japanese
  nmccully: In subtitles has it become just a shear?
  <myles> https://helpx.adobe.com/ch_fr/indesign/using/formatting-cjk-characters.html
  <myles> this is what Nat is talking about
  pal: It seems to be just a one-dimensional thing in subtitles
  pal: Not sure if it's an artistic desire or technical limitation

  koji: The difference here is a position of the ruby, right?
  pal: Yes
  koji: I'm not sure about this use case, but for me changing the
        position of the ruby looks strange to me
  koji: shearing the individual characters looks better to me
  pal: On the thread some others seem to prefer shearing the whole line
  fantasai: For print we know they want the per-character approach
  fantasai: So I suggest we propose that and take that to the subtitle
            group and see if that is acceptable
  fantasai: It's possible that the request here for shearing the whole
            inline-block is just coming from technical limitations
  pal: I like the idea of going back and asking questions
  pal: but the issue opened against ttml was specifically about not
       being able to shear the whole block
  fantasai: I thought the problem was that italics shears in the wrong
            direction. [This would need to be a separate feature from

  koji: Can you point to specific individual / issue so I can follow up
  koji: I can't see any ruby in that issue
  <Rossen> https://w3c.github.io/ttml2/index.html#style-attribute-shear
  <pal> https://github.com/w3c/ttml2/issues/784
  <AmeliaBR> text-combine-upright does look bad with individual
             character shear:

  florian: You said we want to shear the entire line OR paragraph
  florian: these are two things
  florian: For the second option, CSS transforms will do it
  pal: ttml can do all three: character, line, paragraph
  <pal> https://github.com/w3c/csswg-drafts/issues/2983
  florian: The difference with ruby is more subtle
  florian: but the text combine upright case is more obviously
  pal: The issue in 2983 shows a good example
  pal: 2983 ends with a question I asked

  myles: Any proposal for how the author would describe to the browser
         the effect they desire
  pal: Yes there is a proposal there
  myles: So a new property?
  myles: Has anyone considered re-purposing the new syntax for
         font-style to describe the shearing?
  glenn: No I have not
  glenn: We introduced three new properties: shear (block), line-shear
         (per-line including tatechuuyoko), font-shear (glyph box by
         glyph box)

  myles: One option would be to have font-style: oblique -14deg does
  myles: and if it looks bad it's a browser bug
  fantasai: I don't think it will look good if there is Latin text
  myles: There's an issue in the agenda for that later today
  fantasai: I don't think we can mix this with the oblique/italic
  nmccully: It's complicated to have these different properties, but I
            agree with fantasai's desire to have a separate feature
            for this
  nmccully: to say I want to shear these things correctly, and provide
            an angle, and let the UA decide how to do it (especially
            for mixed text)
  koji: I agree with myles and don't understand why specifying an
        angle doesn't work
  nigel: You're asking a lot of the implementation and reducing
         authoring flexibility
  koji: What exactly doesn't work?
  myles: My proposal is that the font-style property does more than
         just font selection
  myles: It does font selection as it does today and also does the
         transform as necessary
  pal: The way this was explained to me is that the desired effect was
       literally just shearing
  koji: We understand, but the point is there are other glyph shearing
        use cases
  koji: that is what myles is proposing
  pal: We need to understand three distinct use cases: per block, per
       line, per character
  koji: We have per block already, myles is proposing per-character
  koji: We are wondering what is needed for line shearing

  fantasai: This example on the screen shows why we can't cover the
            line case with the same per-glyph approach
  fantasai: The characters all shear in different directions when
            using font-style: oblique
  [example includes mixed CJK and vertical and horizontal latin]
  myles: Yes, we want to discuss this later today
  <AmeliaBR> +1 for keeping this logically separate; too confusing
             when mixing latin and upright scripts

  nigel: I think we've understood the use case better, any proposal
  fantasai: CSS definitely needs to solve the per-character shearing
  fantasai: block shearing is solved
  fantasai: Open question about if more is needed for line-shearing

  pal: For block shearing, transform shears the background too. Is
       that ok?
  AmeliaBR: You need a wrapper element if you want to avoid that
  pal: Does the size change too for the block too?
  pal: It doesn't so it extends beyond the background
  pal: Any chance of a shear property that affects block size?
  myles: Transforms that affect layout?
  pal: Yes
  AmeliaBR: It could be a dedicated block shear property
  florian: The general solution for transforms that affect layout is
  florian: A limited use case could be ok
  pal: Just reacting to the idea that block shearing is solved

Aligning an aligned block of text within its container
  github: https://github.com/w3c/csswg-drafts/issues/1975

  nigel: Action was with us to check that the draft spec text was ok
  <AmeliaBR> draft spec:
  pal: I haven't had a chance to look. What's the right way to test it?
  nigel: There's draft spec, but no tests
  nigel: What is the best thing is to do to create those tests
  nigel: We don't have any perspective on implementation
  florian: It's not implemented.
  fantasai: To get it implemented, write tests and either convince
            browsers to implement it, hire Igalia to do it, or
            implement it yourself
  florian: As far as the WG is concerned, if the spec is done, there's
           not much more we can do

  AmeliaBR: It would be great to have pictures in the spec
  AmeliaBR: If you are keen on the feature, adding pictures and use
            cases would help convince implementers it's useful
  pal: So create a new PR with examples?
  all: Yes

Images with layout information
  github: https://github.com/w3c/csswg-drafts/issues/4116

  myles: When we discussed this, we talked about annotating images
         with baseline information
  myles: Is there an image format for subtitles?
  nigel: Same image formats as elsewhere

Visually hiding an element while making it available for AT
  github: https://github.com/w3c/csswg-drafts/issues/560

  nigel: This comes up a lot in subtitles and captions
  nigel: The desire to be able to make text available to the
         screenreader while not visually displaying it
  nigel: this is particularly important for subtitles because there is
         a video behind it which might be showing text, for example
  nigel: so we don't need a subtitle necessarily but we want to expose
         it to a screenreader
  nigel: There are hacks to do this
  nigel: perhaps a display property value
  fantasai: This exists in the speech module level 1
  fantasai: Property is speak
  fantasai: Initial is 'auto' which defers to display
  fantasai: but not implemented it
  fantasai: other values are 'never' and 'always'
  AmeliaBR: display: none has so many other affects other than just
  fantasai: We have a spec but no one is interested in implementing it
  nigel: The request is not to speak it
  nigel: It is to make it visible to the screenreader
  nigel: It might be presenting it in some other way
  AmeliaBR: braille display etc.

  Rossen: you can use visibility: hidden
  Rossen: and refer to it via aria-description etc.
  AmeliaBR: As the label of a different element
  nigel: If you're just labeling an element then the screenreader
         might just read that once
  nigel: but this is an element whose contents is live
  nigel: It needs to read it when it changes
  AmeliaBR: There are many demands this feature beyond the captioning
            use case
  AmeliaBR: I'm sure the accessibility people who come in after the
            break would be happy to talk about it
  nigel: Perhaps we can cover it in that session
Received on Tuesday, 3 December 2019 23:14:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:14 UTC