Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for subscripts and superscripts #585

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

palemieux
Copy link
Contributor

Closes #583

Copy link
Contributor

@nigelmegitt nigelmegitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine to me, but in researching it I discovered that the semantic basis for this is not as stable as we would like, and we need to think about what we do to make this feature properly usable.

TTML2 lists the derivation of tts:fontVariant as CSS Fonts Level 3 §6.11, but no such section exists. I raised w3c/ttml2#1277 fpr this.

MDN claims that the specification of the font-variant-position property is in CSS Fonts Level 4, currently a Working Draft that lists font-variant-position as an at-risk feature - there's a more recent ED too that still includes it.

MDN shows browser support for the CSS property in Firefox and Safari but not Edge or Chrome, so I guess that makes it unlikely to be pulled.

I think the key semantic that we are relying on here, aside from just positioning, is the synthesis of simulated glyphs where the super or sub glyphs are not available in the font. That's not mentioned in TTML2 but is in the CSS Fonts level 4 ED text.

Secondarily, and just as importantly, that spec also defines a fallback mechanism that uses the font-size and vertical-align properties, and recommends using them based on conditional rules. From a TTML/IMSC perspective this is arguably an implementation detail.

However, I think we should think about and discuss:

  1. Whether introducing this is dependent on a fix in TTML2 for the derivation - see Derivation of tts:fontVariant points to a non-existent section ttml2#1277
  2. Whether we need to describe the fallback approaches if the glyphs are absent from the font, or if the CSS property is not supported at all, and if we do, whether that text belongs in TTML2 or IMSC.

@palemieux palemieux changed the base branch from issues/bump-imsc-1-3 to main January 17, 2025 17:31
@css-meeting-bot
Copy link
Member

The Timed Text Working Group just discussed Add support for subscripts and superscripts w3c/imsc#585, and agreed to the following:

  • SUMMARY: Update the semantic basis reference in TTML2, keep watching for CSS updates on this feature
The full IRC log of that discussion <nigel> Subtopic: Add support for subscripts and superscripts #585
<nigel> github: https://github.com//pull/585
<nigel> Nigel: [summarises https://github.com//pull/585#pullrequestreview-2536922277]
<nigel> .. So the two main questions are:
<nigel> .. 1. Do we need to fix up TTML2 before referring to fontVariant?
<nigel> .. 2. How much do we care about what the UA actually does if it doesn't fully support this?
<nigel> .. Or if the font doesn't fully support superscript and subscript for every glyph in the super or subscript text.
<nigel> Pierre: Overall I think this is a feature in flux in CSS, it changed even in the past couple of months.
<nigel> .. The semantic intent is pretty clear though.
<nigel> .. The fallback is very specific today, to HTML and CSS as currently implemented.
<nigel> .. My conclusion is not changed, that for the purpose of TTML and IMSC we can use fontVariant
<nigel> .. and things like imscJS will probably implement the fallback, but it's an implementation detail that
<nigel> .. might change in 2 months.
<nigel> .. Separately we can improve TTML2, but it's a separate issue.
<nigel> Nigel: OK, second question: what is the range of acceptable behaviour for the UA?
<nigel> Pierre: Looking at the current text...
<nigel> -> CSS Fonts Level 4 Subscript and superscript forms https://drafts.csswg.org/css-fonts/#font-variant-position-prop
<nigel> Pierre: [reads text from CSS spec]
<nigel> .. I think the intent is super clear
<nigel> .. The dispute in the browser world is not the semantics, but about whether or not the UA
<nigel> .. is expected to synthesise the font variant if it doesn't exist.
<nigel> Nigel: OK, but there is no link through via TTML2 to this CSS spec text.
<nigel> Pierre: You mean because the link is broken?
<nigel> Nigel: Yes, but even if it weren't broken, it's informative and the TTML2
<nigel> .. text on tts:fontVariant has a lot less information in it.
<nigel> -> TTML2 tts:fontVariant specification https://www.w3.org/TR/ttml2/#style-attribute-fontVariant
<nigel> .. It doesn't hint about synthesis or fallback
<nigel> Pierre: There's a semantic basis in the table
<nigel> Nigel: That's what's broken!
<nigel> Pierre: I can raise a PR to fix the semantic basis link to CSS.
<nigel> .. It links to CSS Fonts Level 3...
<nigel> Nigel: It's missing from there
<nigel> Pierre: No, it's in there.
<nigel> Nigel: Did I make a mistake? Oh, it's just the section number that changed.
<nigel> -> CSS Fonts Level 3 §6.5 Subscript and superscript forms https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#font-variant-position-prop
<nigel> Nigel: Clearly they want to make some tweaks in Level 4 but this is fine.
<nigel> .. TTML2 doesn't even hint at anything except for use of the OpenType features,
<nigel> .. but CSS certainly does.
<nigel> .. I'd be a lot happier if either TTML2 or IMSC said something about fallback alternatives, either way.
<nigel> .. Basically, is it ok if a UA doesn't do anything when the sub or super variants are absent from the font?
<nigel> Pierre: I think it's explicit on what it should look like, the fallback is an implementation detail I think.
<nigel> Nigel: I could read it a different way, which is that the implementation should simply select the
<nigel> .. variant glyphs using the OpenType feature, and if they're absent, there's no behaviour specified.
<nigel> .. In other words, anything is ok.
<nigel> Pierre: I think that's the point of contention in the browser community, last time I checked.
<nigel> Nigel: OK, so what do we do?
<nigel> Pierre: I think we should be happy with the semantic basis definition, and the syntax.
<nigel> .. I don't think anyone disputes what superscript and subscript mean
<nigel> .. I'd consider correcting the section reference in TTML2, but otherwise leave it as is.
<nigel> .. If CSS settles in a couple of months maybe we'll have a reason to revise it.
<nigel> Nigel: I think that's a good starting point, and like you say there's time for us to keep watching and thinking.
<nigel> Pierre: I will have to pay attention to it.
<nigel> Nigel: [hunts for CSS issues]
<nigel> .. Too many to trawl through right now.
<nigel> SUMMARY: Update the semantic basis reference in TTML2, keep watching for CSS updates on this feature
<nigel> Nigel: It's w3c/ttml2#1277
<nigel> Pierre: I'll prepare a pull request for that.
<nigel> .. Any comments on the IMSC pull request?
<nigel> Nigel: No, the text is super simple
<nigel> Pierre: If you can approve it then I'll fix up TTML2
<nigel> Nigel: OK
<nigel> Pierre: Super

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Superscript/subscript support
3 participants