How to rectify CSS flex issues appearing in MS Edge? - css

On my online shop page, the 8 main product categories as well as the products below are displayed as tiles/boxes. The CSS has been optimized for and works great in my installed Chrome (version 79.0.3945.79) as well as my installed Safari (version 13.0.3) browser. However, the shop pages are completely messed up when viewed in Microsoft EDGE (version: 17.17134).
I tried to change the tile element's CSS but this destroys the appearance in Chrome etc. But as I have a limited knowledge of in flexbox, I am not entirely sure where to start.
I am looking for
1) the CSS selector causing the error, and
2) a way to address this error in MS Edge without changing the Chrome CSS settings.
My suspicion is that the following is causing the issue:
#media screen and (min-width:850px)
.gallery-columns-4 .gallery-item, .large-columns-4 > .col, .large-columns-4 .flickity-slider > .col {
max-width: 25%;
-ms-flex-preferred-size: 25%;
flex-basis: 25%;
}
The website shop page can be found here. I am grateful for any helpful tipps and ideas. Thanks!

After further trial and error, I found the issue. The error was mitigated by changing the tile's parent element CSS from
display: flex;
to
display: inline-flex;
This appears to work fine in all browsers, across MS Edge, Chrome etc.

Related

Bootstrap #grid-float-breakpoint issues in Safari

I am working with Bootstrap 3.3.2 . My Goal with the site im building was to have the nav menu always collapsable, like when it is in mobile view. to accomplish this I went to bootstrap.com/customize and changed the #grid-float-breakpoint: to 99999999px; so large that it would never uncollapse the nav. This works fine for all other browsers except for Safari. In safari my nav header image shows up, but the icon for the drop-down menu is gone.
In safari when inspecting the drop-down icon's css I find:
#media (min-width: 99999999px;){
.navbar-toggle {
display: none;
}
}
It seems as if Safari thinks my viewport is actually greater then 99999999px. Now the simple change would be to adjust my code to display: inline; But when i do this it takes the .navbar-toggle out of the grid system and not pliable for responsive.
Any help towards a solution or if anyone knows of this as a bug issue, would help out alot. I have already researched issues with the #grid-float-breakpoint and did not find much other then this WAS an issue with chrome a while back but has since been patched.
thanks
Presumably you're referring to http://crbug.com/375574 , which apparently still applies to Safari 8. The solution is to use a somewhat less absurdly-high value for #grid-float-breakpoint. Removing a single digit seems to be sufficient:
#media (min-width: 999999999px) {
Also, I went ahead and filed a WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=141533
After messing around with the css for a few hours I found that adjusting the #media (min-width: 9999999999px) .nav-bartoggle to -webkit-display: inline; and adjusting the parent element width and a few other adjustments can result in acceptable code. Im sure cvrebert's method will work much better. But I just wanted to comment that there is pure css work arounds in the case some one needs to know in the future.

Strange Webkit Issue in Wordpress

Large amounts of white-space in the body of this page - something is setting height: 4148.21875px; but cant find what.
http://wp.ewsproduction.com/backtohealth/
Wordpress site using woothemes.
Fonts don't render until developer tools are opened.
Site only behaves this way in webkit (tested in chrome, safari)
We can't seem to find the issue.
Any one have an idea?
I found one line at 2159 in style.css.
.widget_woothemes_features .features .feature .feature-content { overflow: hidden; }
It gives to feature block some 3000px height.
If I remove this rule evething is perfect!
Hope this helps!
Also I found the source of the issue with the fonts not loading until inspector is opened:
https://code.google.com/p/chromium/issues/detail?id=336476

Sprites background not sizing properly in safari only on some computers

I am currently working on a reponsive css webdesign and have a few sprites for different button states.
In this case I've tested the webdesign in Firefox, Opera, IE (compatibilty starting from IE8), Chrome and Safari and everything is displayed correctly. The website has been tested under different cell phones and tablets with different browsers without any problems.
I'm in the final testing stages and having co-workers see how the website looks in different resolutions... A friend who owns a macbook pro is the only one who encounters this problem and only under safari which makes it difficult for me to target and solve. I have tried to reproduce the problem using his screen size and switching safari's mode to that of a mac user without success.
The code is the following :
.buttons-menu .btn .rules, .buttons-menu .btn .contact , .buttons-menu .btn .tickets , .buttons-menu .btn .profile { display: block; width: 143px;height: 32.5px;padding-top: 37.5px; background-size: 100% 300%;}
.buttons-menu .btn .rules {background: url(../images/sprite-button-03.png); background-position: 0 -100%;}
The problem is that this tester sees about 2 pixels of the second part of the sprite when he shouldn't and this only in safari.
Thank you for reading this.
EDIT : SOLUTION : As ralph.m thought, the problem came from the rounding of the decimals in safari that didn't always behave the same as in other browsers.
Avoid using values like .5px. The browser will have to round that up or down to a whole number, and you don't know which way it will go.

PureCSS.io - Pure Grid (height) displays different in Firefox

I am using the Pure Grids of PureCSS. I have a pure-g with three pure-u-1-3, containing a few paragraphs. The problem is that there is a difference in display between Chrome/IE and Firefox when one of the units is longer than the others.
http://jsfiddle.net/f3YNe/3/
http://i.stack.imgur.com/VFVYu.png
I have tried to use jQuery to calculate the highest pure-u-1-3 and setting the rest to this height. But it didn't work out as expected, since this grid has to be responsive as well (using pure-g-r)
Does anybody know how to make Firefox produce the same output?
As purecss has fixed the problem (v0.6) by implementing it in every browser, this answer is obsolete.
Previous answer:
Your problem is that PureCSS is using -ms-display: flex in Internet Explorer and -webkit-display: flex in Webkit Browsers. Opera, Firefox and (obviously) older IEs don't get this solution.
To get it working in Firefox (20+) and Opera you could apply the following in your stylesheet:
.pure-g-r {
display: flex;
}
Further information: http://css-tricks.com/using-flexbox/
Here a example using your fiddle: http://jsfiddle.net/f3YNe/12/
This has been fixed and accepted as a fix as part of pure's v0.6.0 milestone.
The fix can be seen on Github here: https://github.com/yahoo/pure/pull/351/files.
If you're using pure prior to 0.6.0 coming out adding
.pure-g-r {
display: flex;
flex-flow: row wrap;
}
to your css should make things play nice in your layout.

Why does internet explorer push my content below the sidebar?

I have a page which displays just fine, in Firefox and Chrome. However, it has the content pushed past the bottom of the sidebar (as if I had a clear) in Internet Explorer 8 (I haven't tested any other IE versions). Does anyone know how to fix this?
The page is located here
Thanks,
Lemiant
You're missing the doctype for you page. Without it, IE will revert to quirks mode, which is essentially IE 5.5's rendering engine.
What you're observing is IE incorrectly computing widths for your elements, see here for a description on how IE 6 and older versions implement width.
For some reason that remains a mystery to me, IE thinks the #content element is wider than it should be.
This code did the trick for me:
#content {
line-height: 18px;
margin-right: 250px;
width: 550px;
width: 497px\9;
}
This makes all browsers use the width of 550px, and IE (all versions), 497px, which seems to be tha maximum it accepts. Hacky, but it works :D
EDIT: You're missing a !doctype. This might be the cause.

Resources