After a few of my customers upgraded to Chrome v72 they've noticed a few layout issues that were not present in <= v71. From what I've found it mostly occurs when having an element with overflow: auto or overflow: scroll within a parent element that is using flexbox to position its children.
Is anyone else experiencing this? Note this is only occurring in v72, I've tested < 72 and other webkit browsers and can't reproduce it.
Looks like Chrome renders flex boxes with overflows differently since v72. At least parts of those changes were intentional to make Chrome more compliant to the spec and other browsers.
See this issue for details:
https://bugs.chromium.org/p/chromium/issues/detail?id=927066
Update:
We've heard you loud and clear and have decided to revert the change in Chrome 72 to avoid breaking existing sites and to allow developers a bit more time to update their pages.
The change will instead ship with Chrome 73. As such it's still important to make the required changes to avoid breaking it in future versions of Chrome and to ensure compatibility with Firefox.
2019-02-05 22:44:28 UTC
Seems like this shipped in Chrome 73, confirmed by a.xin's answer above.
The quick and dirty fix that worked for me is adding "min-height: 0" to all of the flex children.
Related
So I'm quite new to flexbox and I'm by far a real front-end developer. I'm working on a WordPress theme for an upcoming side project and currently I'm doing the HTML part.
I'm using flexbox for pretty much everything, and I'm having some issues with some weird flexbox behaviour.
If you go to http://hatch.tips/preview and check it in Chrome, everything seems to be alright. Mozilla is also fine except a weird border to the right of the compacted logo (resize browser).
On Safari, things go pretty haywire, so you should check that up.
I'd highly appreciate any help. First of all you might notice that I haven't used any prefixes for my code yet, but since Safari renders some of the flexbox stuff, I assumed that might not be the actual problem.
Flexbox is still "fairly new" so I recommend using the prefixers. It fix most of the bugs, especially in IE for instance.
See: http://shouldiprefix.com/#flexbox
I was working on vertical rhythm of my css framework - it looks perfect in firefox but different in chrome and ie9. Anyone know what the cause?
my framework typography page:
http://kenhty.github.com/Natural/typography.htm
If you are referring to the box-flex grid, then check out the specs of the MDN page on using flexible box. There are a couple issues you're running into...
For one, support is extremely limited. Firefox 18+, Chrome 21+, no support in IE and Safari. As such, you are experiencing issues in Chrome because production Chrome is the only one that actually supports your code, and also you are missing the following styling:
-webkit-flex-direction: column
Yours is defaulting to row, which is causing your issues in Chrome.
More perplexing is that I'm on Firefox 15 and it's displaying your Grid properly... Yet when viewing the computer styles, it doesn't even display your grid styling, as Firefox 15 doesn't yet support it. So I'm actually amazed that you're grid displays properly in Firefox.
Anyway, check out what browsers support it and make sure you are overriding any default settings that need to be overridden.
I'm working on adding basic print functionality to a web map application I recently built, and I can't seem to make the printing work properly when using Internet Explorer 8 in standards mode. I was hoping that someone with more CSS experience might be able to help.
I've created a basic example on jsbin that demonstrates what I'm seeing: http://jsbin.com/osepov/16. This example prints properly in most browsers. In Internet Explorer 8 in standards mode, however, the map's tile images run off of the first page and onto a second page when printing. I've tried a bunch of different CSS combinations, and have browsed the web for hours looking for hacks that might solve the problem. I've obviously had no luck thus far.
Being that the print functionality works well in most browsers, I am willing to compromise on a few things, if needed, to get this working in Internet Explorer 8 standards mode:
The map doesn't have to fill the entire page, minus the header. It can have a fixed height.
The header is nice to have, but I'm willing to do without it.
I know it is possible to build a PDF on the server, but I really want to do this with a simple print stylesheet.
Note: Yes, I do have to support IE 8 standards mode. I had a solution that kicked IE8 users to IE7 mode, but this was not acceptable to my client.
UPDATE 2: I was able to resolve the issue by bumping IE8 down to IE7 standards mode. The map is printing correctly now.
UPDATE: Nope, this didn't solve the problem. I'm still seeing the same issue. This seemed to work, but I'm still seeing the problem.
ORIGINAL POST: I think I figured this out. Basically, it seems like the "top" div was causing the entire page to get bumped down and run over to a second page when printing in Internet Explorer 8 standards mode. I'm not sure why this was just happening in IE8 and not in other browsers, but there are all sorts of strange IE-only bugs that I don't understand.
The final fix:
#wrapper {height:100%;left:0px;position:absolute;top:0px;width:100%;}
#top {height:70px;position:relative;width:100%;}
#main {height:785px;overflow:hidden;position:absolute;top:70px;width:100%;}
So positioning the "top" div relatively and assigning a pixel height and "overflow:hidden" to the "main" div seemed to solve the problem.
This isn't a perfect solution, but it meets my current requirements.
Here's the updated solution: http://jsbin.com/osepov/19.
I am pulling my hair trying to find a fix for this problem. If you go to this site you will see that (under IE) the slider and the menu on the top is broken. Works fine under all modern browsers.
Any idea how to fix this? Thanks.
Edit: Want to add that the original site design works fine under IE. I did a massive amount of editing under the hood and somewhere along the line this one was broken that I can't seem to find a fix for. Since I did a lot of customization, I think it seems unfair to ask the original author for a fix (and he is not very responsive either).
The document invalid. In particular, there is a <style> element before the Doctype. This triggers Quirks mode and causes browsers to become very inconsistent (e.g. IE emulates a log of bugs from IE 5.5).
Always work in standards mode and perform basic automated QA.
I can't check it for you, since I've not got access to IE right now, but I've often found that adding position:relative to misbehaving elements is something of an IE magic bullet.
No fix but a lead: the issue with the menu bar is one of IE's mysterious float positioning bugs, as can be demonstrated by putting <div style="clear: both">xxx</div> after the navbar ul. (Note that it won't work if the div has no content!)
stuff about box model deleted: as David Dorward mentions this is caused by quirks mode, and moving the style down past the doctype causes the slider to behave sensibly.
Should i check in all? or in any one is enough because all share same rendering engine Webkit.
My question is related to HTML CSS rendering.
I know one difference Safari for windows and MAC both have Font smoothing (anti -alisaing)
Is there any other differences?
There's definitely a difference between Chrome and Safari due to Safari's font rendering. In Safari text tend to be a bit bolder due to the anti-aliasing algorithm and can sometimes take up a few extra pixels on the screen.
Also keep in mind that Safari uses the SquirrelFish javascript engine while Chrome uses V8.
I have found a difference in the way Safari and Chrome select SELECT boxes. I think Chrome seems to ignore line-height whereas in Safari line height seems to make a difference.
Safari Windows 5.1.7 v's Chrome Windows Version 22.0.1229.94 m
I think this is to do with the default user agent style?
I would check, yes.
Whilst the browsers all use the same rendering core, they're not necessarily on the same version (and there are multiple versions of Safari out there in any case).
Also, as slebetman says, font rendering is quite different depending on OS and anti-aliasing settings too, so you need to be aware of that.
Shadows are fast&ugly in chome; slower&prettier in safari (and firefox). IIRC there was some difference in CSS3 transitions too - but really, these details are still in flux anyhow and change from version to version.
In practice, I only check one of the two regularly, which is generally fine. Before putting major changes online, it's obviously not a bad idea to check again, but during development, it's not worth the hassle; they're so similar anyhow...
There are major and minor differences. Do check!
Minor: full support for CSS3 border-radius in Chrome. I've read about, but can't find, this in Safari.
Major: zooming in Chrome zooms everything. (This is the behavior in almost every browser.) Zooming Safari zooms text but leaves other things unchanged. Your ever-so-carefully-laid-out form is highly likely to be trashed if the user zooms in. Leave lots of extra space.