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

Typography bucket #13

Closed
jensimmons opened this issue Nov 10, 2021 · 30 comments
Closed

Typography bucket #13

jensimmons opened this issue Nov 10, 2021 · 30 comments
Labels
accepted An accepted proposal focus-area-proposal Focus Area Proposal
Milestone

Comments

@jensimmons
Copy link
Contributor

jensimmons commented Nov 10, 2021

Description
After web fonts were defined, and before variable fonts were invented, the CSS Font specification added powerful tooling for web designers & developers to use to create refined typography.

font-feature-settings is a CSS property that addresses the low-level plumbing for these ability. It has broad support across almost all browsers.
However, Authors are encouraged to never use font-feature-settings, and instead use font-variant-*.

This [font-feature-settings] property is a low-level feature designed to handle special cases where no other way to enable or access an OpenType font feature exists. Whenever possible, font-variant shorthand property or an associated longhand property, font-variant-ligatures, font-variant-caps, font-variant-east-asian, font-variant-alternates, font-variant-numeric or font-variant-position should be used.

Authors cannot currently follow this advice, because not all browser have implemented all of the font-variant-* properties. This is holding back typography on the web.

Specifically, these two need to be implemented in Chromium:

Specification
CSS Fonts Module Level 4

Tests
font-variant-* tests

Rationale
State of CSS Survey 2021 reveals requests for typography improvements.

@jensimmons jensimmons changed the title Font features & variations font-variant-* Nov 10, 2021
@jensimmons jensimmons changed the title font-variant-* font-variant-alternates + font-variant-position Nov 10, 2021
@jensimmons jensimmons changed the title font-variant-alternates + font-variant-position Typography: font-variant-alternates + font-variant-position Nov 10, 2021
@jensimmons
Copy link
Contributor Author

If we want to add more typography things to this, we could add support for the IC unit. It's a unit important for typesetting CJK scripts. 1ic is the full width glyph in the element’s font, as represented by the “水”.

@jensimmons
Copy link
Contributor Author

jensimmons commented Nov 10, 2021

@jensimmons
Copy link
Contributor Author

@jensimmons

This comment has been minimized.

@jfkthame
Copy link

If you're thinking of improving support (and interop) for text in CJK scripts, can I propose supporting the Segment Break Transformation rules, which have the potential to make CJK authors' lives considerably better:
https://drafts.csswg.org/css-text-3/#line-break-transform

@jgraham
Copy link
Contributor

jgraham commented Nov 11, 2021

I think it would be useful to decide which are the highest priority areas in this proposal. Including all the specs/properties mentioned seems like it would end up with something that's too broad, and runs the risk of different implementations picking different subsets to prioritise, so not improving the actual interop. Is there data we can use to help narrow the scope to the features with highest impact?

@foolip foolip mentioned this issue Nov 12, 2021
36 tasks
@jensimmons
Copy link
Contributor Author

jensimmons commented Nov 15, 2021

Tests for Segment Break Transformation

foolip added a commit to foolip/browser-compat-data that referenced this issue Nov 22, 2021
These are in Firefox and Safari but not in Chrome, and the subject of an
Interop 2022 proosal:
web-platform-tests/interop#13
foolip added a commit to foolip/browser-compat-data that referenced this issue Nov 22, 2021
These are in Firefox and Safari but not in Chrome, and the subject of an
Interop 2022 proposal:
web-platform-tests/interop#13
@foolip
Copy link
Member

foolip commented Nov 22, 2021

The Chromium bugs for font-variant-alternates and font-variant-position are here:
https://bugs.chromium.org/p/chromium/issues/detail?id=716567
https://bugs.chromium.org/p/chromium/issues/detail?id=1212668

@jensimmons regarding the advice to use font-variant-alternates and font-variant-position instead of font-feature-settings, do you know if it's currently possible to use font-feature-settings to achieve the desired effect?

If so, I see that usage of font-feature-settings is quite high, and I wonder if some of that is really working around lack of support for font-variant-*. That would be compelling evidence of a need. If someone can suggest things to search for in httparchive, I could give that a try.

Elchi3 pushed a commit to mdn/browser-compat-data that referenced this issue Nov 23, 2021
These are in Firefox and Safari but not in Chrome, and the subject of an
Interop 2022 proposal:
web-platform-tests/interop#13
@gsnedders
Copy link
Member

@jensimmons regarding the advice to use font-variant-alternates and font-variant-position instead of font-feature-settings, do you know if it's currently possible to use font-feature-settings to achieve the desired effect?

it is

@jensimmons
Copy link
Contributor Author

I like to withdraw the suggestion of widows & orphans. While this functionality is highly requested, I don't believe that the current spec solves the problem we designers & developers have.

Instead, I believe font-size-adjust and/or text-size-adjust would be a better addition to this bucket.

@jensimmons
Copy link
Contributor Author

@foolip font-feature -* properties do accomplish the same end-results as font-variant-* properties, but Authors are not supposed to be using font-feature-*. That's a low level API which is hard to deal with in the cascade, and has a lot of obscure values. The CSSWG intended for Authors to write code using font-variant-* exclusively. However, Authors cannot do so, because of the lack of implementations. Which is holding the whole industry back.

font-feature -* is implemented, but is practically impossible to use.

font-variant -* is what people should use, but it's not implemented in enough browsers.

Interop 2022 can help with this. Let's finish these features & make Fonts 4 complete.

@jensimmons
Copy link
Contributor Author

I'm hearing desire for Color Fonts as well: https://drafts.csswg.org/css-fonts-4/#color-font-support

@jgraham
Copy link
Contributor

jgraham commented Dec 2, 2021

