4 ms·
> being able to trigger alert from an iFrame that is being singlehandedly removed by the Chrome team. Fixed that for you. It’s not being reconsidered; The Chro
by q-rews 5y ago
> being able to trigger alert from an iFrame that is being singlehandedly removed by the Chrome team.
Fixed that for you. It’s not being reconsidered; The Chrome team makes decisions for the web whether you agree with them or not. They might pull the “proposal” only to just do it again later. [1]
More context on the same blog [2]
1: https://www.quirksmode.org/blog/archives/2017/09/chrome_breaks_v.html https://www.quirksmode.org/blog/archives/2017/09/chrome_brea...
2: https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
- bokan 5y agoDisclaimer: I'm the one who made the change in [1] so I'm biased but... IMHO the argument on the blog mischaracterizes the situation - Chrome didn't break these properties but changed how they're interpreted under pinch-zoom. This was done precisely to keep backwards compatibility (on desktop browsers): at the time, the vast majority of pages assumed pinch-zoom can't happen on desktop (something that was becoming more common). The status quo meant zooming in on a desktop page would cause it to "swim" as various "fixed" elements shifted around, JS drop-down menus appeared in the wrong place, etc. This happened virtually everywhere one looked: facebook, twitter, apple.com, etc. The blog basically argues for "make pages fix themselves" which, even if major sites do, is unrealistic in the long tail. > They might pull the “proposal” only to just do it again later It's not nefarious, this often happens in response to feedback and real world experience to try and minimize disruption. In this case, developers convincingly argued that there should be an API to better react to pinch-zoom before making the change.
- jacquesm 5y agoThen you go to the standards body.