- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 13 Jan 2016 13:17:23 -0800
- 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. ~TJ
Received on Wednesday, 13 January 2016 21:18:10 UTC