I swear this used to work correctly and it still works correctly in Safari under iOS, but for some reason it's broken in Chrome and apparently (as per our client) in IE 11.
The basic setup is here:
http://codepen.io/mattlacey/pen/BpEvWE
With transform: translateZ(0); commented out then everything that's initially offscreen is never rendered, with it, hardware accelerated rendering is enforced and it is rendered. The issue now is that even though it's rendered the elements can not be intereacted with. I've setup two onclick inline scripts, one on "A.L.C" and one on "KAREN WALKER EYEWEAR". Clicking the first works, while the second does not, because it's in an element that's only displayed because of the transform.
Is there a known work around for this issue?
If it is possible for you to edit the HTML, with a little extra markup, it could be resolved wrapping the .filter-values-indexed div in another element and applying the overflow to this new element.
HTML:
<div class="wrap">
<div class="filter-values-indexed">
[...]
</div>
</div>
CSS:
.wrap{
overflow-x:scroll;
}
.filter-values-indexed{
width:100vw;
column-width: 200px;
max-height: 250px;
}
I am not sure why this is happening, but if you remove the overflow-x and transform properties, the offscreen content becomes clickable.
.filter-values-indexed{
column-width: 165px;
/*overflow-x: auto;*/
max-height: 250px;
/*transform: translateZ(0);*/
}
This horizontal scrollbar will move to the bottom of the page. Depending on your specific needs this could be a temporary fix.
Related
On a simple markup:
<div class="line">
<div class="content_width">Content</div>
</div>
with CSS:
.line {
background: yellow;
}
.content_width {
width: 500px;
}
yellow background is wide as a browser window, so if window width is less than 500 and you scroll to the right you can see it was cut off. How to make browser render this correctly? Test Fiddle
I think the .line should, as a parent element, take the maximum width of its children, but maybe I am wrong. I could set the width to the .line, too, but I would like to see more elegant solution, without setting additional widths, because the site is responsive and this is only an IE8 issue.
I thought first this was an IE problem, but I see now same happens in other browsers. I could not notice that because the site is responsive.
Try giving a:
display: inline-block;
To the .line class.
While I know this works, I can't point you to an official documentation why it does. Perhaps someone else can come up with an explanation + better solution.
I am curious about an odd rendering behaviour on Safari 5.1. In a two-column layout, the first column has a fixed width, and the second one should take the remaining part.
HTML:
<div class="row">
<div class="left">
<p>Left</p>
</div>
<div class="right">
<p>Right. Some more text here, to show how odd the line breaks...</p>
</div>
</div>
CSS:
.row { width: 300px; background: yellow; overflow: hidden; }
.left { width: 100px; background: red; float: left; }
.right { margin-left: 100px; background: green; overflow: hidden; }
This works great on most browsers (on all "modern" browsers, as I thought), but now I found out, that Safari 5 adds an unintended right margin on the second column of the same width as the intended left margin (as if there were a .right { margin-right: 100px; } rule).
http://jsfiddle.net/MvF3V/1
Most Browsers:
Safari5: (tested on 5.1.7, but it occurs also on 5.1.9)
When I remove the overflow: hidden; it works fine, but I need that for other inside elements.
My questions is not how to rearrange this little example, but:
Is this a Safari-5-Bug, or are my CSS rules somehow wrong, even if they "work" on most browsers?
If it is a Bug, does it have a name, with which I can google some workarounds?
Can I detect somehow, which Browsers are affected with this behaviour, to define some exception rules for them.
Update: The standard Android browser (Galaxy S3, AppleWebKit 534.30) seems to use the same old webkit engine. The same strange right margin appears: http://jsfiddle.net/MvF3V/1/embedded/result/
Give a
padding-left: 100px;
instead of
margin-left: 100px;
This seems indeed to be a bug in older Webkit versions. I found another question about the same issue.
There are workarounds. The most obvious is to avoid overflow: hidden to clear floats, and to use clearfix instead.
Since nobody answered to my questions, I try to give them myself:
Is this a Safari-5-Bug?
It's a Webkit Bug
If it is a Bug, does it have a name, with which I can google some workarounds?
No name found, apparently there are not many people who layout websites as I do... (and still want to support old browsers).
Can I detect somehow, which Browsers are affected with this behaviour, to define some exception rules for them.
If you really want to define exceptions, you can make such ugly things in JavaScript
var webkitCheck = /AppleWebKit\/([0-9.]+)/.exec(navigator.userAgent);
if (webkitCheck) {
var webkitVersion = parseFloat(webkitCheck[1]);
if (webkitVersion < 535) {
jQuery('html').addClass('oldWebkit');
}
}
< 535, because 534.59.10 is the Webkit version of the latest Safari5 version, and in Safari6, this bug does not occur anymore.
But thanks, #Era and #NoobEditor for your comments.
I've noticed that if I view the page at wider resolution, the content of a section gets aligned to the right, instead of centered.
I use
margin: 0 auto;
width: 998px;
overflow: hidden;
It seems to have this bug, at least in Safari, Firefox and Chrome. I tried disabling overflow: hidden and it gets rid of the bug, but messes up my floats inside the content.
You can see an example at the page live here:
http://autouncle.dk/da/brugte-biler/Kia or http://autouncle.dk/da/brugte-biler/Ford (you have to view it at at least 1500px widescreen to see the bug).
Any ideas on what can cause this bug and what are possible solutions?
About the reason of the problem: this is due to the page-title element of your header:
#header-outer element contains some floated elements but you forgot a clearing, so the offset left of the main section of your site starts where the page-title ends. (you can verify this by hiding page-title element — when you set display: none the page is correctly centered)
So adding
body#basic_page #header-outer {
overflow: hidden;
}
you solve the problem
As a sidenote strongly avoid to put empty div only for clearing purposes: there're cleaner methods that don't require extra markup, like easyclearing
Your solution is removing overflow: hidden
To fix the float bug on the second example you gave try to use 100% of the width:
body#basic_page.brands_controller #content .text_info {
overflow: hidden;
font-size: 12px;
width: 100%; /* new rule */
}
Remove the
overflow:hidden
from div#content and put its contents in an extra <div> in it which has
width:100%;
overflow:hidden;
This resolves the problem for me.
I have a page where the content is positioned in the center of the page using margin:auto and I want to add a background that is centered the same way but because of the background doesn't appear when I scroll down I have resorted to using position:fixed which nicely does the trick.
However, positioning it centrally the same way as the content is proving a huge challenge because playing with left:x% and margin-left:-y% is a nightmare and never quite works well that all screen resolutions.
The markup is simple:
<div id="main" class="container">
<div class="overlay"></div>
<div id="content"></div>
</div>
You can see the site HERE
The BEST CSS configuration I came up with is this:
.overlay
{
position: fixed;
top: 0; /* These positions makes sure that the overlay */
bottom: 0; /* will cover the entire parent */
left: 0;
width: 72%;
margin-left:14%;
height:100%;
background: #000;
opacity: 0.45;
-moz-opacity: 0.45; /* older Gecko-based browsers */
filter:alpha(opacity=45); /* For IE6&7 */
}
I've tried many combinations but the background always resized differently than the content and I would want it to stay in place.
Position:absolute with margin:auto works perfectly well except when you scroll down.
The above configuration works nicely except the "min-width". If I could get it to stop minimizing after a certain point, this would be perfect.
Many thanks in advance if you have a solution to this
you could use background-attachment: fixed for your background, instead of using empty markup for styling purpose. in this way you will see it even when you're scrolling down the page.
Here's a quick and dirty round corners technique I've been playing around with.
<!-- assuming the div isn't statically positioned -->
<div>
<img src="box_TL.png" style="position:absolute;top:0;left:0;"/>
<img src="box_TR.png" style="position:absolute;top:0;right:0;"/>
<!-- other content -->
<img src="box_BL.png" style="position:absolute;bottom:0;left:0;"/>
<img src="box_BR.png" style="position:absolute;bottom:0;right:0;"/>
</div>
Yeah it's ugly, but it's fast, the corners are fluid, it avoids nested divs and requires no javascript. The corner images and content order makes no difference, but I thought it might be more intuitive to order corners and content this way.
Question: How terrible is this technique? Is it passable or should I abandon it completely?
I'd use jQuery Corner Plugin. It's very fast and works in all modern browsers, and also in IE6.
It's terrible. Your markup should be content, and your layout should be in the style. Not intermingled. You should go with:
<div class="whatitis">
bla blah ... content here
</div>
and the style:
.whatitis {
background: whatever;
border: whatever;
border-radius: 1em;
-moz-border-radius: 1em
-webkit-border-radius: 1em;
}
Yes, sure, some browsers won't get rounded corners. But if you hack up a solution that will give properly rounded cornsers even in browsers that does not support that, you will have a complex solution, and odds are that your site will not work att all in some other browsers. So you should ask yourself: What is more important, that the site works at all in some browser X or that you get rounded corners in some other browser Y?
Addition: Using the jQuery plugin mentioned in another answer (or some other pre-packaged solution) might be accepptable. As long as it does not require any extra <div>, <img> or other tags.
It's a terrible solution, sorry :-)
It's true that you don't need any JavaScript or nested div elements. The JavaScript is easily avoidable, no matter what. But is four irrelevant img elements better than a few nested div elements? The img element is supposed to contain image content, using it for layout purposes is basically the same as using tables for layout. Yes, it works, but it's wrong, and it ruins all semantic value.
If I were you, I'd do it this way (excuse the silly class-names, they are just there to illustrate):
The markup
<div class="boxWithRoundedCorners">
<div class="roundedCornersTop">
<div class="roundedCornersTopRight"></div>
</div>
<p>Your content goes here, totally unaffected by the corners at all. Apply all necessary margin and other styling to make it look good.</p>
<div class="roundedCornersBottom">
<div class="roundedCornersBottomRight"></div>
</div>
</div>
The CSS
.boxWithRoundedCorners { background: red; }
.roundedCornersTop {
background: url(topLeftCornerPlusTheTopOfTheBox.gif); /* Should be pretty long. Assuming your corners are 20*20px, this could for instance be 1000*20px, depending on how large the box would ever be in the real world */
height: 20px;
}
.roundedCornersTopRight {
background: url(topRightImage.gif);
width: 20px;
height: 20px;
float: right;
}
.roundedCornersBottom { background: url(topBottomCornerPlusTheBottomOfTheBox.gif); /* same "rule" as above */
height: 20px;
}
.roundedCornersBottomRight {
background: url(bottomRightImage.gif);
width: 20px;
height: 20px;
float: right;
}
Got it? Hang on, I'll put up an example somewhere :-)
Edit: Just threw up an an example!
Anyhow, this method will ensure a complete flexibility regarding height and width of the box, and the layout within the box always works the way it should, unaffected by the corners.
Yes, it gives you some nested divs with no purpose other than the layout - but then again, that's what DIVs are used for. IMGs should always be content-related imagery.
You could do it with all the corners being 15*15px and setting the background-color of the container. However, when stretching these images like this, you get the opportunity to add shadows, gradients or other effects. This is what I'm used to do, so I did this this way with the stretched images.
This method is well tested out, and should as far as I know/remember work fine at least all the way back to IE 5.5.
This is a very old topic, but since it's re-appeared on the front page, I'll add a comment.
In the last few months, a new solution has appeared for rounded corners, which solves the issue for all relevant versions of IE (6,7,8).
CSS3Pie is a 'hack' for IE which allows you to set up rounded corners in your CSS and not worry about it anywhere else. At a stroke, you can throw away all those extra divs in your markup and those jquery plugins, and just specify it in your stylesheet the way it should be.
All other browsers support rounded corners in CSS, and have done so for long enough that you don't need to worry about older versions.
CSS3Pie also helps with CSS gradients and box shadows in IE too, so it's a very big win for cross-browser developers.
you'll come into issues with IE6 using PNGs so you will either need to add the correct CSS filter background to divs instead of images or use javascript to help turn the png images into transparent gifs with the png background added.
http://www.twinhelix.com/css/iepngfix/
If the box is fixed width, then there's an interesting trick you can do which works in IE8 and the rest (but not IE7-):
div.rounded {
width: 600px;
padding: 0 10px;
}
div.rounded:before,
div.rounded:after {
display: block;
content: "";
width: 600px;
height: 10px;
}
div.rounded:before { background: url(images/rounded_top.png); }
div.rounded:after { background: url(images/rounded_bottom.png); }
Unfortunately this doesn't work with anything that has a fluid width, and it's not copatible with older IE browsers, but I still like it :)