Intent to Ship: size-adjust descriptor for @font-face

449 weergaven
Naar het eerste ongelezen bericht

Dominik Röttsches

ongelezen,
4 mei 2021, 07:04:3404-05-2021
aan blink-dev
Contact emails
dr...@chromium.org, xiaoc...@chromium.org

Specification
https://drafts.csswg.org/css-fonts-5/#size-adjust-desc

Most recently, a remaining name-bike-shedding issue was resolved with leaving the name as is.

Summary
The size-adjust descriptor in @font-face allows scaling of glyph sizes for a particular font face without affecting the CSS font-size and derived metrics such as em.

CSS font-size can be seen as a scale factor for a box that the font draws in. Glyph sizes within that box vary between fonts, and size-adjust enables harmonising them across different fonts. That's why it can also help with reducing cumulative layout shift by matching up the fallback font and primary web font using this descriptor.

Blink component
Blink>Fonts

TAG review
https://github.com/w3ctag/design-reviews/issues/557
Existing TAG review for 
New CSS @font-face descriptors for overriding font metrics


Risks

Interoperability and Compatibility
Low, WPT tests have been established. Firefox has an experimental implementation.

Gecko: In development https://groups.google.com/g/mozilla.dev.platform/c/joBc4SoTOPc/m/Mwjr06tcAgAJ
https://github.com/mozilla/standards-positions/issues/489 - earlier discussion that started with advance-override, but we moved to size-adjust instead.

WebKit: Neutral (https://lists.webkit.org/pipermail/webkit-dev/2021-February/031706.html)

Web developers: No signals

Activation
Building close matches between size-adjust for a web font and a connected platform fallback font requires manual work, but can be provided as a service managed by third-party font providers.

Security
CSS property affecting only blink internal values, in line with existing @font-face descriptors.

Debuggability
Same as existing descriptors, @font-face rules inspectable in DevTools.

Is this feature fully tested by web-platform-tests?
Yes

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1137633

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5662073285509120

Dominik Röttsches

ongelezen,
4 mei 2021, 11:53:2304-05-2021
aan blink-dev
Addendum:

Developer Signals:
Positive, there is clear interest from AMP and Google Fonts in using this as a mechanism to reduce layout shift for web fonts.

Yoav Weiss

ongelezen,
5 mei 2021, 09:12:2305-05-2021
aan blink-dev, Dominik Röttsches
Thanks for working on this! :)

On Tuesday, May 4, 2021 at 5:53:23 PM UTC+2 Dominik Röttsches wrote:
Addendum:

Developer Signals:
Positive, there is clear interest from AMP and Google Fonts in using this as a mechanism to reduce layout shift for web fonts.

Have we tried to gauge signals from the broader community? This seems like something that would be generally useful.
goo.gle/developer-signals outlines ways to try and do that.



On Tue, May 4, 2021 at 2:03 PM Dominik Röttsches <dr...@google.com> wrote:
Contact emails
dr...@chromium.org, xiaoc...@chromium.org

Specification
https://drafts.csswg.org/css-fonts-5/#size-adjust-desc

Most recently, a remaining name-bike-shedding issue was resolved with leaving the name as is.

Summary
The size-adjust descriptor in @font-face allows scaling of glyph sizes for a particular font face without affecting the CSS font-size and derived metrics such as em.

CSS font-size can be seen as a scale factor for a box that the font draws in. Glyph sizes within that box vary between fonts, and size-adjust enables harmonising them across different fonts. That's why it can also help with reducing cumulative layout shift by matching up the fallback font and primary web font using this descriptor.

Blink component
Blink>Fonts

TAG review
https://github.com/w3ctag/design-reviews/issues/557
Existing TAG review for 
New CSS @font-face descriptors for overriding font metrics


Risks

Interoperability and Compatibility
Low, WPT tests have been established. Firefox has an experimental implementation.

Gecko: In development https://groups.google.com/g/mozilla.dev.platform/c/joBc4SoTOPc/m/Mwjr06tcAgAJ
https://github.com/mozilla/standards-positions/issues/489 - earlier discussion that started with advance-override, but we moved to size-adjust instead.

