Where do the media queries go in a stylesheet: at the bottom or mixed throughout? - css

I'm working on my first responsive site and have read numerous articles but can't find an explicit answer to my question.
I have created and coded 3 designs at this point. The overall site is has a fluid main column and a fixed sidebar. The header and footer are fluid. After a cutoff point it will go from 2 column to one, with some additional changes to go to smart phone size. I want one style sheet. Having read several pros and cons, since this is my first responsive site I will be making the desktop design the "default" and want to use media queries to change styles for smaller sizes.
I have several styles that won't change from size to size, and a handful of styles that do change.
Do I go ahead and do my entire style sheet for the desktop, then add the media queries at the bottom? (Before the print styles or after?) Or do I mix the media queries in throughout the style sheet, wherever the "default" style is?
Thanks!

I've been battling this about my head for a while, as well. Some of my sites have one big handheld- or print-only section at the bottom, some have the relevant media queries right after the selectors they affect. As far as I've seen, neither way has any impact on rendering performance one way or the other (if there is one, I haven't perceived it).
My answer is to just use whichever you feel is easier to read. If this is part of a bigger project, consult any team members who also work on the CSS and ask them which they prefer.

Related

How to handle css modules changes in responsive design using ooccss and smacss

I am studying CSS best practices and methodologies like OOCSS and SMACSS to use in a medium scope project that uses Twitter Boostrap 3 and LESS. I'm starting to get a grasp of these methods but I have some trouble to find out how to handle responsive design and CSS modules relationship.
For example let say I have a button module with all different kind of buttons used in the project (color, shape, size). How could I make the button change depending of the device. The same button should be large in mobile and a normal in desktop.
Following OOCSS I should have 2 skin classes like btn--default and btn--large. But as the HTML is the same for each device I can't switch this class in the HTML. Also using a media query in the module's CSS that would change the size of the button depending of the device size doesn't seem a good idea as I would be coupling the module with this specific need (and what if I want a normal button in mobile later?).
As an other example, I have product section module that have different possible layouts (vertical / horizontal). What if I want to use the vertical layout in desktop and the horizontal in mobile. I'm facing exactly the same issue. I can easily create 2 different submodules (product--horiz, product-vert) but I can't change them.
I could use javascript to switch classes but it doesn't feel right and would break the design with JS disabled. You could tell me that maybe the design is not right if an element is changing so much from one device to another but it would be a real limitation to restrain this.
So what are your thoughts about this issue. Is there any generalised practice used to face it?
To use your example for buttons:
Mobile is also tablet and tablets come in a variety of viewport sizes that are just as large as desktop. Media queries are not detecting features, like touch, so making a media query is only for visual at that viewport size. It's best practice to use large buttons and large click areas for fat fingers for every device unless you do feature detection with js such as .touch .btn- {big styles}. I use a little script to put .no-touch and .touch on my html, but I don't bother making larger areas just for .touch. I make them for everything if at all possible.
Your base button style should be defined in the button module in your 'modules.scss'. Apply any styles here that will transcend across all buttons. Then handle the differences in your smacss 'states.scss' file (compiled last). You should have one 'button' section in your states file in which you handle media queries and unique classes that will alter the appearance of the button. Hope that helps, I can elaborate more if you need.

What the best strategy to structure CSS in GWT?

We have a medium size application with around 30 views. We have many CSS files laying around. Some are specialized (popup styles) but the rest contains style for different parts of the application, in addition of the style embedded in the *.ui.xml and it's start to get pretty messy.
Is there any guideline on how to structure the styling in a GWT application and in a web application in general ? How do you structure yours ?
There are two schools of thought on this. Some developers prefer to use CSS Resources.
My strong preference, after 7 years of experience with GWT and multiple projects, is to have a single external CSS file for all styles. I even do not include any GWT stylesheets (including DataGrid styles) - I copy their content into my CSS file. These are the reasons for this preference:
CSS is called a cascading style sheet for a reason - it is build around inheritance. A professional web designer builds an app design starting from the very top (html, body elements) and defines the rules for the entire application: font or fonts to be used, color palette, standard margins and paddings, standard grid (columns width), etc. These rules must propagate throughout the entire app. Once developers start defining their own styles at the view/widget level, it's nearly impossible to ensure any design consistency across the app.
Even more importantly, when the CSS rules are split between many different sources, it becomes very hard to predict their interactions. Why is this element not positioned correctly or has the wrong font size? Is it because I used the wrong selector in the widget CSS, or is this because some other rule from some other CSS resource overrides or conflicts with it? Now you find yourself jumping back and forth between different stylesheets trying to make it work.
Even if you do find a source of the problem and fix it in one of the stylesheets, now you have to check how this change affected other views and widgets. Making a change at the top of the DOM tree can impact every element at the bottom (again, it's cascading!). Often it's not easy to anticipate this impact in every browser possible.
These considerations become even more important when you try to make your app design responsive and make your app adjust nicely to different screen sizes. What happens to your view or widget-level CSS when you add a media query in your main CSS file?
Another important point is the speed of development. If you use a professionally designed CSS file, you almost do not need CSS at a view or widget level. When I add a new form, for example, I never need any CSS - I just throw a sequence of labels and input widgets and they all suddenly look right and they are positioned correctly, because the rules have been already set and they apply to all forms, input elements, labels, etc. in the app. I do not think what font size or color to use in a widget. I just use a <h2> header, for example, and it has one color in a light skin and a different color in a dark skin, and it changes its size and margins according to the screen size.
Finally, moving as much CSS away from the widgets makes it easier to reuse them in new projects. Using the same example, if a header does not have a font-family, font-size, color or margins specified in a widget, it will take these values from another app's CSS file (which may or may not be the same rules as the contributing project's file). So you can reuse the widget in a new project without touching its code, which again speeds up the development process and makes maintenance so much easier.
To summarize, a single CSS file makes it easier to enforce style consistency across the entire app and maintain code, and considerably speeds up the development.

How to check whether my website is responsive or not?

I have been given a task to convert an already hosted website into responsive. My working knowledge on CSS is below average.
In that quest, I heard about media queries. I looked for a solution, but what I got was more confusion. Media Queries? I tried responsinator.com and checked my website in that. Actually I don't know how to know whether a website is responsive or not.
My website fits the mobile screens. Header and footer automatically adjusts themselves.
There is a big slider and it just got cropped, but still loads images and works fine. If my website is responsive, how come the slider get cropped?
To make a responsive CSS, Will I have to make any changes to the values in my already existing CSS? Or will I have to just add my styles (without any edits) into the media queries given below.
#media(max-width:480px){
/*PUT YOUR CLASSES STYLES HERE*/
}
your media query defines which part of your css to look in, think of it like an if statement.
When it falls within a media query in your css file, your css has be defined to cater for that screen size,
Just because your page objects crop when you make the screen smaller does not make your site responsive,
best take your phone or tablet and visit your site, if the user interface is simple, easy and smooth, then you dont have to worry, but if you have a desktop styled site on a phone as wide as your numpad on the keyboard, you have some work to do.
It's quite difficult from my experience to "convert" a static website into a responsive one, especially if you do not have good CSS knowledge. Try to find elements with a fixed width and make them fluid by experimenting with max-width and procentual width values. Hope this helps.

