Did you know you can target the Internet Explorer browser on mobile Windows Phone 7 devices?
<!--[if IEMobile]>
Displayed only on Internet Explorer Mobile on Windows Phone 7
<![endif]-->
<![if !IEMobile]>
Anything else
<![endif]>
You totally can1. Hearts to Allison Wagner for telling me about it.
It’s a bit more en vogue to handle mobile styling via media queries, which I generally agree is a better way to handle things (browser agnostic), but has the classic problem of a the browser needing to downloading resources it doesn’t need (e.g. CSS for desktop version when on a mobile device).
You know what would be super radical? If we could do media queries within conditional comments.
<!-- [if (min-device-width: 481px)]>
<![endif]—>
That would combine the syntax and power of media queries, with the ability of conditional comments to load only the specific resources we need, staying streamlined in terms of bandwidth.
1 Notice in the first block of conditional comments above the slightly different syntax. The former is called a downlevel-hidden comment and the latter is a downlevel-revealed comment. Nerdgrammer.
Unnecessary code. There are no Windows phone users.
Unnecessary post. You’re wrong.
Unnecessary bandwidth. The end.
You’re all wrong. There is one man who uses Windows Phone 7. Bill Gates. Everyone else is smart enough not to though so I do agree on the bandwidth. (:
Actually, Sam, you’re wrong too. I’m here and now telling you that there is more than 1 person who uses Windows phone. In fact, I can tell you that there is more than 1 person who uses the windows phone every given second of the day.
All of you need to stop being so negative and so closed minded in regards to Microsoft products. All things considered, Windows 7 is a nearly perfect operating system. The Windows phone is extremely good and very smooth.
Lastly, you guys need to appreciate the art of learning. This is a post that teaches you something. Chris took the time to learn it himself and teach it to you. So you need to take the time to learn it as well, because you never know when you’ll end up using it. Plus, who doesn’t love learning new things?
unnecessary comment (I have nothing to contribute)
Hey Chris! Nice article, I never knew that! I (and possibly other viewers) would find it really helpful if you could write an article (or combine it with the article on IE-Only Stylesheets) to describe what conditional statements are, what are the different parts of the syntax, the difference between downlevel-hidden comments and downlevel-revealed comments, the usage of
!
to mean ‘not’ in conditional statements.Thank you once again for making me aware that there are conditional statements for Internet Explorer even on it’s mobile platform =)
Let me google that for you …
http://lmgtfy.com/?q=conditional+statements
you’re welcome ;-)
@peter
When Aaron mentions things like “the difference between downlevel-hidden comments and downlevel-revealed comments, the usage of ! to mean ‘not’ in conditional statements.” you can probably assume that he doesn’t need the article he’s suggesting but thinks it’d be a good idea for the site. I know, I know, it’s really fun to post links to lmgtfy.
“If we could do media queries within conditional comments”
It’s called the link tag!
<link rel=”stylesheet” type=”text/css” href=”/style.css”
media=”screen and (min-device-width: 481px)”>
But you meant for content didn’t you….. I hang my head in shame
That prevents the CSS from applying until it meets the media query, but not from downloading.
@Chris Are you sure that’s right? Feel free to correct me if I’m wrong, but I thought that browsers will see your list of linked stylesheets and only download them if the respective media queries in the link tag match the capabilities/spec of the browser/device?
Obviously, if the media queries are *within* an all-encompassing stylesheet, then yes, browsers will download the whole lot and use the bits they’re supposed to.
Making a full desktop styled site, then layering media queries *after* this to remove/change stuff is bad for obvious bandwidth reasons.
This is why I see it as much more efficient and bandwidth considerate to build ‘mobile first’, then layer on additional stylesheets for increasing capabilities/screen sizes. This way, the mobile browsers only download what they need, while the more heavy-duty browsers download the full desktop version, as Luke Wroblewski advocates (for more than just this reason).
I guess I’m not 100% sure. That would be very nice if it worked that way. Bears testing.
Well I sure hope it does work like this, or all this clever mobile-first CSS I’m doing at the moment would be kind of pointless! :)
I would genuinely be extremely surprised if that wasn’t the case. It would undermine the whole purpose of media queries.
I’m fairly sure the CSS (and related background images) would load in that example. I think I read the keyword ‘only’ has a bearing on this for some devices. Anyway, I’m going to pin all this down and sort a workable solution out for only loading CSS and styling images when the device is one that is likely to warrant such bandwidth usage. It should be at http://wiki.doliver.co.uk/website_creation:mobile-friendly_method once it’s done.
I’m looking into using http://www.handsetdetection.com/ so that stylesheets are only inserted into the markup based on a server side mechanism.
Super quick test in Chrome 10 shows that CSS will be downloaded regardless of if it meets the Media Query or not. See: http://cl.ly/5Nna (tried “only” keyword as well)
If I was a betting man, I’d say that is because when the browser all the sudden DOES meet the Media Query, it can flip over super quick, rather than needing to download the resource after the fact.
Rock and a hard place.
Looks like I spoke too soon on this one. Shame, I really though that’s how they worked (and should work), though I can see how having the styles ready for changing matching criteria (rotating a mobile, changing browser width) has it’s advantages.
Like you say: rock and a hard place. Advantages and disadvantages to both behaviours.
Wondering whether this is something different browser vendors do differently (wouldn’t surprise me), or if they’ve agreed on something (ha!), or if the download behavior is somewhere in a W3C spec…? Maybe none of the above.
Sweet, this should be working fine if done properly.. can’t wait.
Modernizr now has a customized download option available with modernizr.load (yepnope.js) which allows use of conditional statements to asynchronously load javascript, css, images and so-forth.
http://modernizr.github.com/Modernizr/2.0-beta/
So by doing this, you could sniff the browser-agent and server up a mobile css file instead of the desktop css. You’re stuck running JS on your site to server mobile friendly content, but JS is on by default on most mobile browsers ;)
You can also include the modules you actually use to avoid any unnecessary overhead in terms of bandwidth.
Good article Chris :)
Cheers
Chris,
That prevents the CSS from applying until it meets the media query, but not from downloading.
It seems to me that it is a bad idea to optimize for browser silliness.
A browser has a priori knowledge of whether or not a particular resource needs to be downloaded. For example, a phone would never have a reason to download resources for, say, braille or embossed media types. Further link tags are used for many different types of resources (next/previous in a series, table of contents, etc) so it already has to discriminate based on information in the link tag. Media queries such as device-height, device-width, device-aspect-ratio, monochrome, color, color-index, resolution, scan and grid can always be known prior to rendering anything. In some devices the aspect-ratio, orientation and others are fixed. Regardless, browsers should only ever download those resources it could possibly apply.
It feels more reasonable (and less code smelly) to assume that browsers will use common sense in deciding which resources to download and then to encode things such that the default media query, the one which has nothing specified, is the minimum, old and cranky, kinda-smart-phone browser compliant CSS. Then specify your desktop browser using some version of
>link rel=”stylesheet” type=”text/css” href=”/desktop.css”
media=”screen and (min-device-width: 900px)” /<
or what ever floats your boat. This feels like a better approach than encoding behaviour into comments.
Good to know!
Just a quick note: The preferred syntax for the “downlevel-revealed” CC is like this:
Which is explained here.
This is purely for validation reasons (it won’t validate in HTML5 or XHTML unless you use this syntax). Of course, I have no idea if this will affect Windows Phone, but it would seem logical that it would be fine using the corrected syntax.
If all you need to acomplish with this, let’s call it resolution dependant css loading is mobile browser detection, I suppose that you can do it if you serve your stylesheet in php format. Very dirty solution, and I didn’t have time to test it (and I sure will be testing), but you can do something like this:
@media screen and (max-width: 300px) {
<?php include('mobile.css'); ?>
}
@media screen and (min-width: 301px) {
<?php include('desktop.css'); ?>
}
Anyway, that’s just a quick thought and too hacky for my taste.
forget my last post. the second I clicked submit, I realized that it does nothing :S Need sleep, that’s for sure :)
@media screen and (max-width: 300px) {
}
@media screen and (min-width: 301px) {
}
I’ll never use this.
If someone is viewing a websites on a mobile phone not running a webkit or some other CSS3 compliant browser, they deserve to see the site look like crap.
I’ve never had a client care about anything mobile except the iPhone of course.
Maybe it’s just me, but I’ve never seen a Windows 7 phone in the wild, just in stores, sitting all alone in a display, with no one caring or even looking at it. Poor Microsoft….. at least the did the xbox right.
* { display: none; }
It’s a win-win situation :)
* { display: none; }
It’s a win-win situation :)
Sorry for the double post. There is no preview button to preview :\
Is this deprecated now for IE 10+?
does not work on current windows phone firmwares. therefore unnecessary, confusing and leading to frustration – doesn’t help that people are linking to this without checking…