They seem to have closed that as "abandoned" since. Might be worthwhile to file a new request? 


"no signal" seems more appropriate :/ 

Yoav Weiss

ongelezen,
6 mei 2021, 15:46:1206-05-2021
aan blink-dev, Yoav Weiss, Dominik Röttsches
On second thought, it might be enough to just ping the old thread and let them know that we assume that them sending an intent to prototype for this means they consider this "worth prototyping".

Jake Archibald

ongelezen,
7 mei 2021, 04:52:5107-05-2021
aan blink-dev, Dominik Röttsches
This is great!

Are we still looking at advance-override, or is that dead for now?

It's really hard to change descriptor values in devtools. Is there an effort to improve the developer experience here?

Adam Argyle

ongelezen,
7 mei 2021, 10:37:5207-05-2021
aan Jake Archibald, blink-dev, Dominik Röttsches
ascent-override, descent override and linegap override are available to play with too 👍🏻

I agree the developer ux here is kinda crusty, would love to do my trial and error in the tab instead of in a code editor + full page refresh. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/26a47dd5-0b32-4cdc-b504-028d8a7c75dan%40chromium.org.

Chris Harrelson

ongelezen,
7 mei 2021, 11:23:4807-05-2021
aan Jake Archibald, blink-dev, Dominik Röttsches
On Fri, May 7, 2021 at 1:52 AM Jake Archibald <jaffat...@gmail.com> wrote:
This is great!

Are we still looking at advance-override, or is that dead for now?

advance-override was removed in favor of size-adjust. size-adjust solves the same use cases, but in a way that does a better job at preserving legibility of fonts.

It's really hard to change descriptor values in devtools. Is there an effort to improve the developer experience here?

Good point. I'll follow up with the devtools team to see if this can be improved soon.

--

Dominik Röttsches

ongelezen,
7 mei 2021, 11:31:0807-05-2021
aan Yoav Weiss, blink-dev
Hi Yoav,

On Thu, May 6, 2021 at 10:46 PM Yoav Weiss <yoav...@chromium.org> wrote:


On Wednesday, May 5, 2021 at 3:12:23 PM UTC+2 Yoav Weiss wrote:
Thanks for working on this! :)

On Tuesday, May 4, 2021 at 5:53:23 PM UTC+2 Dominik Röttsches wrote:

Interoperability and Compatibility
Low, WPT tests have been established. Firefox has an experimental implementation.

Gecko: In development https://groups.google.com/g/mozilla.dev.platform/c/joBc4SoTOPc/m/Mwjr06tcAgAJ
https://github.com/mozilla/standards-positions/issues/489 - earlier discussion that started with advance-override, but we moved to size-adjust instead.

They seem to have closed that as "abandoned" since. Might be worthwhile to file a new request? 

On second thought, it might be enough to just ping the old thread and let them know that we assume that them sending an intent to prototype for this means they consider this "worth prototyping".

Commented accordingly on the previous position request: https://github.com/mozilla/standards-positions/issues/489#issuecomment-834523248 

Thank you Yoav and Alex for reaching out to font folks to ask about more developer feedback.

Dominik

Yoav Weiss

ongelezen,
10 mei 2021, 17:02:1810-05-2021
aan Dominik Röttsches, blink-dev
LGTM1

Regarding a developer signal, tweeting out about the feature got ~100 likes, ~20 RTs, and a few supportive replies. (for size, a sheep selfie got ~70 likes, so you could say this feature is x1.4 more popular than the sheep, which is not nothing :P)


Dominik

fantasai

ongelezen,
11 mei 2021, 15:50:5311-05-2021
aan Dominik Röttsches, blink-dev
On 5/4/21 4:03 AM, 'Dominik Röttsches' via blink-dev wrote:
> *Contact emails*
> dr...@chromium.org <mailto:dr...@chromium.org>, xiaoc...@chromium.org
> <mailto:xiaoc...@chromium.org>
>
> *Specification*
> https://drafts.csswg.org/css-fonts-5/#size-adjust-desc
> <https://drafts.csswg.org/css-fonts-5/#size-adjust-desc>

