Apply Different CSS Stylesheet Depending on Browser Window Size - I Can't Find Anything Definitive

how do i include css based on screen size of the device

If you want to have only one css per page, but in that css file you want to import other css files that have differences based on screen size, you can do it like for example for screens less than 960px

@media screen and (max-width: 960px) 
{

/* your imports */
@import url('/css/styles1.css');
@import url('/css/styles2.css');

}

Also if you want to use only two css files in general, you might want to search for media queries and work on that a little :)

There are different methods for using different styles for different devices and screens, you might find this article useful about that http://css-tricks.com/resolution-specific-stylesheets/

Which says, e.g, you can specify in which screen size you want to show a css file like this;

<link rel="stylesheet" media="screen and (min-device-width: 800px)" href="800.css" />

<link rel='stylesheet' media='screen and (min-width: 701px) and (max-width: 900px)' href='css/medium.css' />

Show different div, based on screen resolution

Yes this could be done easily with @media-queries.

A simple example of media queries are:

In the head of your html page you do:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

And the divs with the content:

<div class="visible-phone">
content for phone // in your case -2
</div>

and

<div class="visible-desktop">
content for desktop // in your case -6
</div>

The css will look like this:

.visible-phone{
@media (max-width: 480px) { more css }
}

.visible-desktop{
@media (min-width: 768px) { more css }
}

More about it HERE & HERE

CSS appears different on Windows than Mac

The problem is the different default styles that browsers have. Neither way of displaying your page is wrong, they are just different.

You have compensated for the default styles of one browser, which makes it look quite different in all other browsers. As long as you compensate for the default styles instead of overriding them, you will have that problem.

For example, for the .slogan style you should set the top and bottom margin to zero, instead of using relative positioning to compensate for the default margin. You can use line-height to center the text vertically in the element, instead of moving it up or down to place it in the center.

Example:

.slogan{
  width: 960px;
  line-height: 30px;
  margin: 0 auto;
  color: white;
  font-size: 1.3em;
  font-family: 'Aldrich', cursive;
}

Automatically resize images with browser size using CSS

To make the images flexible, simply add max-width:100% and
height:auto. Image max-width:100% and height:auto works in IE7,
but not in IE8 (yes, another weird IE bug). To fix this, you need to
add width:auto\9 for IE8.

source:
http://webdesignerwall.com/tutorials/responsive-design-with-css3-media-queries

for example :

img {
    max-width: 100%;
    height: auto;
    width: auto\9; /* ie8 */
}

and then any images you add simply using the img tag will be flexible