Creating stable, responsive layouts in Twitter Bootstrap

I am building a responsive layout with Twitter Bootstrap and I am finding it difficult to keep the layout looking good across all sizes/devices.
In my early attempts I tried simply using the grid for placement, but page elements never ended up where I wanted them at different sizes. Now I am at the point where I am using media queries to override some of Bootstrap's styles and my own styles. This seems like it may cause a maintenance headaches down the road.
Rather than overriding styles I am thinking that I should add/remove the styles based on the screen's size by registering for media query events.
Can someone offer advice on good practices for adjusting the layout of a page at different screen sizes using Bootstrap?
I am looking for general advice, but I can post code and screenshots if that will help.
Update: Looks like media query events are not well supported.
Your on the right track. Use CSS media Queries. Firefox has a nice add on that enables you to adjust the page to a particular viewport so that you can see the changes pixel by pixel, though Im sure chrome would have something similar
There are no special tricks just because its bootstrap, as long as you have enabled the responsive stylesheet then you are pretty much good to go
This is a good place to start for media queries
http://css-tricks.com/snippets/css/media-queries-for-standard-devices/

How slow are CSS media-queries?

When I organize my CSS, I like to keep related styles altogether (header styles are in one section, footer styles are all in the same place, etc.) (sorry, OOCSS advocates).
I've recently been experimenting with media queries for smaller/larger screens. To keep with my organizational scheme, I would have to include separate queries for each screen size I'm targeting with each section of the code. (So, for example, if I was supporting, like, seven different screen sizes, I would have seven different media queries with my "header" CSS, and then seven queries in the "footer" section, etc.)
Leaving aside the question of whether or not this is how I should do it, are there any technical ramifications to having so many blocks of media queries? (They're all either min-width, max-width, or both. Say I had 100 different queries, but there are only seven distinct sizes I'm checking over and over again.) Would it take the browser longer to parse?
The code handling potentially slow paths is heavily optimized in modern browsers, so you don't need to pre-optimize this kind of things unless you definitely have to, with the profiling data at hand. Go ahead and write it.

Resources