Responsive design using em or px

[toplisek]

I'm testing [twitter.github.io...]

and need to know how is influenced em or px inside this framework.

Example:
px for top and bottem and % for left and right. Meaning the width is adjustable and the height will be a fixed height...
This is just example as responsive design is different:
Generally, don't use px for responsive layouts, I guess.

Solution:
I will use percent on the body element (body { font-size: 62.5% or 100%; }), and then use the em unit to size it from there.

1. What will be than other units like
padding_/margin/border size/line-height...

2. Can I use em for fonts size and padding/margin with px or it is not correct way to set layout and I have to use all the time em for font size and also for padding_/margin/border size/line-height...

[DrDoc]

It is good practice to:
- set body font-size to 100% (this clears a bug in IE)
- set all subsequent font-size using em
- set line-height as a multiplier of the font-size (i.e. 1.2, 1.5, 2, etc -- no units)
- set border-width using px (this avoids imbalanced borders due to rounding errors)
- set padding/margin to px/em/% as desired (if you need an exact measurement, use px; if you need an approximate measurement, use em; if you need a rough measurement, use %)

[lucy24]

It sounds perverse, but even percentages need to change.

In a browser, margins of up to 10% can be nice. (Look at the present page.*) Drop down to tablet size and you're wasting real estate if you take that much horizontal space out of action; continue down to phone size and you'll want hardly any margin at all. It may be relevant that with smaller devices-- tablet or phone --there is no window, but the device itself has a physical "margin" outside the text area. This becomes part of the viewing experience.

When setting font sizes, 1em = 100%. So you can use whichever form is easiest for you to read and remember.


* Got a nasty feeling I've looked this up before and forgot. The entire page is a table ::cough-cough:: with width of 85%, meaning that the side margins are 7.5%.

[DrDoc]

When setting font sizes, 1em = 100%. So you can use whichever form is easiest for you to read and remember.

I, respectfully, disagree:

Always, always use 100% the first time you define font-size -- This avoids a pretty nasty bug in older but still-in-use versions of Internet Explorer

Always, always use em for anything that will-or-may affect tables OR explicitly declare the following before declaring any percentage based font-size (other than 100%): table, caption, thead, tbody, tfoot, tr, th, td { font: inherit; } -- This avoids several sizing bugs, mainly in Internet Explorer, but occasionally in other browsers as well.

Rather than figuring out how to avoid individual bugs or how to "fix" a nasty bug, by following the advice of using 100% for body and using em elsewhere you spare yourself from head aches.

In a browser, margins of up to 10% can be nice. (Look at the present page.*) Drop down to tablet size and you're wasting real estate if you take that much horizontal space out of action; continue down to phone size and you'll want hardly any margin at all. It may be relevant that with smaller devices-- tablet or phone --there is no window, but the device itself has a physical "margin" outside the text area. This becomes part of the viewing experience.

Sound advice! However, many/most don't know how to do this. But, yes, the whole layout (not just margins) needs to be modified explicitly for tablets and smart phones.

[lucy24]

Part of my boilerplate is

table {font-size: inherit; font-family: inherit;}

I don't remember which specific browser prompted me to add this line-- except that it can't have been MSIE. I only remember noticing that tables didn't always look the way I expected. Now, apparently very old versions of MSIE don't understand the word "inherit" ... but you gotta draw the line somewhere. (I don't remember where I learned this either. Can't find it in caniuse dot com.)

Sometimes I also add

img {text-decoration: none;}

for similar browser-specific reasons. If you use an image as a link, Camino will outline the image using the same color as ordinary text links. I don't think any other browser does this-- and sometimes I like the effect, so I don't mess with it. (But I don't add it explicitly so other browsers will see the same thing. I expect it; they don't.)

Does it have to be "100%" as opposed to the third option, "medium"?

[edited by: engine at 8:42 am (utc) on May 8, 2013]
[edit reason] fixed typo [/edit]

[DrDoc]

a img { border: none; text-decoration: none; }

A surprising number of browsers have issues with fonts in tables. In fact, I can't think of a single one that handles them absolutely right. Most font issues are solved with your example -- inherit on the parent table. But to ensure that more complex tables are handled right, you still need the more explicit inherit rule.

As for older IE -- I draw the line at 7 or 8, depending on the site.

[drhowarddrfine]

I don't think any other browser does this

IE does.

[Fotiman]

This avoids a pretty nasty bug in older but still-in-use versions of Internet Explorer

Which versions?

[DrDoc]

Which versions?

It's really bad in IE7 and older, mostly fixed (although still present) in IE8, and completely fixed in IE9.

[Fotiman]

Thanks. IE7 has less than 1% market share, so in my opinion shouldn't be explicitly designed against (and ditto for anything older than that). Your mileage may vary, of course.
I wasn't aware of any specific cases in IE8 though.

[lucy24]

Is it really a bug or--
har har, yuk yuk--
a feature? Does it do something basic like throw all tables into 80% sans-serif, or something worse?

IE does.

Oh, how goofy. That means most people on That Other Platform see my gallery pages the way I do-- but Mac and Linux users don't :)

[DrDoc]

Yeah, IE7 isn't really a problem nowadays unless your particular target audience is different from the "average".

IE8 has the occasional issue tied to inherited font sizes in tables, along with setting a %/em based font size using JavaScript. It doesn't always trigger, however, and I have never felt motivated enough to figure out the exact ifs and whens ... I just know that 100% on body followed by em elsewhere (including in JavaScript) has never triggered the buggy behavior in IE8.

As for border -- to my knowledge, all "older" browsers (and some newer) exhibit that behavior.