interop icon indicating copy to clipboard operation
interop copied to clipboard

Test Change Proposal for `font-size-adjust`

Open drott opened this issue 1 year ago • 7 comments

Test List (updated)

  • css-fonts/animations/font-size-adjust-composition.html - remove any tests that refer to ic-height.
  • css-fonts/parsing/ - ditto, remove any tests that refer to ic-height.
    • font-size-adjust-computed.html
    • font-size-adjust-valid.html
    • font-size-adjust-invalid.html

Rationale

ic-height fallback behavior is unresolved, compare https://github.com/w3c/csswg-drafts/issues/6384

As long as we do not have a consistent, testable specified behavior for what we do when ic-height is not available, we can not logically achieve meaningful interop, or complete test coverage. There are realistic scenarios where the value is not available, and UA specific fallbacks cause the kind of surprising behavior that we want to remove through the Interop effort.

CC @shivamidow @lilles

drott avatar Feb 13 '24 12:02 drott

There are also subtests for ic-height in:

css-fonts/parsing/font-size-adjust-computed.html css-fonts/parsing/font-size-adjust-valid.html css-fonts/parsing/font-size-adjust-invalid.html

lilles avatar Feb 13 '24 13:02 lilles

Updated issue description with those.

drott avatar Feb 13 '24 13:02 drott

@jgraham / @zcorpan can you review for Gecko? @gsnedders / @nt1m can you review for WebKit?

nairnandu avatar Feb 14 '24 15:02 nairnandu

Given it's early in the year I slightly favor the option of standardizing ic-height fallback behavior rather than removing this. I'm open to removing ic-height fallback behavior tests if the standardization timeline does not give enough room for other browsers to implement though. cc @fantasai

nt1m avatar Feb 14 '24 16:02 nt1m

Yes, alternatively can we move the ic-height stuff to separate tests, or guard it with CSS.supports checks instead?

emilio avatar Feb 14 '24 16:02 emilio

Moving ic-height tests in that case to guarded by CSS.supports works for me, thanks for the suggestion. Our shipping decision for the ic-height value depends on if and what we can resolve on in https://github.com/w3c/csswg-drafts/issues/6384

drott avatar Feb 14 '24 17:02 drott

Following https://github.com/w3c/csswg-drafts/issues/6384 I can foresee two possible outcomes:

  1. We do base the adjustments on unreliable heuristics, in which tests we can only WPT test situations in which the relevant metrics are available.
  2. We agree to make no adjustments if a specified metric is not available, in which case we can also test fallback behavior. (= no adjustment expected).

Do these outcomes sound reasonable to everyone on this thread? And would folks agree on checking tests and if needed or non interopable: removing expectations for fallback behavior from tests in the case of 1)?

This also means, we're okay shipping ic-height if in WPT tests we don't try to attempt to test or pretend we have interoperable fallback behavior in absence of the metric.

drott avatar May 08 '24 08:05 drott

In CSS WG resolutions https://github.com/w3c/csswg-drafts/issues/10292 and https://github.com/w3c/csswg-drafts/issues/6384 it was decided to keep using heuristics in the case where the font lacks a metric, which means we arrive at

  1. We do base the adjustments on unreliable heuristics, in which tests we can only WPT test situations in which the relevant metrics are available.

With that ic-height can be tested, we just can't test what happens when ic-height is not available. This is a limitation, but this was the group's consensus. - With that, no test change is needed.

drott avatar Aug 01 '24 14:08 drott

Thank you @drott!

foolip avatar Aug 01 '24 14:08 foolip