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.
I have seen multiple approaches to web typography that suggested setting the base font-size (on either the html or body element) to a precise pixel value, or a percentage (62,5% for example, for easy sizing with em, or 100%).
I'm researching whether this is still necessary, when sizing type with rem. My idea is that when working with > IE9, rem is an easy way to size type based on the users preferred base font-size. So it is:
Good for accessibility (i.e. not overriding the users preferences)
Easy to design with (the values don't cascade, and the entire design can be sized up or down, so it's fluid)
But since there are so many recommendations, I'm wondering: is there something I'm missing? What is the current state of affairs regarding font-sizing? Are there accessibility concerns with my approach, things I haven't thought of? Just looking for source material that deals with this issue, from the standpoint of the current state of affairs, not opinions.
rem is based on your root element, or html tag size, so giving that a size is advised. I wouldn't wonder about 'user preference', since most modern browser will just enlarge everything uniformly. So the golden rule is to set your html size to your base value in pixels:
html { font-size: 12px; }
simply because it's easy to calculate from there. After that, set every subsequent font value like this:
.element {
font-size: 12px;
font-size: 1em;
font-size: 1rem;
}
It seems quite extensive, but it allows for maximum compatibility. Accessibility wise it's not a concern, as increasing size of your font in the browser will increase the original 12px in your html, and will enlarge the rest subsequently.
I have been searching for an answer for this for an hour now with no luck.
I am centering text vertically inside the box using the "line-height" CSS property. This is working fine with standard safe fonts and also works fine for ""#font-face"" font embedding on Windows.
On the Mac however, there is a problem with this centering using "#font-face". See: http://cl.ly/QBlE/o
I don't know what to do with this. The only way to fix this to use different line-height for Mac. But as far as I know this is not possible without JavaScript or server side programming and does not seem to be the proper solution for me.
Example (blue box at the top):
#header .login {
text-decoration:none;
margin:11px 9px 0 9px;
float:right;
font-size:11px;
color:#fff;
background:url(../img/header-login.png);
width:118px;
height:26px;
line-height:26px;
padding:0 0 0 10px;
text-transform:uppercase;
font-family: 'Helvetica55', Sans-Serif;
}
Instead of using different line heights, try using the font-size-adjust property with a value of auto.
From the W3C:
In situations where font fallback occurs, fallback fonts may not share the same aspect ratio as the desired font family and will thus appear less readable. The font-size-adjust property is a way to preserve the readability of text when font fallback occurs. It does this by adjusting the font-size so that the x-height is the same regardless of the font used.
First, try setting the line-height from px to em.
If that doesn't work, then it could be caused by default styles that are different for each browser. Those default styles could be messing with your styles. So try to use a reset.css in your page.
The problem most probably lies in the used font. Each font has its own metrics and when not optimized properly they can differ from one platform to another. See http://blog.typekit.com/2010/07/14/font-metrics-and-vertical-space-in-css/ for a better explanation of this.
You could try to alter the font yourself using a tool like http://fontforge.org/. This isn't easy though and takes some trial and error to get it right. It may also violate the license of the font you're using.
My advice: choose a font that is better optimized for use on the web. Take any font from Typekit or the like and i bet you get more consistent results.
Perhaps 'vertical-align:' may help,
please check this fiddle
this will explain the difference, I think every browser have different default value,
here I have created 4 different span tag to show the top, middle, bottom, and default(unassigned) value of the vertical align value,
Please change values if that helps,
as you are using images in the button, please verify the image are set with 0 0
i.e background:url(../img/header-login.png) no-repeat 0 0;
this will render the image from the 0 left and 0 top that will help you idnetify if and image is not properly generated..
Please reply if problem not solved..
From my experience for multi browser and multi platform websites you should really drop the pixels in fonts and start using ems.
Here's a useful convertion table tool:
http://pxtoem.com/
Let me know if it still happens using em. Keep in mind also that different fonts have different behaviors and the default (base) size may differ too. If you want to make sure it is exactly the same size, appart from using 'em' you should also use an openType font and embbed it into your CSS, having exactly the same font and size in any screen or browser.
Operating systems may render fonts different ways. One can start from bottom and other can start from top as their algorithm different. If the problem was CSS, it wouldn't be resolved by another type of font.
I found another question similiar to your one, you can check if it works for your situation:
Mac vs. Windows Browser Font Height Rendering Issue
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am designing a new website and I want it to be compatible with as much browsers and browser settings as possible. I am trying to decide what unit of measurement I should use for the sizes of my fonts and elements, but am unable to find a conclusive answer.
My question is: should I use px or rem in my CSS?
So far I know that using px isn't compatible with users who adjust their base font size in their browser.
I've disregarded ems because they are more of a hassle to maintain, compared to rems, as they cascade.
Some say that rems are resolution independent and therefore more desirable. But others say that most modern browsers zoom all elements equally anyway, so using px is not a problem.
I'm asking this because there are a lot of different opinions as to what is the most desirable measure of distance in CSS, and I am not sure which is best.
TL;DR: use px.
The Facts
First, it's extremely important to know that per spec, the CSS px unit does not equal one physical display pixel. This has always been true – even in the 1996 CSS 1 spec.
CSS defines the reference pixel, which measures the size of a pixel on a 96 dpi display. On a display that has a dpi substantially different than 96dpi (like Retina displays), the user agent rescales the px unit so that its size matches that of a reference pixel. In other words, this rescaling is exactly why 1 CSS pixel equals 2 physical Retina display pixels.
That said, up until 2010 (and the mobile zoom situation notwithstanding), the px almost always did equal one physical pixel, because all widely available displays were around 96dpi.
Sizes specified in ems are relative to the parent element. This leads to the em's "compounding problem" where nested elements get progressively larger or smaller. For example:
body { font-size:20px; }
div { font-size:0.5em; }
Gives us:
<body> - 20px
<div> - 10px
<div> - 5px
<div> - 2.5px
<div> - 1.25px
The CSS3 rem, which is always relative only to the root html element, is now supported on 99.67% of all browsers in use.
The Opinion
I think everyone agrees that it's good to design your pages to be accommodating to everyone, and to make consideration for the visually impaired. One such consideration (but not the only one!) is allowing users to make the text of your site bigger, so that it's easier to read.
In the beginning, the only way to provide users a way to scale text size was by using relative size units (such as ems). This is because the browser's font size menu simply changed the root font size. Thus, if you specified font sizes in px, they wouldn't scale when changing the browser's font size option.
Modern browsers (and even the not-so-modern IE7) all changed the default scaling method to simply zooming in on everything, including images and box sizes. Essentially, they make the reference pixel larger or smaller.
Yes, someone could still change their browser default stylesheet to tweak the default font size (the equivalent of the old-style font size option), but that's a very esoteric way of going about it and I'd wager nobody1 does it. (In Chrome, it's buried under the advanced settings, Web content, Font Sizes. In IE9, it's even more hidden. You have to press Alt, and go to View, Text Size.) It's much easier to just select the Zoom option in the browser's main menu (or use Ctrl++/-/mouse wheel).
1 - within statistical error, naturally
If we assume most users scale pages using the zoom option, I find relative units mostly irrelevant. It's much easier to develop your page when everything is specified in the same unit (images are all dealt with in pixels), and you don't have to worry about compounding. ("I was told there would be no math" – there's dealing with having to calculate what 1.5em actually works out to.)
One other potential problem of using only relative units for font sizes is that user-resized fonts may break assumptions your layout makes. For example, this might lead to text getting clipped or running too long. If you use absolute units, you don't have to worry about unexpected font sizes from breaking your layout.
So my answer is use pixel units. I use px for everything. Of course, your situation may vary, and if you must support IE6 (may the gods of the RFCs have mercy on you), you'll have to use ems anyway.
I would like to praise josh3736's answer for providing some excellent historical context. While it's well articulated, the CSS landscape has changed in the almost five years since this question was asked. When this question was asked, px was the correct answer, but that no longer holds true today.
tl;dr: use rem
Unit Overview
Historically px units typically represented one device pixel. With devices having higher and higher pixel density this no longer holds for many devices, such as with Apple's Retina Display.
rem units represent the root em size. It's the font-size of whatever matches :root. In the case of HTML, it's the <html> element; for SVG, it's the <svg> element. The default font-size in every browser* is 16px.
On Using px
The majority of CSS examples on the internet use px values because they were the de-facto standard. pt, in and a variety of other units could have been used in theory, but they didn't handle small values well as you'd quickly need to resort to fractions, which were longer to type, and harder to reason about.
If you wanted a thin border, with px you could use 1px, with pt you'd need to use 0.75pt for consistent results, and that's just not very convenient.
On Using rem
rem's default value of 16px isn't a very strong argument for its use. Writing 0.0625rem is worse than writing 0.75pt, so why would anyone use rem?
There are two parts to rem's advantage over other units.
User preferences are respected
You can change the apparent px value of rem to whatever you'd like
Respecting User Preferences
Browser zoom has changed a lot over the years. Historically many browsers would only scale up font-size, but that changed pretty rapidly when websites realized that their beautiful pixel-perfect designs were breaking any time someone zoomed in or out. At this point, browsers scale the entire page, so font-based zooming is out of the picture.
Respecting a user's wishes is not out of the picture. Just because a browser is set to 16px by default, doesn't mean any user can't change their preferences to 24px or 32px to correct for low vision or poor visibility (e.x. screen glare). If you base your units off of rem, any user at a higher font-size will see a proportionally larger site. Borders will be bigger, padding will be bigger, margins will be bigger, everything will scale up fluidly.
If you base your media queries on rem, you can also make sure that the site your users see fits their screen. A user with font-size set to 32px on a 640px wide browser, will effectively be seeing your site as shown to a user at 16px on a 320px wide browser. There's absolutely no loss for responsive web design (RWD) in using rem.
Changing Apparent px Value
Because rem is based on the font-size of the :root node, if you want to change what 1rem represents, all you have to do is change the font-size:
:root {
font-size: 100px;
}
body {
font-size: 1rem;
}
<p>Don't ever actually do this, please</p>
Whatever you do, don't set the :root element's font-size to a px value.
If you set the font-size on html to a px value, you've blown away the user's preferences without a way to get them back.
If you want to change the apparent value of rem, use % units.
The math for this is reasonably straight-forward.
The apparent font-size of :root is 16px, but lets say we want to change it to 20px. All we need to do is multiply 16 by some value to get 20.
Set up your equation:
16 * X = 20
And solve for X:
X = 20 / 16
X = 1.25
X = 125%
:root {
font-size: 125%;
}
<p>If you're using the default font-size, I'm 20px tall.</p>
Doing everything in multiples of 20 isn't all that great, but a common suggestion is to make the apparent size of rem equal to 10px. The magic number for that is 10/16 which is 0.625, or 62.5%.
:root {
font-size: 62.5%;
}
<p>If you're using the default font-size, I'm 10px tall.</p>
The problem now is that your default font-size for the rest of the page is set way too small, but there's a simple fix for that: Set a font-size on body using rem:
:root {
font-size: 62.5%;
}
body {
font-size: 1.6rem;
}
<p>I'm the default font-size</p>
It's important to note, with this adjustment in place, the apparent value of rem is 10px which means any value you might have written in px can be converted directly to rem by bumping a decimal place.
padding: 20px;
turns into
padding: 2rem;
The apparent font-size you choose is up to you, so if you want there's no reason you can't use:
:root {
font-size: 6.25%;
}
body {
font-size: 16rem;
}
and have 1rem equal 1px.
So there you have it, a simple solution to respect user wishes while also avoiding over-complicating your CSS.
Wait, so what's the catch?
I was afraid you might ask that. As much as I'd like to pretend that rem is magic and solves-all-things, there are still some issues of note. Nothing deal-breaking in my opinion, but I'm going to call them out so you can't say I didn't warn you.
Media Queries (use em)
One of the first issues you'll run into with rem involves media queries. Consider the following code:
:root {
font-size: 1000px;
}
#media (min-width: 1rem) {
:root {
font-size: 1px;
}
}
Here the value of rem changes depending on whether the media-query applies, and the media query depends on the value of rem, so what on earth is going on?
rem in media queries uses the initial value of font-size and should not (see Safari section) take into account any changes that may have happened to the font-size of the :root element. In other words, it's apparent value is always 16px.
This is a bit annoying, because it means that you have to do some fractional calculations, but I have found that most common media queries already use values that are multiples of 16.
| px | rem |
+------+-----+
| 320 | 20 |
| 480 | 30 |
| 768 | 48 |
| 1024 | 64 |
| 1200 | 75 |
| 1600 | 100 |
Additionally if you're using a CSS preprocessor, you can use mixins or variables to manage your media queries, which will mask the issue entirely.
Safari
Unfortunately there's a known bug with Safari where changes to the :root font-size do actually change the calculated rem values for media query ranges. This can cause some very strange behavior if the font-size of the :root element is changed within a media query. Fortunately the fix is simple: use em units for media queries.
Context Switching
If you switch between projects various different projects, it's quite possible that the apparent font-size of rem will have different values. In one project, you might be using an apparent size of 10px where in another project the apparent size might be 1px. This can be confusing and cause issues.
My only recommendation here is to stick with 62.5% to convert rem to an apparent size of 10px, because that has been more common in my experience.
Shared CSS Libraries
If you're writing CSS that's going to be used on a site that you don't control, such as for an embedded widget, there's really no good way to know what apparent size rem will have. If that's the case, feel free to keep using px.
If you still want to use rem though, consider releasing a Sass or LESS version of the stylesheet with a variable to override the scaling for the apparent size of rem.
* I don't want to spook anyone away from using rem, but I haven't been able to officially confirm that every browser uses 16px by default. You see, there are a lot of browsers and it wouldn't be all that hard for one browser to have diverged ever so slightly to, say 15px or 18px. In testing, however I have not seen a single example where a browser using default settings in a system using default settings had any value other than 16px. If you find such an example, please share it with me.
This article describes pretty well the pros and cons of px, em, and rem.
The author finally concludes that the best method is probably to use both px and rem, declaring px first for older browsers and redeclaring rem for newer browsers:
html { font-size: 62.5%; }
body { font-size: 14px; font-size: 1.4rem; } /* =14px */
h1 { font-size: 24px; font-size: 2.4rem; } /* =24px */
Yes, REM and PX are relative yet other answers have suggested to go for REM over PX, I would also like to back this up using an accessibility example.
When user sets different font-size on browser, REM automatically scale up and down elements like fonts, images etc on the webpage which is not the case with PX.
In the below gif left side text is set using font size REM unit while right side font is set by PX unit.
As you can see that REM is scaling up/down automatically when I resize
the default font-size of webpage.(bottom-right side)
Default font-size of a webpage is 16px which is equal to 1 rem (only for default html page i.e. html{font-size:100%}), so, 1.25rem is equal to 20px.
P.S: who else is using REM? CSS Frameworks! like Bootstrap 4, Bulma CSS etc, so better get along with it.
As a reflex answer, I would recommend using rem, because it allows you to change the "zoom level" of the whole document at once, if necessary. In some cases, when you want the size to be relative to the parent element, then use em.
But rem support is spotty, IE8 needs a polyfill, and Webkit is exhibiting a bug. Moreover, sub-pixel calculation can cause things such as one pixel lines to sometimes disappear. The remedy is to code in pixels for such very small elements. That introduces even more complexity.
So, overall, ask yourself whether it's worth it - how important and likely it is that you change the "zoom level" of the whole document within CSS?
For some cases it's yes, for some cases it'll be no.
So, it depends on your needs, and you have to weight pros and cons, because using rem and em introduces some additional considerations in comparison to the "normal" pixel-based workflow.
Keep in mind that it's easy to switch (or rather convert) your CSS from px to rem (JavaScript is another story), because the following two blocks of CSS code would produce the same result:
html {
}
body {
font-size:14px;
}
.someElement {
width: 12px;
}
html {
font-size:1px;
}
body {
font-size:14rem;
}
.someElement {
width: 12rem;
}
josh3736's answer is a good one, but to provide a counterpoint 3 years later:
I recommend using rem units for fonts, if only because it makes it easier for you, the developer, to change sizes. It's true that users very rarely change the default font size in their browsers, and that modern browser zoom will scale up px units. But what if your boss comes to you and says "don't enlarge the images or icons, but make all the fonts bigger". It's much easier to just change the root font size and let all the other fonts scale relative to that, then to change px sizes in dozens or hundreds of css rules.
I think it still makes sense to use px units for some images, or for certain layout elements that should always be the same size regardless of the scale of the design.
Caniuse.com may have said that only 75% of browsers when josh3736 posted his answer in 2012, but as of March 27 they claim 93.78% support. Only IE8 doesn't support it among the browsers they track.
I've found the best way to program the font sizes of a website are to define a base font size for the body and then use em's (or rem's) for every other font-size I declare after that. That's personal preference I suppose, but it's served me well and also made it very easy to incorporate a more responsive design.
As far as using rem units go, I think it's good to find a balance between being progressive in your code, but to also offer support for older browsers. Check out this link about browser support for rem units, that should help out a good amount on your decision.
pt is similar to rem, in that it's relatively fixed, but almost always DPI-independent, even when non-compliant browsers treat px in a device-dependent fashion. rem varies with the font size of the root element, but you can use something like Sass/Compass to do this automatically with pt.
If you had this:
html {
font-size: 12pt;
}
then 1rem would always be 12pt. rem and em are only as device-independent as the elements on which they rely; some browsers don't behave according to spec, and treat px literally. Even in the old days of the Web, 1 point was consistently regarded as 1/72 inch--that is, there are 72 points in an inch.
If you have an old, non-compliant browser, and you have:
html {
font-size: 16px;
}
then 1rem is going to be device-dependent. For elements that would inherit from html by default, 1em would also be device-dependent. 12pt would be the hopefully guaranteed device-independent equivalent: 16px / 96px * 72pt = 12pt, where 96px = 72pt = 1in.
It can get pretty complicated to do the math if you want to stick to specific units. For example, .75em of html = .75rem = 9pt, and .66em of .75em of html = .5rem = 6pt. A good rule of thumb:
Use pt for absolute sizes. If you really need this to be dynamic relative to the root element, you're asking too much of CSS; you need a language that compiles to CSS, like Sass/SCSS.
Use em for relative sizes. It's pretty handy to be able to say, "I want the margin on the left to be about the maximum width of a letter," or, "Make this element's text just a bit bigger than its surroundings." <h1> is a good element on which to use a font size in ems, since it might appear in various places, but should always be bigger than nearby text. This way, you don't have to have a separate font size for every class that's applied to h1: the font size will adapt automatically.
Use px for very tiny sizes. At very small sizes, pt can get blurry in some browsers at 96 DPI, since pt and px don't quite line up. If you just want to create a thin, one-pixel border, say so. If you have a high-DPI display, this won't be obvious to you during testing, so be sure to test on a generic 96-DPI display at some point.
Don't deal in subpixels to make things fancy on high-DPI displays. Some browsers might support it--particularly on high-DPI displays--but it's a no-no. Most users prefer big and clear, though the web has taught us developers otherwise. If you want to add extended detail for your users with state-of-the-art screens, you can use vector graphics (read: SVG), which you should be doing anyway.
Half (but only half) snarky answer (the other half is bitter disdain of the reality of bureaucracy):
Use vh
Everything is always sized to browser window.
Always allow scroll down, but disable horizontal scroll.
Set body width to be a static 50vh, and never code css that floats or breaks out of the parent div. (If they try to mock up something that looks like it does, clever use of a background gif can throw them off track.) And style only using tables so everything is held rigidly into place as expected. Include a javascript function to undo any ctrl+/- activity the user may do.
Users will hate you, because the site doesn't flow differently based on what they're using (such as text being too small to read on phones). Your coworkers will hate you because nobody in their right mind does this and it will likely break their work (though not yours). Your programming professors will hate you because this is not a good idea. Your UX designer will hate you because it will reveal the corners they cut in designing UX mock-ups that they have to do in order to meet deadlines.
Nearly everyone will hate you, except the people who tell you to make things match the mock-up and to do so quickly. Those people, however (which generally include the project managers), will be ecstatic by your accuracy and fast turn around time. And everyone knows their opinion is the only one that matters to your paycheck.
Yes. Or, rather, no.
Er, I mean, it doesn't matter. Use the one that makes sense for your particular project. PX and EM or both equally valid but will behave a bit different depending on your overall page's CSS architecture.
UPDATE:
To clarify, I'm stating that usually it likely doesn't matter which you use. At times, you may specifically want to choose one over the other. EMs are nice if you can start from scratch and want to use a base font size and make everything relative to that.
PXs are often needed when you're retrofitting a redesign onto an existing code base and need the specificity of px to prevent bad nesting issues.
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)