Well, almost everything.
There are at least two breaking CSS changes that I have discovered in the latest stable version of Chrome (Version 22.0.1229.79). All other browsers along with Chrome 21 and earlier render these examples as expected.
Floats don’t push block content down
Normally, if there isn’t enough space for a block level item to fit in a space it will drop down to another line when there is floated content before it. In Chrome 22, however, the block item will be pushed horizontally past the bounds of the parent element to the right.
Update: Looks like the newer versions of Firefox will render it differently than depicted in the screenshot. Firefox 14 and 15 look like this.
Screenshot
Z-index breaking when element is a child of a fixed parent
In every browser and version before this, z-index was respected across a page even when the element was a child of a fixed element. In Chrome 22 this no longer appears to be the case. There appear to be more issues surrounding z-index, but this is the first one I could reproduce.
Screenshot
Related: Stacking Changes Coming to position:fixed elements (thanks jamesr_chromium)
Are these bugs?
I tried looking through the CSS spec, but was unable to determine what the correct functionality was with these two examples. If Chrome 22 is rendering them correctly, then every other browser and every version of Chrome before it was wrong. Until this issue is resolved it would be good to keep these two issues in mind when running through the CSS of sites you use or work on.
#
As we say on SO, if you don’t show the code, it didn’t happen.
#
The code is in the linked jsFiddle examples, amigo. http://jsfiddle.net/cvalleskey/WD9pB/ http://jsfiddle.net/cvalleskey/9S3S8/
#
The second issue is intentional. The z-index issue is something mobile browsers are already doing. Chrome, being a browser on desktops, tables, handsets, tvs, and even it’s own OS, has decided to standardize this across all platforms. But the float thing, that’s just strange!
#
I tried both examples in Firefox and Chrome, but the floating example looks exactly the same in Firefox 15.0.1 as in Chrome 22. With the header to the right outside the box.
#
Oh wow, thanks for noticing that! I just grabbed the latest version of Firefox and here’s what I see. What’s even more curious is the first word “This” will move over as far as you set the float element’s width. It looks like this might be more of rendering difference between browsers than a bug specific to Chrome. I can’t tell which one, if either, is rendering it correctly.
#
Adding clear:both; to the h1, as you no doubt have already figured out, ‘fixes’ stuff. As an earlier comment pointed out : the float thing is just strange and experience has taught me throwing in a clear:both; after some float-business keeps my ‘Okuda’-inspired UI in place. Although I totally agree some clarity is long overdue (w3c, whatwg ?), staying ahead of the curve by testing in chromium builds on the look-out for breaking changes is almost a must. Having said that these builds sometimes contain bugs that completely shred your design leading to utter despair ;-)
#
Firefox 16 beta also behaves like FF15.
#
It’s happening for me in Firefox 16 release, too.
#
The problem isn’t with Chrome, Firefox, or any other browser. The problem isn’t that their behavior has changed over time.
The problem is solely with CSS, and the fact that its various standards are rubbish. Like you yourself said, “I tried looking through the CSS spec, but was unable to determine what the correct functionality was with these two examples.”
CSS should have been scrapped ages ago. There are so many things wrong with it at every level of its specification and implementation. It’s not the kind of technology that can be salvaged; it needs to be disposed of completely.
These fundamental issues are what the browser developers should be working on. They shouldn’t be redoing the UIs every minor revision, or wasting time and effort on Chrome OS or Firefox OS and other nonsense like that. They should be making it easy for web designers to clearly specify how a page should be laid out, and then have it work flawlessly across the major browsers. They need to get the fundamentals fixed.
#
Chrome 22.0.1229.79 also breaks tables – with some fonts (e.g. Lucida Grande) it miscalculates the width of text and will cause additional line breaks within the tables.
#
Yeps tables are broken too (and this IS a bug), http://code.google.com/p/chromium/issues/detail?id=152475 No response from developers so far. Kinda disappointing…
#
Chrome would love to go the way of ie6 and try to standardize on a different format, because that way when all the WebKit fanboys make their sites work for Chrome, it breaks everything else and makes them look bad. Take a look at how all the chrome experiments are written, they are written so that they will intentionally fail on other browsers. They are doing bad things to convince everyone that they have the most “compliant” browser by changing the standards.
Dickie is right, the real problem is the ambiguity in the specs, but Google shouldn’t be trying to capitalize on it.
#
And the text rendering! For some reason, Chrome seems to completely mangle Helvetica, especially in bold weights, which sort of makes it useless.
#
The text rendering is what has me the most worried, since these two visual “bugs” are edge cases and can be avoided. For the last couple of releases a site I’ve been working on has been doing a sort of “text rendering shuffle” every time I scroll (we use a jQuery scroller). Every time you’d scroll Chrome would use the antialiased rendering mode for the text, but then take it off a split second afterwards. My “solution” to this problem was to apply antialiased to the body tag, but now it’s looking bad again after this recent update! Grrr…
#
Weird!
#
I’m not sure if this is related to this problem or not, but we encountered some major layout issues with Chrome 22 which seemed to be related to how rules for handheld and narrower screens were interpreted. Float and padding rules were being changed due to
@media handheld, only screen and (max-width: 767px)
on browser widths which were much wider than 767px.
#
Interesting! Do you mean something like this? http://jsfiddle.net/cvalleskey/Nb3Bk/
#
Everything is broken in Chrome 22, web inspector hangs, tabs hang, it’s completely shitty!
#
I’m having all the problems related in the post and in the comments PLUS Chrome isn’t rendering border-radius properly. Actually… is not rendering border-radius at all.
Anyone else having this problem?
#
Let me rephrase that… Is not rendering border-radius when the value is bigger than 35000000px (in some cases i set the radius to 99999999px to make a circle, it used to work ok, But if I just set it to 999px will work the same way).
#
I am having a similar problem with a floated element. I am also using BrowserStack to test the site I created and everything is good til version 22. Version 23 also has the same problem. Does anyone know a good fix? Someone stated about use clear: both? Where would that go?
#
Going back to example #1.
It (this example) will only happen if the margin-top on h1 is negative. This example has the margin-top set to 0 and behaves as expected: http://jsfiddle.net/myez9/2/
However, on a slightly more elaborate layout, the negative margin on h1 doesn’t have the ‘bug’ observed initially: http://jsfiddle.net/myez9/3/
Maybe this can set us in finding a solution and a reason?