Old IE & print styles: Feed desktop-first style sheet

[mhulse]

(Originally created/posted by Patrick in the Tracker's issues).

Discussion Points:

• Mobile-first isn't needed b/c of our lack of background images
• Desktop-first would mean better native print stylesheets
• Desktop-first would mean that we could avoid the IE8- issues presented by using media queries and the respond.js polyfill
• Please add more here...

HTML5BP Team discussion

Notable quotes:

"Correct me if I'm wrong but I believe that the mobile first approach with media queries was invented to prevent the downloading of big background-images on small viewports. That is a very valid reason. Now, if you don't use background-images the need to use this appoach is not as urgent anymore."

... and:

"But I have a feeling the mobile-first MQ setup is a lot of work. And the payoff is not worth the effort."

[mhulse]

Here's a good example of an article that makes it sound like "mobile first" is the way to go. Under the heading "The bottom line":

In most cases, I would advocate making the mobile styles the default, as it allows old mobile browsers to see the correct mobile styles. Yes, desktop IE 8 and earlier will also see those mobile styles, but this is an easy to fix with some JavaScript—a much more quick and straightforward process than getting your mobile styles to apply to non-media-query-supporting mobile browsers when you make desktop the default.

Based on what we're seeing, an "easy fix" is not the case (maybe it is, if your not having to worry about "CDN/X-Domain Setup").

When he/she says:

a much more quick and straightforward process than getting your mobile styles to apply to non-media-query-supporting mobile browsers when you make desktop the default.

That's statement is making the assumption that one cares about media queries working in older browsers. From my perspective, it's a better/easier solution to just let older browsers see the desktop view.

The "desktop first" advantages

On top of what Patrick has already laid out:

1. No extra work to get IE8 (and below) to see desktop view (no need to worry about media query support in these browsers; the ROI is way too low).
2. By reversing the process and going with a "desktop first" approach we'll be able to print the desktop view by default without any extra work (hopefully).

For point number 2 above, I have to test this. There's probably some technical limitations I hadn't considered. I'll post some demo pages as soon as I get the chance.

Disadvantages

1. Might be a lot of work to change our CSS.
2. Other technical limitations?

[mhulse]

Started a related discussion here:

"desktop first" tutorial

[mhulse]

I forget if there are other issues related to this topic. Here's my latest thinking on a direction to head:

Seen this a while back:

http://jakearchibald.github.io/sass-ie/

Because we're already using LESS, I thought I take the time to convert the above code into LESS syntax. Unfortunately, currently, LESS does not have support of something similar to SASS's @content. :-1:

Looks like the best option is to convert my LESS code to SASS.

Fortunately, I have not gone crazy with LESS, so the conversion shouldn't take more than a caffeine-induced night of geekery.

I guess this could be looked at as a drawback to using CSS preprocessors... As soon as you find a better feature in another preprocessor it may not be a simple task to convert your code to that new syntax.

LESS is nice and shiny looking, but it looks like SASS might be a bit more robust in terms of features.

Either way, once I get this code working, it should solve all of our OLD IE and print woes!!!!! WOOT!

[psullivan6]

this might help with the color creation with SASS

[mhulse]

Update: Looks like LESS can handle this.

See this repo:

https://github.com/himedlooff/media-query-to-type

See this issue:

https://github.com/himedlooff/media-query-to-type/issues/1

[himedlooff]

@mhulse another mobile-first strategy for dealing with old IE is to let it keep the small-screen layout but use a conditional comment to set a max-width on the container so it doesn't look so ridiculously stretched.

Also the mobile-first strategy is much more than the bg image thing, with mobile-first you are building up an experience as opposed to tearing it down with the desktop approach. For example the desktop approach would have you first float things left and right to create layouts, then for mobile you say 'no don't float anymore', like...

.sidebar {
  float: right;
}

/* Now we need to tear-down for smaller screens */
@media only all and (max-width: 767px) {
  .sidebar {
    float: none;
  }
}

Where the mobile-first way is simply...

@media only all and (min-width: 768px) {
  .sidebar {
    float: right;
  }
}

It's much less code which makes sense because the small-screen styling is often simpler than the larger-screen styles and that is just one example.

[mhulse]

Hi @himedlooff! Thanks for the comments. :bowtie:

@mhulse another mobile-first strategy for dealing with old IE is to let it keep the small-screen layout but use a conditional comment to set a max-width on the container so it doesn't look so ridiculously stretched.

That's a reasonable, and simple, solution! Thanks for sharing.

Also the mobile-first strategy is much more than the bg image thing, with mobile-first you are building up an experience as opposed to tearing it down with the desktop approach. For example the desktop approach would have you first float things left and right to create layouts, then for mobile you say 'no don't float anymore', like...

... ...

It's much less code which makes sense because the small-screen styling is often simpler than the larger-screen styles and that is just one example.

I think that's a great example as to why one should go with mobile-first. :+1:

Some background/thoughts:

Without boring you with the details, we have been struggling with old IEs, and printing/print styles, since our launch of a responsive template/theme.

To clarify, there's two issues I want to solve:

1. The problem with older IEs is that IE8 and below don't read media queries (obviously, this is a well known problem with media queries).
2. Printers will respect mobile-first media queries. Based on my tests, when using @media only screen, only the mobile styles will print. If one uses @media all, then the printer will print what fits on the printed page (in my test cases, that was the "tablet" size).

For issue number 1 above, I was hoping that respond.js would be the best solution ... unfortunately, it's proven to be much more of a maintenance burden that I had originally anticipated (I've posted some of my complaints here).