So, can we clarify what the actual proposal here is? It's difficult to understand what people think forms part of the final state of this proposal, and if we don't know that it's not possible to take a stance on it (or at least not a positive stance).

@gsnedders
Copy link
Member

So, concretely, I believe our proposal is:

General Typography

  1. Support font-variant shorthand + longhands
  2. Support initial-letter
    • Spec
    • Needs tests in WPT. (There's some token coverage, and both WebKit and Gecko have some tests in their respective repos.)
  3. Support font-palette and @font-palette-values

CJK Typography

Splitting this out, mostly for the sake of clarity; this being split out shouldn't be taken as any suggestion that these should be in any way lower priority.

  1. Support the ic unit
  2. Support hanging-punctuation

@jensimmons
Copy link
Contributor Author

jensimmons commented Dec 3, 2021

Also under CJK Typography, as suggested by Mozilla:

  1. Support Segment Break Transformation

@achristensen07
Copy link

Along with CJK Typography, it's probably worth including CJK text encoding, particularly iso-2022-jp, gbk, and gb18030

@foolip
Copy link
Member

foolip commented Dec 6, 2021

  1. Support initial-letter

    • Spec
    • Needs tests in WPT. (There's some token coverage, and both WebKit and Gecko have some tests in their respective repos.)

I found https://github.com/WebKit/WebKit/tree/main/LayoutTests/fast/css-generated-content but I can't find any tests in Gecko (or Chromium) beyond what's imported from WPT.

How comprehensive are the WebKit tests, and do they match the current spec?

@foolip
Copy link
Member

foolip commented Dec 6, 2021

For Segment Break Transformation Rules, the spec has UA-defined behavior:

Then any remaining segment break is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.

I only looked into this feature today so my misunderstanding is surface deep, but doesn't this make most of the interesting cases UA-defined? A bunch of the tests were marked tentative in web-platform-tests/wpt#26588 due to w3c/csswg-drafts#5086, which is still open.

@jfkthame
Copy link

jfkthame commented Dec 6, 2021

For Segment Break Transformation Rules, the spec has UA-defined behavior:

Then any remaining segment break is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.

I only looked into this feature today so my misunderstanding is surface deep, but doesn't this make most of the interesting cases UA-defined? A bunch of the tests were marked tentative in web-platform-tests/wpt#26588 due to w3c/csswg-drafts#5086, which is still open.

Yeah, that's unfortunate.... there used to be quite a bit more in the spec, but then details were deferred to Text-4 following the discussion in w3c/csswg-drafts#5086 (comment).

So I guess we'd need to push that spec work forward if any real progress is going to happen here.

(FWIW, I think Gecko implemented something close to what used to be in the Text-3 draft up until a year ago, though there may have been some edge cases where it didn't entirely conform.)

@foolip
Copy link
Member

foolip commented Dec 6, 2021

I see. w3c/csswg-drafts@b3bb0ed seems to be the commit that commented out the rules around this.

@foolip foolip added the accepted An accepted proposal label Dec 14, 2021
@jensimmons jensimmons changed the title Typography: font-variant-alternates + font-variant-position Typography bucket Dec 16, 2021
@foolip
Copy link
Member

foolip commented Dec 16, 2021

@gsnedders said on the Matrix channel:

https://wpt.fyi/results/?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&q=legacy-mb%20or%20iso-2022-jp-%20or%20ic-unit%20or%20font-variant is in principle vaguely what we want for what the typography issue became, but also calling that all "typography" seems a bit questionable.

I agree. Does anyone have suggestions for another name for this bucket? Or could it make sense to slot encodings under the webcompat bucket, if it has caused any broken sites? @achristensen07 WDYT?

@karlcow
Copy link

karlcow commented Dec 17, 2021

What about "Font Parametrization bucket"?

@foolip
Copy link
Member

foolip commented Dec 20, 2021

@karlcow https://encoding.spec.whatwg.org/ doesn't really fit well under that banner either. But @annevk suggested just "text" which I think would work.

@gsnedders
Copy link
Member

I've labelled them as interop-2022-text based on @annevk's suggestion, but I'm by no means wedded to that name.

@foolip
Copy link
Member

foolip commented Jan 10, 2022

Thanks @gsnedders! It would be great if someone from each browser engine team can look over interop-2022-text and comment if there are any issues.

@jfkthame
Copy link

The font-variant descriptor (as distinct from the font-variant property) was dropped from CSS Fonts (as noted at https://drafts.csswg.org/css-fonts-4/#changes-2018-09-20), which means a few of the tests currently listed are not valid. At first glance, this affects font-variant-05.xht, font-variant-06.xht, and font-variant-descriptor-01.html.

@gsnedders
Copy link
Member

From the discussion earlier, @foolip was going to remove many of the tests in encoding, given most already pass. I'd added everything that followed from "including CJK text encoding", not limiting it to the parts particularly mentioned.

These are the tests which don't pass everywhere, which is 8 tests rather than 1209 tests. However, even among those 8 many of those are any.js tests, and it's unclear there's any value to running those in different environments. Do we just want to go down to these five tests?

@gsnedders
Copy link
Member

web-platform-tests/wpt-metadata#2388 does duly remove the vast majority of the tests (down to six, keeping decode & encode tests for each of three encodings, despite gb18030 encode being interop already).

@jensimmons
Copy link
Contributor Author

For reference, this is what we debated and decided.

Technology Considered Decision
font-variant-alternates + font-variant-position Include
IC unit (CJK focused) Include
hanging punctuation (JP focused) Exclude
Initial Letter Exclude
Color fonts Exclude
Segment Break Transformation rules Exclude
CJK text encoding Include

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted An accepted proposal focus-area-proposal Focus Area Proposal
Projects
None yet
Development

No branches or pull requests

7 participants