I use a Primefaces DataTable to display some data. I also allow filtering and sorting. In Internet Explorer, setting the filter to a value that returns no results (empty table) shrinks the table too much and scroll bars appear:
This is of course very ugly. In all other browsers it works perfectly fine. So this might be a problem with the version of Internet Explorer or Primefaces that I use, but changing those is not really an option.
I probably need some CSS shenanigans to work around this. I tried using height/width and min-height/min-width and also the scrollWidth / scrollHeight and scrollable attributes of the p:dataTable but that didn't to the trick.
Any suggestions?
Edit:
Using Primefaces 6.2.17, Internet Explorer 21H1
While looking through the rendered HTML I noticed that the <div> the dataTable was rendered inside (<div class="ui-datatable-tablewrapper">) had this CSS set:
.ui-datatable-tablewrapper {
overflow: auto;
}
Setting it to overflow: visible; in my .css file solved my problem:
Related
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
I need to print a page in IE8, IE9, and Chrome. It prints perfectly in Chrome, no so well in IE8 (have not tested IE9 yet).
The 3 major problems I'm facing with IE right now are:
Checkbox and radio button width is messed up and it has a border
Extra padding throughout the form, especially between label and field
Internal table borders do not show up, and the first column should be hidden
See the screenshots below. Why is this happening? I can't seem to fix it, I've tried changing the css several times. I know it is reading the CSS though.
Checkbox:
Extra padding everywhere:
No internal table borders:
UPDATE:
The form shows up correctly (table borders shown, padding correct, etc.) in both Chrome and IE. It prints correctly in Chrome. It does not print correctly in IE.
Please do not tell me to print the form another way. I've made a design decision to print it from the browser: it's what's best for my project.
1: You probably have something like
input {border: ...; width: ...}
which affects your checkboxes and radios. At least in Internet Explorer. You can fix this either by using
input[type=radio], input[type=checkbox] {alternating styles}
or by assigning specific classes:
input.radio, input.checkbox {alternating styles}
2: The padding you might get rid of by giving both the input-forms and the label right next to it
text-align: vertical
3: To solve the borders you should provide the CSS for that ;)
I added a simple table with borders to the page to test if IE not displaying table borders, or if my css was some how overridden. When that worked, I realized my table was being selected somewhere else by it's ID (and having it's borders removed). When I tried to add in the borders for printing, I was selecting the table by it's class name not ID.
I also realized the jquery.jqprint plugin was not including the doctype in the iframe it was printing. Now, it prints perfectly in IE8.
I have a WordPress site that I recently moved from one domain to another (using my host's dotnetpanel). When it went live on the new domain, it does not show up correctly in Internet Explorer. Previously, it worked well in all browsers. Specifically, it seems like parts of the stylesheet are just being ignored. It works fine on all browsers tested except IE.
Try putting the code here in and testing to see if it fixes your problem. What parts look like they're being ignored?
Maybe you have to reinstall some of your plug-ins?
I guess there are some wrong paths in the database or config-files.
Try to search database by db-admin-tool and all the files with an advanced text-editor with the option to search automatically in all files at the same time.
As far as I can see the style sheets are applied.
You have width: 100% and height: 100% on the links in the menu, which messes with their size in IE. Remove those styles.
The reason that the gradients doesn't show up is because they are filters, and the elements has to have layout for the filters to apply.
The object that the filter is applied to must have layout before the filter effect will display. You can give the object layout by setting the height or width property, setting the position property to absolute, setting the writingMode property to tb-rl, or setting the contentEditable property to true.
Ref: http://msdn.microsoft.com/en-us/library/ms532997%28v=vs.85%29.aspx
If you give the elements layout, the gradients will show up, for example:
.block h2 { width: 100%; }
For some reason my checkboxes and dropdown arrows are not visible in chrome, however, they still work.
They are perfectly visible in IE. When I load the page in IE, then try loading the page in chrome, they usually appear until I refresh the page again in chrome.
Anyone know what the problem might be?
Reference image: http://i.imgur.com/Q66w6.png
A 'solution' to this Chrome problem is to
open Task Manager
refresh the page in Chrome while the Taks Manager is open in front of the browser.
I couldn't believe this would actually work when I read about it, but I've seen it with my very eyes. This issue apparently exists since the early versions of Chrome and still exists in current versions, though it only occasionally occurs. It seems to be permanently gone after this 'fix'.
In webkit browsers the following code will remove dropdown arrows.
select{
-webkit-appearance:none;
}
Checking in your browsers inspector will indicate if it's being applied in your case or not.
Found this question while having the same problem.
Setting:
input {
width:100%
}
was the cause of the problem for me. This:
input[text] {
width:100%
}
was what I wanted (leave checkbox widths unchanged) -- setting the width of checkboxes in chrome seems to make them disappear.
As user48956 mentioned; setting input width to 100% causes checkboxes to vanish in chrome.
I use bootstrap and often have forms where I want all inputs to stretch 100% and don't want to use bootstraps form methods and this issue still comes up.
If you have defined input {width:100%} you can put a width on the div containing the checkbox and it will fix. e.g.
<div style="display:inline-block; width:20px"><input type="checkbox" name="read_privacy_policy" id="read_privacy_policy" class="pull-left"></div>
<div style="display:inline-block">I have read and understand the Privacy Policy.*</div>
or you can set style="width:auto" on the input itself
I had the same issue
Try this css style supression all style that acts in the input checkbox element.
-webkit-appearance: checkbox!important;
I think it's a bug and it's still there. I use checkboxes in a ligthbox window and they don't show. I'm on OS-X using Chrome 21.
Just finishing up a site and having an issue with position: fixed on IE7. I've Googled it and tried different Doctypes but the fixed area is still moving out of position on IE7.
I've not got IE7 but a client staffer has it and I can see the issue using an online IE renderer/tester.
I've removed the .htaccess from the test site so you can see the site/code.
http://drinkzing.com/test
Any advise or help would be appreciated.
There is a <div> and an <ul> element which both have id="logo-nav". They've both set position:fixed and some other properties. I think this is the main problem. Remove the duplicate ID, set position:fixed only for the <div> element and then we can investigate the issue (or the problem should disappear at best).
If you have newer version of Internet Explorer, you may emulate IE7 by clicking the Compatibility View button or choosing IE7 document mode in Developer Tools.
edit: I noticed that you haven't set any left property for #logo-nav. I don't know why IE7 computes the default position other way than all other browsers, but simply adding #logo-nav { left: 225px } works for me.
Try this in your css:
* html idorclasshere {
position: absolute;
}
Note: replace "idorclasshere" with your, well, ID or Class of the non-responding div (don't worry, due to the asterisk, other browsers aside from IE won't see it, add it in conjunction to your "position:fixed" style).