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. ~TJReceived 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