For issue number 2 above, I was hoping that the desktop-first technique would be an easy way to get printers to print desktop styles. Additionally, at first, it seemed like desktop-first would also solve the old IE problem.

With all that said, I opened this issue in order to start a thread where my co-workers and I (and anyone else interested in this topic), could provide feedback, document research and brainstorm on possible fixes.

Not documented in this thread, but several weeks ago (around the time that I created this thread) I had built a simple desktop-first demo page; while I had some success at solving the OLD IE and print problems mentioned above, I quickly came to the conclusion that the pros of mobile-first outweighed the pros of going desktop-first (like you mention).

I eventually ruled out converting our theme to desktop-first and found sass-ie. I had actually forked that repo in the hopes that I could convert it to LESS. I soon discovered that LESS doesn't support @content, so that's when I came across this LESS @content thread/issue, which eventually led me to your repository. :octocat:

While I like your idea of using a max-width on the container (that would a painless technique to implement) I think your media-query-to-type technique solves not only the old IE problem, but it will allow us to have a "desktop" print style sheet (without me having to convert from LESS to SASS). :+1:

Anyway, sorry to talk your ear off. Thanks for the comments/tips! I really appreciate it. :smile:

[himedlooff]

@mhulse in your second issue above you mentioned something like@media only screen (max-width... will be excluded from printing. That makes sense because you are targeting screens not printers and screens. Have you tried something like @media only all (max-width...?

[mhulse]

@himedlooff

@mhulse in your second issue above you mentioned something like@media only screen (max-width... will be excluded from printing. That makes sense because you are targeting screens not printers and screens. Have you tried something like @media only all (max-width...?

Hmmm, I have not tried only all syntax specifically.

I have tried @media all and ( ... ), that's where the printer loads the media queries but only the tablet size prints due to (I assume) the size of the printed area and the mobile-first setup.

One of our goals, for this project, is to have the default browser "print command" print out the desktop view; for a more streamlined printout we have opted to use the paid version of Print Friendly on our story pages.

To summarize, when using a moblie-first technique, the options are:

1. Using @media only screen ..., like you say, will print only the mobile styles (due to the "screen" restriction).
2. Using @media all ... the printer will load the media queries but you might not get the desktop "view" because the printer respects the way media queries adapt to the size of the device/format (hope that makes sense).

Based on my tests on the grid framework we're using, the "tablet" size is what makes it to the printed page.

With all that said, I'm 99.9999% sure your LESS technique will solve our problems; in theory, we'll be able to utilize the IE-generated version of the CSS for both old IEs and print styles! :eyes:

Thanks again for the feedback. It's great to get some outside perspectives on this topic. :smile:

[mhulse]

Once the new print style sheet has been added:

... we should add back a "normal" (browser-based) print icon to the social icons on the story page.