Re: [css-size-adjust] Expose the adjusted font-size and adjustment percentage

That's a great point about correctness. I made a demo that shows this
behavior exists in both blink/android and WebKit/iOS:

I searched the httparchive and found getComputedStyle(...)['font-size'] is
incredibly common so any change here (either way) will likely break
content. I know of two sites, and google feedback, which do
depend on the current blink/webkit behavior. The computed font-size value
also has some surprises when positioning content relative to text--I only
point this out to show what a bad place users are in :/

How do you think the no-op/roundtrip property of getComputedStyle compares
with the web compatibility concern?

On Mon, Jan 11, 2016 at 12:25 PM, Boris Zbarsky <> wrote:

> On 1/11/16 3:11 PM, Philip Rogers wrote:
>> It's true that returning the used font-size from getComputedStyle would
>> likely require layout/reflow.
> That wasn't my concern.  Plenty of things in getComputedStyle need
> relayout to calculate.
> Are you primarily concerned with the performance impact, or is there
>> also a correctness issue with getComputedStyle(...).fontSize not being a
>> no-op?
> It's a correctness issue, imo.  Generally, the value returned by
> getComputedStyle should be such that setting it as the specified value
> doesn't change the way things look/act.  Computed and used values both
> typically have that property, actually.
> From that point of view, if a UA is enforcing a minimal used font size,
> returning that used font size from getComputedStyle seems fine.  But if a
> UA is multiplying all font sizes by some constant factor to go from
> computed to used, then returning the used value from getComputedStyle would
> mean that every time you do the "set specified style to result of
> getComputedStyle" operation you would pick up another factor of that
> constant, right?
> Are we in that sort of situation here, or am I misunderstanding the
> proposal?
> -Boris

Received on Tuesday, 12 January 2016 01:03:26 UTC