I've this specific CSS code for Firefox browsers.
#-moz-document url-prefix(){
.bill-tab-fixed-width{
width:104.5px;
}
}
But firefox does not render this value. It instead render the style that I've defined for other browsers! When I inspect the element the value I've defined is strike through. Am I doing this wrong? Please help!
Firefox version 19.0.2
Thank you.
Its basically being overwritten by the other rules. Either move this block below the other rules in the stylesheet or add !important to force it to use this style.
#-moz-document url-prefix(){
.bill-tab-fixed-width{
width:104.5px !important;
}
}
Note: defining pixel values as a decimal is probably not a good idea. It is impossible for a screen to use half of a pixel and browsers can tend to round slightly differently.
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 have seen some people in css write something like
.together
{
display:inline;
display:inline-block;
}
not just restricted to display style, but say background-size or background-image for an example
what is the purpose of this? i mean the second one is going to override the first one, so why bother?
Usually this type of behavior indicates a browser hack for compatibility. When browsers detect a property or value they do not know, they ignore it. Thus, if you place the most widely-accepted properties first, browsers will "fall back" to that behavior if none of the latter properties are compatible.
There's a possibility that it's written that way for browser-compatibility. They probably want the element to have a display value of inline-block, but not all browsers support it on all elements. Sitepoint has a good reference for compatibility of the display property.
The background property is a shorthand for all of the background-related properties, so it's common to set background on one selector and then only overwrite specific background properties later on other selectors. And again, you might have multiple background declarations for browser compatibility.
Lets take the following example.
<html>
<head>
<style>
.carlist
{
background-color: red;
height: 30px;
margin: 10px;
margin: 20px;
}
</style>
</head>
<body onload="loadCars()">
Check div style.
<div id="mydiv" class="carlist"></div>
</body>
</html>
In the above example we have 2 margins declared. I checked and found that the 2nd declaration is accepted by browser(FF,IE,Chrome). So I think if we use this for browser compatibility then the most browser specific style should be declared at last. But there are other ways to define browser specific styles. So its better to have single attribute defined.
I'm working on a site and I have some problems that I hope you guys can help me with :)
If I put bold on my text in the menu it looks too bold in Firefox :S, but it looks fine in Chrome.
In Firefox the double border on the #content container is outside of the shadow effect :S, but looks good in Chrome.
Screen shot on Mac Firefox 5.0.1 and Chrome 13.0.782.112:
This is my project.
I hope some one can help me out with this.
If you have something I better I can do, I will be glad to hear that too :)
Your first issue regarding bold font looking different between the browsers is just because of the way browsers render text differently. There is nothing you can do about it, unless you go the horrible route of using images instead.
Your second issue is not about the border but rather the outline. It is caused because of the way Firefox interprets the outline when box-shadow is applied. It applies it outside of the shadow instead.
You can put the code below in your css to target Firefox and bring the outline back in:
#-moz-document url-prefix() {
#content{
outline-offset: -11px;
}
}
Live example: http://jsfiddle.net/tw16/n8bet/
#1: There differences in font rendering in every browser. You can try numeric values instead of simply bold to narrow the results ( http://clagnut.com/blog/2228/ ). Also read the answer on this SO entry: Same font except its weight seems different on different browsers
#2: remove this line from #content css:
outline: 1px solid #B9BDBE;
I have been asked to fix up some CSS that another worker in our company created. The code contains the following:
div#bwrap {
position: absolute; bottom:35px; left:120px; right: 60px; height:10px;
} body>div#bwrap {position:fixed;}
and:
div#mwrap {
margin-left:0;
voice-family: "\"}\"";
voice-family:inherit;
margin-left:16px;padding: 85px 60px 35px 240px;
font-family: Segoe UI,Tahoma,Verdana,Arial,sans-serif;
} body > div#mwrap { height: 500px; margin-left:0; }
I understand this code is for older browsers but does anyone know which ones it fixes problems for. If for example it is for IE6 or earlier then our company no longer uses that browser.
Do I still need the:
body>div#bwrap {position:fixed;}
and
voice-family: "\"}\"";
voice-family:inherit;
IE6 doesn't support the > selector, so the references to body>div#bwrap won't work in IE6.
Since they are effectively identical to the main selectors above them div#bwrap, this implies that the bits inside the body>div#bwrap are overrides for browsers other than IE6.
In the first example, IE6 would produce an element positioned absolute, whereas all other browsers would position it fixed. If you are no longer supporting IE6, you can therefore move that style into the main div#bwrap selector and remove the body>div#bwrap one.
You can find out more about supported CSS selectors in various browsers here: http://quirksmode.org/css/contents.html
The voice-family bit is a hack which tells the hacked browser to ignore the rest of the styles in the selector. It is also IE6-specific, so if again if you're dropping IE6 support, you can drop the hack. You can find out more about this hack here: http://tantek.com/CSS/Examples/boxmodelhack.html
The second example also has a matching > selector, which you need to treat in the same way as the first example, although the margin-left is specified in both anyway (since they're using this method of separating IE6, I don't know why they bothered with the voice-family hack as well).
The voice-family/box model hack is definitely for old browsers (like IE5, old). More info on that can be found here.
The positioning thing I'm not sure about. Here's some information that might pertain to it. Specifically, the "IE >= 6" portion, where it mentions a hack and notes that it breaks position: absolute;. Without context, and given the format, I'd assume it's an older one, though, too. I'd say comment it out and check IE7/8 to see if it affects it. I think IE8 has developer tools (like Firefox's Firebug plugin), I'm not sure about IE7, though, but you can check them, too, if they're available.
My comment may be redundant but here are my points to take into account:
div#bwrap (You usually don't need the 'div' bit, it's cleaner to omit it.)
The voice-family part is, as mentioned, a really old hack and should be removed
If you're explicitly not supporting IE6 you may not need the child selector ">" at all
Position fixed doesn't work some webkit browsers like Mobile Safari
If you do need to support IE6 then the child selector is your best friend:
#bwrap { ... all browsers - including ie6 ... }
html > body #bwrap { ... modern override: Firefox, safari, opera, ie7+ ... }
Only implement the 'modern override' if you really really need to fix it in IE6.
HI guys,
I'm having a problem trying to change the default textfield of file_field_tag on chrome and FF, it works fine on IE but on the other browsers it is not applying the size.
My code is.
file_field_tag "#{ compliance.id }_document" , :size => '2
Dont know if i might be doing something wrong but i am sure its a very small thing that i have missed.
Thanks in advance
The HTML 4.01 specification says that this attribute, in case of <input type="file">, defines the width in pixels, not in characters.
http://www.w3.org/TR/html4/interact/forms.html#h-17.4
Besides that, you should use a CSS for width definition. You have two options: use an inline style:
file_field_tag "#{compliance.id}_document", :style="width: 2em"
or (preferable) add a class to the tag, and the CSS definitions place in your stylesheet:
file_field_tag "#{compliance.id}_document", :class="short"
/* CSS */
input.short {
width: 2em;
}
/* ..or if you expect some intelligent browsers, you may be more specific: */
input[type='file'].short {
width: 2em;
}
You may need to experiment a little, since file controls may refuse to accept your width. The default stylesheet rules of every browser may define some other rules, stronger than your ones.
For Firefox you may see the definitions in a file forms.css. On my system the location is /usr/lib64/xulrunner-1.9.2/res/forms.css.
There is a definition, which may help you:
input[type="file"] > input[type="text"] {
....
Define a width for input[type="file"].short > input[type="text"] and you should be OK. Note however, that this rule may be changed in every version of the browser.