81–90 of 108 posts
Other browsers do allow multiple URLs to be specified, but Chrome doesn't. The workaround from time immemorial has been a chunk of Javascript that calls window.open on a bunch of URLs. In Chrome 22 only the first will open.
Earlier quoted context omitted.
What does the spec say? is there a bug opened already? or are all the browsers wrong and Chrome is right?
The spec says Chrome is right (was recently changed). Chrome is not the only browser. iOS browsers, the Android browser and Chrome for Android have always used the new behavior. The reason for the change is faster scroll performance, particularly on mobile.
Earlier quoted context omitted.
What does the spec say? is there a bug opened already? or are all the browsers wrong and Chrome is right?
The spec says Chrome is right (was recently changed). Chrome is not the only browser. iOS browsers, the Android browser and Chrome for Android have always used the new behavior. The reason for the change is faster scroll performance, particularly on mobile.
for position: fixed and changed stacking contexts, you're likely running into this: http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin... Basically, the position: fixed on the parent of the span you're trying to put on top is now making the parent its own stacking context, which means that all children will be stacked relative to each other, not to the first absolutely or relatively positioned ancestor of t…
How much content does this break? Was this discussed on one of the public mailing lists? If so, does anyone have a link to some relevant discussion? (I would love to hear the various positions regarding breaking existing content to bring an optimization used by browsers people generally consider to render things weirdly to all browsers.)
for position: fixed and changed stacking contexts, you're likely running into this: http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin... Basically, the position: fixed on the parent of the span you're trying to put on top is now making the parent its own stacking context, which means that all children will be stacked relative to each other, not to the first absolutely or relatively positioned ancestor of t…
for the float issue, I did find this: http://code.google.com/p/chromium/issues/detail?id=133474 it may be a dupe of an older bug, but I got tired of looking. It's worth noting that it does not render as stated in Firefox (Mac or Win) or IE9 (in IE9 or compatibility modes). IE9 puts the entire h1 below the floated content. Firefox is partway between IE and Chrome and moves the "This" off to the right side but puts the…
Since the update I've also encountered issues with box-reflect when used in combination with CSS3 transforms or box-shadows.
Not directly related, but there was a comment in the original article that got me thinking: >To test if your page is going to change, go to Chrome's about:flagsand turn on/off "fixed position elements create stacking contexts" Wouldn't it be cool if webdevs could alter Chrome's rendering settings to simulate IE and Safari? This would be a huge productivity boon. I think it might be an interesting challenge for Chrome…
Earlier quoted context omitted.
The spec says Chrome is right (was recently changed). Chrome is not the only browser. iOS browsers, the Android browser and Chrome for Android have always used the new behavior. The reason for the change is faster scroll performance, particularly on mobile.
Really? Can you point to the spec change? Did I miss a working group decision on this somewhere? Last I checked, the discussion on this got nowhere, with WebKit folks claiming this change was needed to optimize stuff and Opera and Mozilla folks claiming that optimizing scrolling worked just fine without this behavior change...
Earlier quoted context omitted.
The spec says Chrome is right (was recently changed). Chrome is not the only browser. iOS browsers, the Android browser and Chrome for Android have always used the new behavior. The reason for the change is faster scroll performance, particularly on mobile.
Those are all webkit based browsers, so it seems normal that they'd all behave the same.