- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Dec 2019 18:13:14 -0500
- 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
issues
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:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E
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
that?
nmccully: or will there be some small space that messes up the
layout?
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
text-decoration-skip-ink
<heycam> with text-emphasis and text-decoration:
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
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
subtitling
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
diamond
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
italics/oblique.]
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:
https://github.com/w3c/ttml2/issues/784#issuecomment-390856934
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
different
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
shear
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
involved
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
feature
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
action?
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
hard
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:
https://drafts.csswg.org/css-text-4/#text-group-align-property
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
hiding
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:09 UTC