JSFiddle example here. No JavaScript required. Works in latest versions of Chrome, Firefox and IE (which is all I've tested).

Should CSS always precede JavaScript?

This is a very interesting question. I've always put my CSS <link href="...">s before my JavaScript <script src="...">s because "I read one time that it's better." So, you're right; it's high time we do some actual research!

I set up my own test harness in Node.js (code below). Basically, I:

Made sure there was no HTTP caching so the browser would have to do a full download each time a page is loaded.
To simulate reality, I included jQuery and the H5BP CSS (so there's a decent amount of script/CSS to parse)
Set up two pages - one with CSS before script, one with CSS after script.
Recorded how long it took for the external script in the <head> to execute
Recorded how long it took for the inline script in the <body> to execute, which is analogous to DOMReady.
Delayed sending CSS and/or script to the browser by 500 ms.
Ran the test 20 times in the three major browsers.

Results

First, with the CSS file delayed by 500 ms (the unit is milliseconds):

     Browser: Chrome 18    | IE 9         | Firefox 9
         CSS: first  last  | first  last  | first last
=======================================================
Header Exec |              |              |
Average     | 583    36    | 559    42    | 565   49
St Dev      |  15    12    |   9     7    |  13    6
------------|--------------|--------------|------------
Body Exec   |              |              |
Average     | 584    521   | 559    513   | 565   519
St Dev      |  15      9   |   9      5   |  13     7

Next, I set jQuery to delay by 500 ms instead of the CSS:

     Browser: Chrome 18    | IE 9         | Firefox 9
         CSS: first  last  | first  last  | first last
=======================================================
Header Exec |              |              |
Average     | 597    556   | 562    559   | 564   564
St Dev      |  14     12   |  11      7   |   8     8
------------|--------------|--------------|------------
Body Exec   |              |              |
Average     | 598    557   | 563    560   | 564   565
St Dev      |  14     12   |  10      7   |   8     8

Finally, I set both jQuery and the CSS to delay by 500 ms:

     Browser: Chrome 18    | IE 9         | Firefox 9
         CSS: first  last  | first  last  | first last
=======================================================
Header Exec |              |              |
Average     | 620    560   | 577    577   | 571   567
St Dev      |  16     11   |  19      9   |   9    10
------------|--------------|--------------|------------
Body Exec   |              |              |
Average     | 623    561   | 578    580   | 571   568
St Dev      |  18     11   |  19      9   |   9    10

Conclusions

First, it's important to note that I'm operating under the assumption that you have scripts located in the <head> of your document (as opposed to the end of the <body>). There are various arguments regarding why you might link to your scripts in the <head> versus the end of the document, but that's outside the scope of this answer. This is strictly about whether <script>s should go before <link>s in the <head>.

In modern DESKTOP browsers, it looks like linking to CSS first never provides a performance gain. Putting CSS after script gets you a trivial amount of gain when both CSS and script are delayed, but gives you large gains when CSS is delayed. (Shown by the last columns in the first set of results.)

Given that linking to CSS last does not seem to hurt performance but can provide gains under certain circumstances, you should link to external style sheets after you link to external scripts only on desktop browsers if the performance of old browsers is not a concern. Read on for the mobile situation.

Why?

Historically, when a browser encountered a <script> tag pointing to an external resource, the browser would stop parsing the HTML, retrieve the script, execute it, then continue parsing the HTML. In contrast, if the browser encountered a <link> for an external style sheet, it would continue parsing the HTML while it fetched the CSS file (in parallel).

Hence, the widely-repeated advice to put style sheets first – they would download first, and the first script to download could be loaded in parallel.

However, modern browsers (including all of the browsers I tested with above) have implemented speculative parsing, where the browser "looks ahead" in the HTML and begins downloading resources before scripts download and execute.

In old browsers without speculative parsing, putting scripts first will affect performance since they will not download in parallel.

Browser Support

Speculative parsing was first implemented in: (along with the percentage of worldwide desktop browser users using this version or greater as of Jan 2012)

Chrome 1 (WebKit 525) (100%)
Internet Explorer 8 (75%)
Firefox 3.5 (96%)
Safari 4 (99%)
Opera 11.60 (85%)

In total, roughly 85% of desktop browsers in use today support speculative loading. Putting scripts before CSS will have a performance penalty on 15% of users globally; your mileage may vary based on your site's specific audience. (And remember that number is shrinking.)

On mobile browsers, it's a little harder to get definitive numbers simply due to how heterogeneous the mobile browser and OS landscape is. Since speculative rendering was implemented in WebKit 525 (released Mar 2008), and just about every worthwhile mobile browser is based on WebKit, we can conclude that "most" mobile browsers should support it. According to quirksmode, iOS 2.2/Android 1.0 use WebKit 525. I have no idea what Windows Phone looks like.

However, I ran the test on my Android 4 device, and while I saw numbers similar to the desktop results, I hooked it up to the fantastic new remote debugger in Chrome for Android, and Network tab showed that the browser was actually waiting to download the CSS until the JavaScript code completely loaded – in other words, even the newest version of WebKit for Android does not appear to support speculative parsing. I suspect it might be turned off due to the CPU, memory, and/or network constraints inherent to mobile devices.

Code

Forgive the sloppiness – this was Q&D.

File app.js

var express = require('express')
, app = express.createServer()
, fs = require('fs');

app.listen(90);

var file={};
fs.readdirSync('.').forEach(function(f) {
    console.log(f)
    file[f] = fs.readFileSync(f);
    if (f != 'jquery.js' && f != 'style.css') app.get('/' + f, function(req,res) {
        res.contentType(f);
        res.send(file[f]);
    });
});

app.get('/jquery.js', function(req,res) {
    setTimeout(function() {
        res.contentType('text/javascript');
        res.send(file['jquery.js']);
    }, 500);
});

app.get('/style.css', function(req,res) {
    setTimeout(function() {
        res.contentType('text/css');
        res.send(file['style.css']);
    }, 500);
});

var headresults={
    css: [],
    js: []
}, bodyresults={
    css: [],
    js: []
}
app.post('/result/:type/:time/:exec', function(req,res) {
    headresults[req.params.type].push(parseInt(req.params.time, 10));
    bodyresults[req.params.type].push(parseInt(req.params.exec, 10));
    res.end();
});

app.get('/result/:type', function(req,res) {
    var o = '';
    headresults[req.params.type].forEach(function(i) {
        o+='\n' + i;
    });
    o+='\n';
    bodyresults[req.params.type].forEach(function(i) {
        o+='\n' + i;
    });
    res.send(o);
});

File css.html

<!DOCTYPE html>
<html>
    <head>
        <title>CSS first</title>
        <script>var start = Date.now();</script>
        <link rel="stylesheet" href="style.css">
        <script src="jquery.js"></script>
        <script src="test.js"></script>
    </head>
    <body>
        <script>document.write(jsload - start);bodyexec=Date.now()</script>
    </body>
</html>

File js.html

<!DOCTYPE html>
<html>
    <head>
        <title>CSS first</title>
        <script>var start = Date.now();</script>
        <script src="jquery.js"></script>
        <script src="test.js"></script>
        <link rel="stylesheet" href="style.css">
    </head>
    <body>
        <script>document.write(jsload - start);bodyexec=Date.now()</script>
    </body>
</html>

File test.js

var jsload = Date.now();

$(function() {
    $.post('/result' + location.pathname.replace('.html','') + '/' + (jsload - start) + '/' + (bodyexec - start));
});

jQuery was jquery-1.7.1.min.js

How to get the inherited values of element from JavaScript

You can simply implement a pixel-to-rem converter and use that:

function convertPixelsToRem(pixels) {
    return ((pixels.replace("px", "") / getComputedStyle(document.documentElement).fontSize.replace("px", "")) + "rem");
}

console.log(convertPixelsToRem(window.getDefaultComputedStyle(document.getElementById("new").querySelector(".h1"))["font-size"]));

<style>
  #new {
    font-size: 2rem;
  }
</style>

<div id="new">
  <h1 class="h1">This is a heading</h1>
  <!–– Here h1 is inheriting font-size from div ––>
</div>

IE8 and REM based Media Queries

IE8 doesn't support media queries either, so it's not that the polyfill is turning them off, it's just that IE8 simply doesn't support them.

What did Chuck mean with saying "to ignore MQ rules when the polyfill was kicked in, since support would only be required at desktop". So when the polyfill kicked in MQ support was dropped? And why would MQ support in IE8 only be needed for desktop?

He means that IE8 only runs on the desktop, so there's no point supporting it in a responsive way.

Can it not be that some users don't have the browser window fully open but just one half or quarter of the screen and thus have a smaller screen-width? I don't have my browser at full size most of the time to be able to do work in the other windows etc.

Okay, so maybe there is a point to supporting it in a responsive way, but it's not a good enough reason for the developer -- he decided that the extra difficulty in adding this support would be too much work to make it worthwhile.

He does say in the ticket that if anyone else wants to do the work and submit the code changes, then he'll consider bringing them into the library, but he's not going to do it.

How much work is it?

Well, it's worth pointing out again that IE8 doesn't support media queries. So in order to get MQs at all in IE8, you need to use another polyfill library such as RespondJS.

Therefore, the work of making IE8 REMs work with MQs is actually work to make the REM polyfill and RespondJS know about each other and work together -- there's a good chance that you'd need to make changes to both libraries to make it work at all. It could be very difficult to do. I can certainly understand why they decided not to bother.

So as things stand, I think you are going to have to accept that what you want to do is not possible in IE8. Unless you want to start hacking around in the polyfill libraries to fix it for yourself.

How to make cross-browser compatibility with IE10 and IE11?

I am with Spudley. What does your font-family value look like? Are you using a MAC to check Chrome, then a virtual machine to check IE? Check both Chrome and IE on the same machine. Also make sure you are not using a MAC only font as your lead font. Also are you using a CSS reset that evens out settings like letter spacing? Remember every browser has a base stylesheet and they are not all the same, so a reset is a way to even the rules out.