There's no First Public Working Draft of css-fonts-5, so this spec is not
official yet and has no patent protection. You might want to push the CSSWG to
publish FWPD.

~fantasai

Manuel Rego Casasnovas

ongelezen,
12 mei 2021, 11:27:0012-05-2021
aan Yoav Weiss, Dominik Röttsches, blink-dev
LGTM2

On 10/05/2021 23:01, Yoav Weiss wrote:
> LGTM1
>
> On Fri, May 7, 2021 at 5:31 PM Dominik Röttsches <dr...@google.com
> <mailto:dr...@google.com>> wrote:
>
> Hi Yoav,
>
> On Thu, May 6, 2021 at 10:46 PM Yoav Weiss <yoav...@chromium.org
> <mailto:yoav...@chromium.org>> wrote:
>
>
>
> On Wednesday, May 5, 2021 at 3:12:23 PM UTC+2 Yoav Weiss wrote:
>
> Thanks for working on this! :)
>
> On Tuesday, May 4, 2021 at 5:53:23 PM UTC+2 Dominik
> Röttsches wrote:
>
>
> *Interoperability and Compatibility*
> Low, WPT tests have been established. Firefox has an
> experimental implementation.
>
> *Gecko:* In development
> https://groups.google.com/g/mozilla.dev.platform/c/joBc4SoTOPc/m/Mwjr06tcAgAJ
> <https://groups.google.com/g/mozilla.dev.platform/c/joBc4SoTOPc/m/Mwjr06tcAgAJ>
> https://github.com/mozilla/standards-positions/issues/489
> <https://github.com/mozilla/standards-positions/issues/489>
> - earlier discussion that started with
> advance-override, but we moved to size-adjust instead.
>
>
> They seem to have closed that as "abandoned" since. Might be
> worthwhile to file a new request? 
>
>
> On second thought, it might be enough to just ping the old
> thread and let them know that we assume that them sending an
> intent to prototype for this means they consider this "worth
> prototyping".
>
>
> Commented accordingly on the previous position request:
> https://github.com/mozilla/standards-positions/issues/489#issuecomment-834523248
> <https://github.com/mozilla/standards-positions/issues/489#issuecomment-834523248
>
> Thank you Yoav and Alex for reaching out to font folks to ask about
> more developer feedback.
>
>
> Regarding a developer signal, tweeting out about the feature
> <https://twitter.com/yoavweiss/status/1390547860433817601> got ~100
> likes, ~20 RTs, and a few supportive replies. (for size, a sheep selfie
> <https://twitter.com/yoavweiss/status/1390956772286996480> got ~70
> likes, so you could say this feature is x1.4 more popular than the
> sheep, which is not nothing :P)
>
>
> Dominik
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWBOq6-O7EMRqtUTpVmcgWaUTor%2BVrRtE1SG%3DF6RbhKQg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWBOq6-O7EMRqtUTpVmcgWaUTor%2BVrRtE1SG%3DF6RbhKQg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Alex Russell

ongelezen,
13 mei 2021, 15:23:4613-05-2021
aan blink-dev, Manuel Rego, blink-dev, Yoav Weiss, Dominik Röttsches, Tab Atkins
LGTM3

fantasai: Blink process is not gated on progression through standards milestones. We of course want features we support to eventually become standards and feature developers are on the hook to support that work. Moving this to FPWD would clearly be good, but won't change ship trajectory either way. Adding Tab who can perhaps move things forward.

Dominik Röttsches

ongelezen,
17 mei 2021, 07:50:3017-05-2021
aan Alex Russell, blink-dev, Manuel Rego, Yoav Weiss, Tab Atkins
Thanks for the responses and feedback, the flag is now switched on and chromestatus updated with LGTMers information and link to this thread. Aiming for M92.


fantasai

ongelezen,
23 jun 2021, 15:05:0623-06-2021
aan blin...@chromium.org
I understand not gating on FPWD being published since you don't control that,
but requiring at least a request that it happens would be useful. Mozilla has
this practice, and it helps keep things on track on the standards side.

~fantasai

Allen beantwoorden
Auteur beantwoorden
Doorsturen
0 nieuwe berichten