This question is geared towards CSS3, I've been looking at a few boilerplate templates and guides and most of them declare a whole lot of attributes before even going into what you want to edit.
Why is this so? Does declaring all of the usable attributes make the
browser load faster or something?
What are the benefits? Why not just use CSS3 "as is" (like just declaring what's being used in the HTML section)?
And if the underlying attribute changes in further editions, wouldn't
it mean you would have to constantly keep a check on deprecated
attributes and keep declaring and changing attributes every once in a while?
HTML5Boilerplate contains a version of normalize.css. Rather than just reset everything to 0 (i.e. margins, padding etc) it has the minimum set of changes to ensure things have the same settings in all browsers. In their own words:
“Normalize.css is a customisable CSS file that makes browsers render
all elements more consistently and in line with modern standards. We
researched the differences between default browser styles in order to
precisely target only the styles that need normalizing.”
An example of a style used here is:
/*
* 1. Correct text resizing oddly in IE6/7 when body font-size is set using em units
* 2. Prevent iOS text size adjust on device orientation change, without disabling user zoom: h5bp.com/g
*/
html {
font-size: 100%;
-webkit-text-size-adjust: 100%;
-ms-text-size-adjust: 100%;
}
This fixes some weirdness in older IE, as well as on iOS. This is the sort of thing that you'll likely have a problem with, read loads, find a solution and add in eventually yourself. By using this set of defaults you can avoid a lot of weirdness.
As well as bugs, it includes things you'd likely want anyway:
nav ul,
nav ol {
list-style: none;
list-style-image: none;
margin: 0;
padding: 0;
}
Using a ul in a nav is a common pattern, and you usually don't want bullet points there. This sorts that for you.
In all, I'd recommend using your own custom version of their code – it will save you a lot of annoyance!
Also if you want to add CSS3 functionality you can add it to ie5 with javascript(not to say this doesn't come with its cons) with html5shiv or html5shim .
Also lets examine the definition of the acronym CSS. Cascading Style Sheets. You may declare styles in order of fall back. i. e.
body {
style-1: new browsers (this renders yay!)
style-2: semi-new browsers (don't understand style-1 I will ignore ahh style2)
style-3: ie5(me want to crash soon or BOD you. but me not get either 1 or 2 they smart but i think i can work on style 3)
Related
I found this reset.css file inside a jquery image slider demo, but it was never included in the main index.html file. what is is suppose to do, and more importantly, where do you put it? Do you put it before any referenced stylesheets()?
Here is the code inside reset.css
/* CSS reset */
body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,fieldset,input,textarea,p,blockquote,th,td {
margin:0;
padding:0;
}
html,body {
margin:0;
padding:0;
}
table {
border-collapse:collapse;
border-spacing:0;
}
fieldset,img {
border:0;
}
input{
border:1px solid #b0b0b0;
padding:3px 5px 4px;
color:#979797;
width:190px;
}
address,caption,cite,code,dfn,th,var {
font-style:normal;
font-weight:normal;
}
ol,ul {
list-style:none;
}
caption,th {
text-align:left;
}
h1,h2,h3,h4,h5,h6 {
font-size:100%;
font-weight:normal;
}
q:before,q:after {
content:'';
}
abbr,acronym { border:0;
}
In the beginning, there was no standardisation on how styles worked, each browser implemented what it felt was right. One of the reasons you see so many questions about style errors in IE is because IE was the browser with the most dissimilarities from other browsers in terms of styling. Though IE has improved and so have other browsers they still apply their own borders, padding and margins, zoom, fonts to elements to give their own unique feel to pages. One example is, chrome gives its own yellow borders to text boxes. The "reset" actually "resets" all these styles to zero/none, so that you don't see any styles you haven't applied to your page.
If these styles are not "reset", you will see unwanted styles/effects and things breaking. Its generally recommended to "reset" the browser's styles.
Have a look at this article Should you Reset Your CSS?
reset.css is used to normalize browser's default styles.
Example:
Looking at the answers here there seems to be a bit of mixup between "reset" and "normalize". Their goals are slightly different.
A CSS reset is a set of styles you load prior to your other styles, to remove browser built-in styles. One of first and most popular ones was Eric Mayer's Reset CSS.
Another option is to harmonize browser built-in styles. The most popular tool to achieve this is currently Normalize.css.
Browser have different "built-in" styles which they apply to different html-elements. These styledefinitions may vary accross different browsers. The normalizing css files are meant to „normalize“ the rendering of the page across browsers by resetting these browser-specific styes.
You have to include it before your own style definitions. Otherwise these styles would possibly override (due to the cascading nature of css) your declarations too, which wouldn't make much sense;)
The most popular styles reset is probably Eric Meyer's which comes along with a little background information..
Browsers may render the HTML and CSS received according to its native rendering engine. Different browsers may use different rendering approaches [IE ;) if you know what i mean] so the intension of reset.css is to set all the attributes to common predefined values so the developers/ designers are can forget some rendering engine and start development from the scratch.
A CSS Reset (or “Reset CSS”) is a short, often compressed (minified)
set of CSS rules that resets the styling of all HTML elements to a
consistent baseline.
In case you didn’t know, every browser has its own default ‘user
agent’ stylesheet, that it uses to make unstyled websites appear more
legible. For example, most browsers by default make links blue and
visited links purple, give tables a certain amount of border and
padding, apply variable font-sizes to H1, H2, H3 etc. and a certain
amount of padding to almost everything. Ever wondered why Submit
buttons look different in every browser?
Obviously this creates a certain amount of headaches for CSS authors,
who can’t work out how to make their websites look the same in every
browser.
Using a CSS Reset, CSS authors can force every browser to have all its
styles reset to null, thus avoiding cross-browser differences as much
as possible
refer http://www.cssreset.com/what-is-a-css-reset/
Every browser has its own default user agent stylesheet, that it uses to make unstyled websites appear more legible. For example, most browsers by default make links blue and visited links purple, give tables a certain amount of border and padding, apply variable font-sizes to H1, H2, H3, etc. and a certain amount of padding to almost everything.
Ever wondered why Submit buttons look different in every browser?
Obviously this creates a certain amount of headaches for CSS authors, who can’t work out how to make their websites look the same in every browser.
Using a CSS Reset, CSS authors can force every browser to have all its styles reset to null, thus avoiding cross-browser differences as much as possible.
From the consistent base that you’ve set up via your reset, you can then go on to re-style your document, safe in the knowledge that the browsers’ differences in their default rendering of HTML can’t touch you!
Hopefully it helped, you may want to take a look at this article, Which CSS Reset Should I Use?.
In simple words CSS reset is required due to browsers’ inconsistency. In detail all browsers rendering are not the same. Therefore web rendering could be different from browser to browser.
Meyer Web providing a utmost CSS reset code if you're want to use/reset. You can find it here. If you need more details, here also you can find out what CSS reset in more details and why we need to use it.
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
One strange thing I've noticed when trying to normalize my css across browsers is that default line-height properties for h-elements and other major tag types are different across browsers like Chrome and Firefox, and yet are not set at the user-agent level:
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/css/html.css
http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css
Moreover, popular normalizers like normalize.css don't take care of that either.
So my question is two parts:
If line-heights aren't set at the user agent level, where are the default values coming from?
I'd rather not normalize line-heights myself, but if I have to, where is a good example of some defaults?
I agree that "things aren't meant to be exactly the same" is somewhat of a cop-out, especially as even IE comes on board with pretty good standards adoption.
Relative (120%, 1, 1em) line-height values are based on the computed font-size, Normal is supposed to be based on font size but it can and does vary from browser to browser, as you can see by opening up this example in FF and Chrome: http://jsfiddle.net/mahalie/BSMZe/6/
I generally look to HTML5 Boilerplate for queues on best practices since it is so popular (and therefore well vetted / under a lot of scrutiny. They use:
body { margin: 0; font-size: 13px; line-height: 1.231; }
And their discussion of it is quite interesting although no perspective is the clear winner:
https://github.com/h5bp/html5-boilerplate/issues/724
I understand that elements can have multiple classes:
.rfrsh-btn {
background-image:url(../../upload/rfrsh_nb_grey.png);
...
}
.submit
{
font-size: 0.85em;
padding: 0;
}
This was working perfectly as an ID before. now I changed it to a class and lo and behold, no images.
But for some reason this <button> element doesn't seem to want to display with a background image and styles applied.
Is there a reason for this? Or am I codeblind and doing something wrong.
I can't use ID either as it's repeated many times on the page.
Thanks all :)
There are several reasons. For instance, it's quite possible your image path is not correct. It 's worth noting that paths in CSS are relative to the .css file 's location, and not to the including page.
To better understand what's going on now and in the future, however, I recommend either working with Chrome, which offers a nice set of debugging tools, or use Firefox with Firebug installed. This way you can inspect your elements and see what styles get applied, overlapped, or any images the browser cannot locate.
For more information: http://www.thetruetribe.com/2008/03/firebug-tutorial-getting-started/
Underscores in class names can cause issues. Try renaming rfrsh_btn.
https://developer.mozilla.org/en/Underscores_in_class_and_ID_Names
I am testing a web site on Chrome, Firefox and Internet Explorer using the following in a CSS file.
#foot_links1, #foot_links2, #foot_links3 {
position: absolute;
margin-top: 55px;
margin-top: 14em;
color: #02102f;
font-family: Arial;
}
#foot_links1 {
left: 335px;
}
#foot_links2 {
left: 630px;
}
#foot_links3 {
left: 830px;
}
The foot_links1, foot_links2 and foot_links3 all are in one straight line, but the placement of the foot_links1, foot_links2, foot_links3 placement varies with the browser.
How can I correct this?
I suggest using a reset stylesheet.
A reset stylesheet will reduce browser inconsistencies like default line heights, margins and font sizes of headings.
You may also want to check the following articles for further reading:
CSS Tip #1: Resetting Your Styles with CSS Reset
Mayerweb: Reset Reasoning
Stack Overflow: Is it ok to use a css reset stylesheet?
Stack Overflow: Best css reset
Ensure you have this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
This will change the Internet Explorer behaviour boxing model in Internet Explorer 7 or earlier
Ensure that the first rule of all is:
body *{
padding:0;
margin:0;
}
(Maybe it is not a good idea to append this after you already written all the CSS, instead you could use a more specific rute that aims the place.)
Start by ensuring you're running a proper doctype, and check whether the site validates at http://validator.w3.org/
A proper doctype would be xhtml transitional or html 4 strict (html 4 transitional usually makes IE do things differently)
As for reset stylesheets - yes they can be useful, however I try to avoid them, since you're pushing more kbs to your users (longer load times, especially if your webhotel isn't zipping css), and furthermore you're slowing down the browsers rendering, because there are more css rules it has to process.
Finally it just seems hackish to me - I mean you can make it look right without resorting to resetting all sorts of stuff, so why do it ?
You did not say how the placement varies.
I made a quick test with IE8 and Opera and there were some difference in vertical placement.
I fixed that by adding the top property (and removed the 2nd margin-top). For example:
margin-top: 1em;
top: 55px;
But generally, it is not good idea to try and force a specific look. Web page is not printed media.
The users have different preferences, different display devices and they do not all have the same fonts etc. installed.
Although what other people have suggested are all good advice, as a direct answer to your question, use "padding-top" instead of "margin-top" and ensure your divs have a height set. That should get you quite close, or all the way there.