IMPORTANT NOTE! I have only recreated this bug on a 1st generation iPhone running Safari 4.0 (528.16), but as I'm trying to make my site as widely compatible as possible this is still a potential issue...
The problem: floated elements in lists are not appearing on screen. I have narrowed the issue down to the following combination of rules:
<html>
<head>
<style>
p {
float: left;
overflow: hidden;
}
ul {
list-style: none;
}
</style>
</head>
<body>
<ul>
<li><p>hello</p></li>
</ul>
</body>
If I place a non-floated element inside the <li> tag following the <p>, then the text in the <p> becomes visible.
So far I have tested this on the latest versions of Chrome/IE/Firefox on Windows 7, Safari on an iPhone 4, and Chrome/Firefox/Opera on Android (4.2.1 ) and the problem described has not occurred
I repeat: I have ONLY seen it occur on Safari 4.0, but as I can't test every platform/browser version combination out there, I am concerned this issue may be more widespread.
Thanks
I am also encountering this issue, however I am seeing it in Safari 5.1.7 in Windows 7.
My current hot-fix is unfortunately JavaScript-based:
$('.listContainer').hide();
$('.somethingElse').hide();
$('.listContainer').show();
I don't exactly understand why this works, but as long as .somethingElse is a valid selector, the hide/show operation shouldn't get optimized away and will actually force Safari to render the list. Someone who actually understands the nuts and bolts of this could probably lend a more graceful solution, but that's the hack I'm using right now.
EDIT
The weird thing is that if I place the dynamically-generated HTML statically into the .html file I'm working in, there is no rendering problem in Safari. There's something lower-level going on here with how the DOM is constructed in Safari that's breaking this. It's also quite possible that I'm not following some standards for how new elements should be added to the DOM in real time.
Any help? Maybe I should add a question of my own.
FINAL EDIT
Alright, I got it working through CSS, now.
The solution is to give the list-items overflow:hidden.
I don't know why, but that solved my problem. Hope it solves yours. Give it a shot.
I think the problem here is that you've got overflow:hidden which is why your element move out of range. Actually, if you have any element with some width specified and overflow: hidden then you are trying to hide some internal tags
for eg:
<div style='width:200px'>
<div style='float:left;'>asdfkl</div>
<div style='float:left;'>asdfkl</div>
<div style='float:left;'>asdfkl</div>
<div style='float:left;'>asdfkl</div>
<div style='float:left;'>asdfkl</div>
<div style='float:left;'>asdfkl</div>
</div>
Then you are actually trying to hide anything that goes out of given 200px width Provided you have the inner divs float so that all of them are in same line/ section or div
When there's a bunch of float elements, the parent element will not be able to calculate its height properly.
After all your float elements include an empty element as follows
<div class="break"></div>
. break{
height: 1px;
width: 100%;
clear: both;
float: none;
}
Related
I'm running into a really weird issue in IE (specifically tested in IE 11 & edge mode on Windows 7). IE seems to add extra padding/height to the list-items in the nested <ul>. Screenshots and tests below. If someone could point me the right direction of how to fix this, that would be great, I've tried a few different things and don't know what's going wrong.
I have a nested <ul>, like so:
HTML
<ul>
<li class='static'>Example Menu Item</li>
<li class='static'>
Another Example
<ul class='dynamic'>
<li class='dynamic'>Dropdown Menu Item</li>
</ul>
</li>
</ul>
CSS
ul.dynamic
{
z-index: 10000;
list-style-type: none;
padding: 0;
margin: 0;
background: #ccc;
min-width: 200px;
}
li.dynamic
{
display: block;
white-space: nowrap;
/* Fix for bug in IE10/11/Edge */
list-style-image: url(data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7);
}
The list-style-image setting, if you're wondering, is a fix for a previous bug I found in IE wherein regardless of the list-style or list-style-type setting, the submenu would still have the list "dots" next to it. That encoded data is the smallest possible transparent image.
Tests
I've tried a lot of different things, from setting both the <ul> and the <li> to fixed height, box-sizing: (content-box|border-box), white-space: nowrap, and/or padding: 0; margin: 0;, with no tangible results.
Strangely, if I set basically anything differently in the IE inspector, including changing existing values on the <li>, when the repaint occurs, the <li>'s suddenly snap back to the right height. However, if I put any of those changes in my stylesheet and reload, the same problem occurs.
Furthermore, this problem isn't specific to my machine. I've had a few others (also, Windows 7, IE11) test it and run into the exact same problem. It's also specific to IE. The menu looks fine in every other (up-to-date) browser, but when I run it in 11 or 11's compat modes for IE10 and 9, I see the same issue.
I also cannot created a reduced test case in JSFiddle (or similar), as I cannot replicate this bug in JSFiddle, which is the strangest part. That would also imply that my CSS has more affecting it than I think, but the only things that I did not include in the CSS above are a few styles that only add color & a border-bottom, and some inline styles that are set by javascript to set its top, left, and position correctly as a dropdown menu.
Notes
My doctype is:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
And I am not setting any meta tag that would force IE into an older compat mode.
Finally, these <ul> menus aren't hardcoded, they are generated by the ASP.NET <asp:Menu> element with RenderingMode="List" and IncludeStyleBlock="false".
Screenshots
Chrome
Internet Explorer 11 (no-compat mode)
Above is a shot of the <li> in question with the inspector highlighting it, showing no padding or margin making up this
Thanks for taking the time to read all this! If you have any pointers or suggestions, I would be happy to hear it!
Figured out my issue, shoutout to #ns1234 for helping me out with this.
Turns out there is a bug in IE related to the combination of dynamically modifying content, and using position: relative.
Note that position: relative does not trigger hasLayout, which leads
to some rendering errors, mostly disappearing or misplaced content.
Inconsistencies might be encountered by page reload, window sizing and
scrolling, selecting. With this property, IE offsets the element, but
seems to forget to send a “redraw” to its layout child elements (as a
layout element would have sent correctly in the signal chain of redraw
events).
In essence, either don't use position: relative, or also add an overflow value, like overflow: hidden, to your element, to fix this.
I fixed it by adding overflow: hidden to my sub-menu <ul>, which caused IE to correctly repaint the <li>s I was having trouble with.
This CSS works for me:
overflow: hidden;
height: auto;
Problem
I have a <select> where one of its <option>’s text values is very long. I want the <select> to resize so it is never wider than its parent, even if it has to cut off its displayed text. max-width: 100% should do that.
Before resize:
What I want after resize:
But if you load this jsFiddle example and resize the Result panel’s width to be smaller than that of the <select>, you can see that the select inside the <fieldset> fails to scale its width down.
What I’m actually seeing after resize:
However, the equivalent page with a <div> instead of a <fieldset> does scale properly. You can see that and test your changes more easily if you have a <fieldset> and a <div> next to each other on one page. And if you delete the surrounding <fieldset> tags, the resizing works. The <fieldset> tag is somehow causing horizontal resizing to break.
The <fieldset> acts is as if there is a CSS rule fieldset { min-width: min-content; }. (min-content means, roughly, the smallest width that doesn’t cause a child to overflow.) If I replace the <fieldset> with a <div> with min-width: min-content, it looks exactly the same. Yet there is no rule with min-content in my styles, in the browser default stylesheet, or visible in Firebug’s CSS Inspector. I tried to override every style visible on the <fieldset> in Firebug’s CSS Inspector and in Firefox’s default stylesheet forms.css, but that didn’t help. Specifically overriding min-width and width didn’t do anything either.
Code
HTML of the fieldset:
<fieldset>
<div class="wrapper">
<select id="section" name="section">
<option value="-1"></option>
<option value="1501" selected="selected">Sphinx of black quartz, judge my vow. The quick brown fox jumps over the lazy dog.</option>
<option value="1480">Subcontractor</option>
<option value="3181">Valley</option>
<option value="3180">Ventura</option>
<option value="3220">Very Newest Section</option>
<option value="1481">Visitor</option>
<option value="3200">N/A</option>
</select>
</div>
</fieldset>
My CSS that should be working but isn’t:
fieldset {
/* hide fieldset-specific visual features: */
margin: 0;
padding: 0;
border: none;
}
select {
max-width: 100%;
}
Resetting the width properties to the defaults does nothing:
fieldset {
width: auto;
min-width: 0;
max-width: none;
}
Further CSS in which I try and fail to fix the problem:
/* try lots of things to fix the width, with no success: */
fieldset {
display: block;
min-width: 0;
max-width: 100%;
width: 100%;
text-overflow: clip;
}
div.wrapper {
width: 100%;
}
select {
overflow: hidden;
}
More details
The problem also occurs in this more comprehensive, more complicated jsFiddle example, which is more similar to the web page I’m actually trying to fix. You can see from that that the <select> is not the problem – an inline-block div also fails to resize. Though this example is more complicated, I assume that the fix for the simple case above will also fix this more complicated case.
[Edit: see browser support details below.]
One curious thing about this problem is that if you set div.wrapper { width: 50%; }, the <fieldset> stops resizing itself at the point then the full-size <select> would have hit the edge of the viewport. The resizing happens as if the <select> has width: 100%, even though the <select> looks like it has width: 50%.
If you give the <select> itself width: 50%, that behavior does not occur; the width is simply correctly set.
I don’t understand the reason for that difference. But it may not be relevant.
I also found the very similar question HTML fieldset allows children to expand indefinitely. The asker couldn’t find a solution and guesses that there is no solution apart from removing the <fieldset>. But I’m wondering, if it really is impossible to make the <fieldset> display right, why is that? What in <fieldset>’s spec or default CSS (as of this question) causes this behavior? This special behavior is probably be documented somewhere, since multiple browsers work like this.
Background goal and requirements
The reason I’m trying to do this is as part of writing mobile styles for an existing page with a big form. The form has multiple sections, and one part of it is wrapped in a <fieldset>. On a smartphone (or if you make your browser window small), the part of the page with the <fieldset> is much wider than the rest of the form. Most of the form constrains its width just fine, but the section with the <fieldset> does not, forcing the user to zoom out or scroll right to see all of that section.
I’m wary of simply removing the <fieldset>, as it is generated on many pages in a big app, and I’m not sure what selectors in CSS or JavaScript might depend on it.
I can use JavaScript if I need to, and a JavaScript solution is better than nothing. But if JavaScript is the only way to do this, I’d be curious to hear an explanation for why this is not possible using only CSS and HTML.
Edit: browser support
On the site, I need to support Internet Explorer 8 and later (we just dropped support for IE7), the latest Firefox, and the latest Chrome. This particular page should also work on iOS and Android smartphones. Slightly degraded but still usable behavior is acceptable for Internet Explorer 8.
I retested my broken fieldset example on different browsers. It actually already works in these browsers:
Internet Explorer 8, 9, and 10
Chrome
Chrome for Android
It breaks in these browsers:
Firefox
Firefox for Android
Internet Explorer 7
Thus, the only browser I care about that the current code breaks in is Firefox (on both desktop and mobile). If the code were fixed so it worked in Firefox without breaking it in any other browsers, that would solve my problem.
The site HTML template uses Internet Explorer conditional comments to add classes such .ie8 and .oldie to the <html> element. You can use those classes in your CSS if you need to work around styling differences in IE. The classes added are the same as in this old version of HTML5 Boilerplate.
Update (25 Sept 2017)
The Firefox bug described below is fixed as of Firefox 53 and the link to this answer has finally been removed from Bootstrap's documentation.
Also, my sincere apologies to the Mozilla contributors who had to block removing support for -moz-document partly due to this answer.
The fix
In WebKit and Firefox 53+, you just set min-width: 0; on the fieldset to override the default value of min-content.¹
Still, Firefox is a bit… odd when it comes to fieldsets. To make this work in earlier versions, you must change the display property of the fieldset to one of the following values:
table-cell (recommended)
table-column
table-column-group
table-footer-group
table-header-group
table-row
table-row-group
Of these, I recommend table-cell. Both table-row and table-row-group prevent you from changing width, while table-column and table-column-group prevent you from changing height.
This will (somewhat reasonably) break rendering in IE. Since only Gecko needs this, you can justifiably use #-moz-document—one of Mozilla's proprietary CSS extensions—to hide it from other browsers:
#-moz-document url-prefix() {
fieldset {
display: table-cell;
}
}
(Here's a jsFiddle demo.)
That fixes things, but if you're anything like me your reaction was something like…
What.
There is a reason, but it's not pretty.
The default presentation of the fieldset element is absurd and essentially impossible to specify in CSS. Think about it: the fieldset's border disappears where it's overlapped by a legend element, but the background remains visible! There's no way to reproduce this with any other combination of elements.
To top it off, implementations are full of concessions to legacy behaviour. One such is that the minimum width of a fieldset is never less than the intrinsic width of its content. WebKit gives you a way to override this behaviour by specifying it in the default stylesheet, but Gecko² goes a step further and enforces it in the rendering engine.
However, internal table elements constitute a special frame type in Gecko. Dimensional constraints for elements with these display values set are calculated in a separate code path, entirely circumventing the enforced minimum width imposed on fieldsets.
Again—the bug for this has been fixed as of Firefox 53, so you do not need this hack if you are only targeting newer versions.
Is using #-moz-document safe?
For this one issue, yes. #-moz-document works as intended in all versions of Firefox up until 53, where this bug is fixed.
This is no accident. Due in part to this answer, the bug to limit #-moz-document to user/UA stylesheets was made dependent on the underlying fieldset bug being fixed first.
Beyond this, do not use #-moz-document to target Firefox in your CSS, other resources notwithstanding.³
¹ Value may be prefixed. According to one reader, this has no effect in Android 4.1.2 Stock Browser and possibly other old versions; I have not had time to verify this.
² All links to the Gecko source in this answer refer to the 5065fdc12408 changeset, committed 29ᵗʰ July 2013; you may wish to compare notes with the most recent revision from Mozilla Central.
³ See e.g. SO #953491: Targeting only Firefox with CSS and CSS Tricks: CSS hacks targeting Firefox for widely referenced articles on high-profile sites.
Safari on iOS issue with selected answer
I found the answer from Jordan Gray to be particularly helpful.
However it didn't seem to solve this issue on Safari iOS for me.
The issue for me is simply that the fieldset cannot have an auto width if the element within has a max-width as a % width.
Fix for issue
Simply setting the fieldset to have a 100% width of it's container seems to get around this issue.
Example
fieldset {
min-width: 0;
width: 100%;
}
Please refer to the below for working examples - if you remove the % width off the fieldset or replace it with auto, it will not continue to function.
JSFiddle | Codepen
I’ve struggled for many hours with this, and basically, the browser is applying computed styling that you need to override in your CSS. I forget the exact property that is being set on fieldset elements versus divs (perhaps min-width?).
My best advice would be to change your element to a div, copy the computed styles from your inspector, then change your element back to fieldset and compare the computed styles to find the culprit.
Hope that helps.
Update: Adding display: table-cell helps in non-Chrome browsers.
.fake-select { white-space:nowrap; } caused the fieldset to interpret the .fake-select element by its original width, rather than its forced width (even when the overflow is hidden).
Remove that rule, and change .fake-select's max-width:100% to just width:100% and everything fits. The caveat is that you see all of the content of the fake-select, but I don't think this is all that bad, and it fits horizontally now.
Update: with the current rules in the following fiddle (which contains only real selects), the fieldset's children are constrained to correct widths. Other than removing rules for .fake-select and fixing comments (from // comment to /* comment */, I've noted changes in the fiddle's CSS.
I understand your problem better now, and the fiddle reflects some progress. I set default rules for all <select>s, and reserve .xxlarge for those which you know will be wider than 480px (and this only works because you know the width of #viewport, and can manually add the class to those too wide. Just requires a little bit of testing)
Proof
We've got a really annoying layout problem on our site only in IE (7 & 8 tested), Firefox and Chrome works fine. The problem is on this page:
http://www.foe.co.uk/community/campaigns/climate/rio_resources_33589.html
The problem code is that the report images should appear to the left of the text to the right. We have a simple that contains the item and the a inner floated to the left and another floated to the left too. Both have widths that are less than add up to less than the outer DIV. Here's an example bit of code that isn't working:
<div class="resourceitem">
<div class="resourceleft">
Test LEFT
</div>
<div class="resourceright">
Test RIGHT
</div>
</div>
The relevant CSS is simply:
.resourceitem {
margin-bottom: 10px;
overflow: hidden;
width: 100%;
}
div.resourceleft {
float: left;
margin-left: 20px;
width: 156px;
}
div.resourceright {
float: left;
padding: 0;
width: 268px;
}
Any help is much appreciated, it's driving me bonkers!
Cheers,
Chris.
UPDATE - Fixed it.
Ah. Ok found the problem folks - it's was down to my responsive linking code and IE8's Developer Tools showing rules that don't actually apply. The rules for this were in fms-res.css file but this only gets used on Browsers that understand media queries, and have width > 980px. IE8 uses a default. desktop-only file, called m-equiv.css - the rules were missing from this file. The Web Developer Toolbar very unhelpfully shows the rules as applying to the elements from the fms-res.css file, even though actually they don't. I'd forgotten this effect of Developer Tools, we usually see with our print stylesheet (print.css) rules showing, even though they don't apply (unless when actually printing).
Massive thanks for the contributions folks, sorry it was such a stupid fix in the end.
Cheers!
Remove </a> from the following code It is an extra code (might be a typo) and causing trouble in IE:
<div class="resourceleft">
<img border="0" alt="Rio+20: Is this it?" src="http://www.foe.co.uk/imgs/Rio_-_is_this_it.png" />
</a>
</div>
Note: every <div class="resourceleft"> has an extra </a>
UPDATE - Fixed it.
Ah. Ok found the problem folks - it's was down to my responsive linking code and IE8's Developer Tools showing rules that don't actually apply. The rules for this were in fms-res.css file but this only gets used on Browsers that understand media queries, and have width > 980px. IE8 uses a default. desktop-only file, called m-equiv.css - the rules were missing from this file. The Web Developer Toolbar very unhelpfully shows the rules as applying to the elements from the fms-res.css file, even though actually they don't. I'd forgotten this effect of Developer Tools, we usually see with our print stylesheet (print.css) rules showing, even though they don't apply (unless when actually printing).
Massive thanks for the contributions folks, sorry it was such a stupid fix in the end.
Cheers!
my friend was helping me make a new design for my website but has since gotten a full time job. Web Design is not my strong suit and I can't get it to work across all browsers!
So right now, my website looks good in Chrome and Safari. But is broken in FireFox
http://dl.dropbox.com/u/22866203/sb%202/speedbump.html
http://dl.dropbox.com/u/22866203/sb%202/speedbump.css
I was researching/trying different CSS Resets to fix this problem (Meyers Reset) but this only seemed to break the page in Chrome and Safari as well.
Any suggestions would be much appreciated!
If you started without a reset then a reset is not going to help. You particular problem is that you're not clearing your floats. To solve it do this:
#social-media, hr { clear: both; }
Btw, you have a 404 error on an image and many other warnings. Check firebug or devtools.
As I was messing a bit with your site with firebug, I noticed that if you add to some divs the property float: left it arranges the site to look like it does in chrome.
Download FireBug for firefox (great tool) and arrange the floating divs exactly how you want them to be.
Hope it helps.
Give the #wrapper overflow:hidden and remove margin top from previous and after divs.
The problem is that you have floated elements in the body text (left) and the green box (right) but the parent isn't floated, meaning that the floated elements will not affects it's overall height. Also, don't use hr, instead, use borders.
http://dl.dropbox.com/u/33811812/stackoverflow/speedbump/Speedbump.html
The paths are now relative to my folder and you'll need to change them back.
IDs need to be unique(#wrapper) I see four ( 4 ) instances of it from the image above.
Use a class instead as it can be re-used.
.wrapper:after{
visibility: hidden;
height:0;
display: block;
clear:both;
*zoom:1;
content: '.';
}
I am having trouble with IE7. I have a header, which is an IMG. Under it I have a div that represents a menu, they have to be attached to each other without space in between. Both are 1000px width. In Opera and FireFox the header and the menu are neatly attached to each other. However, in IE7, there is a small space between the menu DIV and the IMG. I have tried explicitly defining padding and margin on the IMG, however it does not work. I have had this problem before, so it seems to be a IE7 quirk.
My HTML Code:
<div id="middle">
<img id="ctl00_headerHolder_headerImage" src="pictures/headers/header_home.jpg" style="border-width:0px;" />
<div id="ctl00_menuPanel" class="menu">
<a id="ctl00_home" href="Default.aspx" style="color:#FFCC33;">Home</a> |
<a id="ctl00_leden" href="Leden.aspx">Leden</a> |
<a id="ctl00_agenda" href="Agenda.aspx">Agenda</a> |
<a id="ctl00_fotos" href="Fotos.aspx">Foto's</a> |
<a id="ctl00_geschiedenis" href="Geschiedenis.aspx">Geschiedenis</a> |
<a id="ctl00_gastenboek" href="Gastenboek.aspx">Gastenboek</a>
</div>
</div>
Try the IE Developer Toolbar, which will let you inspect what is going on with the elements and give you outlines of the areas covered. It might give you a better understanding of the problem.
The solution:
img {
padding: 0px;
margin: 0px;
display: block;
}
display: block
I run into this a lot. Rather than hunting down the specific behavior, try sanity checking by explicity setting padding and margin properties for img/div/etc selectors to 0, set border-style: none border-width: 0px border="0" etc.
IE Dev Toolbar is a must-have but whether it helps you with figuring out single-pixel issues is unlikely.
Instead of resorting to display block, note that IE7 does some seriously odd things with whitespace; try removing the whitespace between the image and the div, and see what happens.
CSS Resets (like the YUI Reset CSS) are great for this kind of thing. They reset paddings, margins, and other display properties on a lot of HTML elements to minimize the display differences.
The solution...display: block
That question couldn't be answered properly without knowing the rendering mode that the browser was in; you need to tell people what doctype you have if you have CSS rendering issues. The image behaviour you refer to is different in quirks mode as opposed to standards mode. A minimal test case must include a full HTML document and the CSS to reproduce the problem. Please don't ask people for help without giving them the information they need to answer easily without wasting their time...
The real solution:
#middle { font-size: 0; line-height: 0; }