I'm in the early stage of building a site. I'm looking at some design elements that would take advantage of media queries to work properly at smaller screen sizes.
I've no problem with this except that this will be a small site and therefore pretty much the only javascript running on it will be a Polyfill for media queries for IE and other limp along browsers.
How much will this impact performance? Are there any proper tests that have been ran?
I ask because I'm in the stage now that if the polyfill affects the performance enough I can tweak the design so I don't have to use them, and also as a thought for future projects.
Bonus Question:
If I don't use mobile first but use mobile last, and do max-width queries rather than min, would I even need a polyfill. If nothing about the page is changing until it's less than 500px wide do I really need to worry about IE not displaying them? Or am I missing some edge cases?
Let's start with your bonus question.
If you approach with max-width media queries, i don't think you actually need a js solution for IE8 and below. That said, it really depends on what's your site "breaking point".
Probably, a user who still has IE7 running won't have an hd screen with 1920x1200 resolution. So keep in mind to make everything work well for 800x600 screens without media queries involved.
Personally, i prefer a min-width approach, so i can progressively enhance my site features. But it really depends on your project type/audience.
According to StatCounter's global stats, at Sept 2012 ~14% of users still use IE8, and less than 2% IE7.
If you want to serve the best user experience for this 15% (~6 every 100), then you probably need respond.js.
I've used and tested it on IE7 and IE8. I didn't notice a difference in performance, but i can't find any benchmark test online.
It's recommended by Modernizr and included in html5boilerplate responsive build, so i'm pretty sure you can...trust it ;-)
Related
I'm designing a mobile-first site and the thing is, height-based media queries could really benefit my page layout in many ways. But I am holding myself from using them because like more than 90% articles I've read about responsive design don't even mention vertical media queries.
Even mixin libraries exclude them like the one I use (Rupture). And here in SO they don't recommend using it. It really feels like it's a broken feature or has loads of compatibility issues...
I just noticed Instagram uses min-height on their mobile site So I thought maybe it's really safe to use them.
So, I was having a play with Flexbox this evening and have managed to re-create my relatively complex responsive layout using only flexbox items and no media queries.
There would be no getting around the need for media queries to make a production version (changing background images, font-sizes etc), but in terms of the layout, I have a working version which is completely fluid and has much much simpler code (See note below)
This brings me to my question; should I be doing this?
Note: I've used excellent SASS mixins by Brian Franco to simplify the cross browser aspects of flexbox.
I suppose that the main disadvantage of this approach is that browser support of FLexboxes (especially new syntax which gives the maximum possibilities for 'completely fluid' layouts) is a bit worse than browser support of Media Queries. For example, IE9 supports Media Queries, but doesn't support any syntax of Flexbox. Also, there might be inconsistensies between 'old' and 'new' Flexboxes behavior that can't be fixed with SASS approach. Hovewer, I believe that it would be very interesting and informative experiment.
I'm working on a responsive website, but 1 question always bother me is that should we always work from smaller screen size and move up to bigger screen or other way round?
For me I find it easier to work from bigger screen then reduce the browser screen and adjust it slowly. The reason I do this is because I can preserve my original pc screen's design much easier, if I work from smaller screen onwards, adjust it to original pc screen design would be difficult.
Is it better to work from bigger/smaller screen onwards? What is your opinion in terms of performance, loading speed, and coding difficulty?
This goes far beyond just responsive layouts or even CSS. You should optimize anything based on the way it will be used most. If I were making a site that most users would want to use from their phone, then of course, I would start development with the mobile version first! My reasoning is that there tend to be some trade-offs (albeit minor) with how things degrade as the screen size becomes smaller. To make sure the tradeoffs favor the mobile version, it may be best to start there and work toward the desktop version. However, I have always found myself in situations where starting with the desktop size is most practical, then I reduce the screen size and re-style it to my liking with media queries - reduce screen size, restyle, etc. It sounds like that's the approach you are taking and that should be fine unless a project calls for more attention to mobile from the beginning as I said.
No matter what you choose, if you are writing sensible code, the performance will be fine and the code should be understandable.
As m59 said, start with whatever device will be most used. A scenario that can benefit from the mobile to monitor workflow is when you create a new site from the ground up. This scenario leans more towards affecting design decisions because by starting mobile, you include all of the features and contents that are absolutely necessary for the user - the bare necessities . This way you filter out any filler that go into some desktop sites, making your design cleaner and the UI more user-friendly. Also, starting from mobile will allow you to explore and enhance your mobile UI development ability for the future, rather than just learning how to cram it all in.
I am working on two different responsive websites (both work in progress and one is taken from lynda.com just for practice). This first one I did works fine as far as I can tell.
The HTML is HERE and CSS is HERE.
Then I started to work on this one, created the same css as above but the media query targeting #media only screen and (max-width: 768px) is not loading for some reason.
HTML is HERE and CSS is HERE.
I've spent hours trying to figure out why and I'm lost. I don't any differences between the two, yet one is working and one isn't. Any suggestions you have would be much appreciated!
I'm just testing them in a browser right now.
Thank You!
I think the issue is one site has a "meta...viewport..." in its HTML, while in the other site that statement is commented out.
In the site with no "meta...viewport..." the Media Queries are actually testing against the dimensions of the unconstrained "viewport" rather than the "screen" (an oversimplification is "devices sometimes lie"). On the other hand in the site with "meta...viewport...width=device-width" the "viewport" width is forced down to be the same as the "screen" width before the Media Queries test it, so you get different answers (especially on smaller devices).
(Depending on what devices you're targeting, you may need to dive down into thoroughly understanding a "viewport". There are good reasons for the way a "viewport" behaves; please don't misinterpret my sarcastic "devices sometimes lie" to mean "viewports are a bad idea".)
I've been reading a lot of ways recently of how to avoid having to use Photoshop for things like gradients and shadows on buttons, when you can use CSS3 Box Shadow for such features. Now this is great, but obviously legacy browsers and most IE browsers don't yet implement CSS3 features, so my question is, why save yourself extra work in Photoshop when you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects? Isn't that just extra work?
you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects?
Often you don't really care whether the other browsers see the desired effects. If it's just a subtle background gradient effect, the site's going to work fine and still look reasonable with a flat background in downlevel browsers.
Compatibility was more of a problem when CSS 2 Positioning was at this stage: an unsupported positioning feature could lead to an unusable layout. But for essentially frivolous effects like backgrounds, borders and shadows, it's not critical if the effect goes missing.
There are a few reasons. From a developer/designers perspective, using CSS3 can be more flexible. An image is more or less just a static image. With CSS you can use script or CSS to animate or adjust the styling, and have advanced integration between the various technologies. This allows you to be able to do some things that are not possible or difficult just using images.
The page weight is also lower usually when using CSS, which allows the page to load faster, especially on slow connections or mobile devices. It also reduces HTTP requests (although you can use data uris too) which reduces latency and thus speeds up page loading.
Using CSS is often more maintainable and quicker, as you can adjust say a background colour or a shadow quickly just by changing the CSS, while with images you have to open up photoshop, edit the file, resave, etc. This is fantastic for quick tweaks.
There are also some people (myself included) that are much more comfortable in code than they are using graphics packages. For me it is easier to use CSS, but your milage may vary.
Also from the browser perspective we want to move the web platform forward and increase the capabilities. SVG is an example of another technology that doesn't work across all browser versions yet, but adds a lot of power. Although it may not be possible to deploy sites using certain CSS3 properties or SVG without fallbacks right now (depending on your audience or client) there will be a time in the future when old browsers are dead and what we are adding today works for all users. There was a time when most of CSS2.1 wasn't supported for example, while now you can rely on most of it if you don't need to design for IE6.
There are some parts of CSS3 that you can happily use without fallbacks, if you have a client that doesn't require all browsers to look the same. border-radius is an example, or giving a solid colour fallback to old browsers and applying transparency for newer browsers.
The world is moving forward, you can't ignore it. as long as old browser will show a button and new browser will show a more nice one, you are ok.
Otherwise, we were still be working on VT100... as why using "Windows" if most monitors doesn't support more than 4 color graphics and has 80X22 resolution....
If your bosses accepts the idea of having two versions of looks and feel and a warning. CSS3 is a good idea.
So, you use CSS3 features in your code and forget about the browsers that are not compatible -- they will see the "low-graphics version", you might want to issue a non-intrusive warning (like the one we get as alerts in StackOverflow), saying, "Your browser is not compatible with CSS3. To see this website in high graphics please upgrade your browser. Click the link here to update now."
But, depends on where you work. Big companies with lot of resources may like to stick with Photoshop and smaller once may like a light-weight CSS3 code that degrades silently in non-compatible browser.
Well you can always use ChromeFrame, to impose nice behavior on IE. Assuming that a lot of products will insist for it the near future (yeah we can argue against this), chances are that most IE users will have chromeFrame even before your application would insist for it. Once you take a decision on this, decision on using CSS3 properties or HTML5 elements is - well - hell yeah!!
Marvin