WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
259551
[CSS Fonts] The `from-font` value for CSS `font-size-adjust` is not computed correctly
https://bugs.webkit.org/show_bug.cgi?id=259551
Summary
[CSS Fonts] The `from-font` value for CSS `font-size-adjust` is not computed ...
Jonathan Kew
Reported
2023-07-27 05:15:25 PDT
Support for the `from-font` value was implemented in
https://bugs.webkit.org/show_bug.cgi?id=254790
, but does not behave according to the spec. The current spec[1] says that the computed value of `font-size-adjust` is the keyword none, or a pair of a metric keyword and a <number> and for the `from-font` keyword[2] it confirms that this Computes to the <number> corresponding to the specified metric of the first available font. However, in Safari Tech Preview[3] I'm seeing `from-font` retained as the computed value. This results in incorrect behavior, because when inherited by a child element, it may then resolve to different numbers depending on the font of the child (instead of inheriting the number computed from the metrics of the font on the element where it was specified). In addition, it appears that the value is not being resolved using the metrics of the first available font *of the element where `font-size-adjust` was specified*, but rather using metrics from the parent element. This can be seen in the demo at
https://codepen.io/jfkthame/pen/NWEMaaG
, where the use of `from-font` gives different results depending on the font family of the containing block, instead of being computed from the paragraph's own first available font. See also
https://github.com/w3c/csswg-drafts/issues/9050
. [1]
https://drafts.csswg.org/css-fonts-5/#font-size-adjust-prop
[2]
https://drafts.csswg.org/css-fonts-5/#valdef-font-size-adjust-from-font
[3] Release 171 (Safari 16.4, WebKit 18616.1.15)
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2023-08-03 05:16:16 PDT
<
rdar://problem/113328110
>
Tim Nguyen (:ntim)
Comment 2
2023-08-03 09:59:09 PDT
WPTs are at
https://github.com/web-platform-tests/wpt/pull/41273
(thanks Jonathan!) The computed style is a trivial fix, and using the correct font probably is as well, currently doing some local testing.
Tim Nguyen (:ntim)
Comment 3
2023-08-04 09:54:44 PDT
This requires a bit more work than expected to use the current element's style, since the fonts are not initialized at the moment we compute the size-adjust value.
ChangSeok Oh
Comment 4
2023-08-08 16:42:49 PDT
(In reply to Tim Nguyen (:ntim) from
comment #3
)
> This requires a bit more work than expected to use the current element's > style, since the fonts are not initialized at the moment we compute the > size-adjust value.
Yes. That is why the parent element's font instead. I will take a look at the issue.
ChangSeok Oh
Comment 5
2023-09-25 15:26:19 PDT
Pull request:
https://github.com/WebKit/WebKit/pull/18193
EWS
Comment 6
2023-09-27 17:28:48 PDT
Committed
268550@main
(49f5188b5e82): <
https://commits.webkit.org/268550@main
> Reviewed commits have been landed. Closing PR #18193 and removing active labels.
WebKit Commit Bot
Comment 7
2023-09-28 00:17:18 PDT
Re-opened since this is blocked by
bug 262285
ChangSeok Oh
Comment 8
2023-09-29 12:11:06 PDT
Pull request:
https://github.com/WebKit/WebKit/pull/18425
EWS
Comment 9
2023-10-07 07:54:01 PDT
Committed
269041@main
(89bdb0336c3b): <
https://commits.webkit.org/269041@main
> Reviewed commits have been landed. Closing PR #18425 and removing active labels.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug