W3C home > Mailing lists > Public > www-style@w3.org > January 2016

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 13 Jan 2016 13:17:23 -0800
Message-ID: <CAAWBYDCwKh1g5MZX3Q+xjK9NhKdG9iSzh0-LNEg5=baS=z7UEQ@mail.gmail.com>
To: Philip Rogers <pdr@chromium.org>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style <www-style@w3.org>
On Mon, Jan 11, 2016 at 5:02 PM, Philip Rogers <pdr@chromium.org> wrote:
> That's a great point about correctness. I made a demo that shows this
> behavior exists in both blink/android and WebKit/iOS:
> http://output.jsbin.com/hodega
> 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, fullstory.com 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?

I'd be surprised if there wasn't an opposing web-compat issue with our
sending magnified values, with things being misplaced or mis-sized as
a result.

Let's try to fix our impl to reflect the computed font-size (relying
on authors to manually handle multiplying by text-size-adjust if they
want "real" values) and see where that gets us.  We can make a better
decision with some actual compat data.

Received on Wednesday, 13 January 2016 21:18:10 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:56 UTC