21–30 of 108 posts
Is it me, or the settings button now looks like Android?
I presume it's for consistency with Android, since right now Chrome for Android still makes references to 'the wrench icon' in text.
Without wishing to piggy back on this thread I feel its a good time to point out that this is exactly why enterprises stick with IE. People are risk averse in businesses.
Enterprise apps using IE have 1/100 of the design complexity of sites that are affected by these changes.
I just ran CLOC. We have 6.2 million lines of code in 14 different languages!
I don't know if this is related, but I had an issue with flash yesterday which seems to correspond to the Chrome 22 release. I was playing a game which had never had a serious issue before, and I noticed that the timing of things was way, way off. At first, I thought that my system was just lagging - I had a server VM running, Firefox (my main) always has a ridiculous number of tabs open, and I was playing the game i…
Without wishing to piggy back on this thread I feel its a good time to point out that this is exactly why enterprises stick with IE. People are risk averse in businesses.
That's funny, where I work (yes it's Enterprise scale) it is far more likely the tools work in Firefox than recent IE, Safari or Chrome. Closer to the truth is that Enterprise's stick with whatever it was that their developers were using when they developed the tool. That just happened to be Netscape/Mozilla browsers when some of these tools were written where I work.
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…
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 rest of the h1 below the floated content. Safari is the only browser that renders like the "old" screenshot with floated content and the h1 overlapping (and I would bet this change was made at the webkit level, so webkit nightly and eventually safari will lay out like chrome).
I avoid floated content whenever possible, so I can't comment on which browser has the correct rendering. That every browser renders differently doesn't speak well for the state of the float spec, though :) It looks like it's the negative top margin of the element after the floated content that is the root of the disagreement, and that particular case may just be under- or unspecified.
Additionally, Chrome 22 changed the behavior of -webkit-font-smoothing: antialiased so that the weight of fonts looks much different than it used to when this was enabled. It makes icon fonts look especially bad. http://code.google.com/p/chromium/issues/detail?id=152304
Well it is experimental for a reason. As quoted from the bug report > The webkit-font-smoothing css property is, contrary to the summary, still working. It is still respected, as no lcd font smoothing is being applied. However, the bug where it also affected the weight of the text as a side effect has been fixed. Though it's worth noting they are looking into whether the purpose (and thus the function) of this partic…
Your last sentence is reassuring that the developers appreciate this too.
It might have been an edge case related to the layout of this application, but ultimately I ended up having to patch bootstrap.js to fix it. I felt bad about editing bootstrap, but should anyone else need a temporary(?) fix, it came down to this code in bootstrap.js
this.$backdrop = $('')
- .appendTo(document.body)
+ .insertAfter(this.$element)
That change had been discussed even before the Chrome changes, here
https://github.com/twitter/bootstrap/pull/3825
https://github.com/twitter/bootstrap/issues/3217
So, is this a Chrome bug, or a new spec that's being followed?
In a complex code-base, there can be a lot to blame, but it's nice to have some plausible explanation.
Without wishing to piggy back on this thread I feel its a good time to point out that this is exactly why enterprises stick with IE. People are risk averse in businesses.
I thought that had more to do with the billions of dollars invested in IE-only web applications and the astronomical cost of upgrading, retraining and supporting thousands of people, not the fear that one version of Chrome will someday break CSS behavior.
Corporations fear things breaking. Retraining is rarely an issue for a browser upgrade. However, if someone pushes out a crap Chrome update like this and an LOB application goes pop then heads roll. Chrome is entirely out of band from their normal operations and skill sets so it just doesn't even get considered. It also has dubious unpredictable support lifecycles and a rate of change which would scare anyone. To use a car analogy: they want a 3 year old Volvo, not a 6 month old Tesla.