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

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.

Related

What is the best practice to develop the cross-platform components with Vue.js 2.0?

I'm planning to write a common component library with Vue.js 2.0 and hope the library can work on multiple platforms. This question is about the best practices when it comes to a component's style.
On the PC / browser, We usually write CSS for fixed-width or flow layout with px. On a mobile platform (webview or browser), We usually write the CSS for flexible layout with vw / rem.
I see, some components only suit either one ( PC or mobile platform ), but still some components are common and versatility, such as Button, GridView, InputField and so on.
For example, there is a Button component that has a default padding style. In order to better adaptability, should I set the padding value by what unit? px? rem? For the goal, what is the best practice to do the things?
In fact, this question is not only related to Vue, but it's relevant for any frameworks that allows developing components, such as: React, Angular, Ember, etc.
I suggest that you stop thinking of browser / PC layout and mobile apps as being different. As it looks, you can't be sure what form factor's going to come next for both of them. That's true even for platforms that have been proven to be consistent, such as iPhone / iOS.
Responsive web design is the same in both environments, your layouts should be 'prepared' for a change in form factor.
Responsive web design is not different from React to Angular or anything in between. The only thing that differs is how CSS actually gets in your app.
No matter what you're designing for, you should:
Respond to the needs of the users and the devices they're using. The layout changes based on the size and capabilities of the device.
The basic principles are: Adapt, respond, and overcome.
Technical perspective
In Vue the way to go is: isolate components, including styles -> use scoped styles whenever possible <style scoped></style>.
Then (not specific to Vue), use fluid layouts however you want; some people choose %, some use vh / vw or em / rem. As long as it's fluid, you'll probably be fine. Many choose vh / vw for containers and use percentages afterwards, but there's no default pattern. With percentages, some people find it easier to mix in calc(), which can be a useful responsive tool.
Regarding your button example, it's probably a good idea to use rem or em as a default. However, for some components it might make sense to use px - don't be afraid to mix and match. This can save you a lot of code and there's no golden rule about it.
Your breakpoints shouldn't be shaped after devices, instead figure out where your content can be presented better. This way you'll build a more future-proof layout, which can turn out to be a nightmare to maintain.
Choose whatever makes you feel comfortable.
It's up to you to combine your tools and get the CSS to work for you / follow certain RWD patterns.
Wrap up
That being said, here are some patterns you can follow when building your responsive apps:
Mostly Fluid
Column Drop
Layout Shifter
Tiny Tweaks
Off Canvas
There's a course I encourage you to take if still in doubt.
In this course you'll learn the fundamentals of responsive web design with Google's Pete LePage! You'll create your own responsive web page that works well on any device - phone, tablet, desktop or anything in between. It might feel a bit slow in the beginning, but you'll learn a lot by the end of it.

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.

Grid layout - why should I use it, and should I use a framework like Bootstrap or Foundation?

I had experience with Twitter Bootstrap and Foundation, and I personally think the only thing I want to use is their grid system. Other features are just bloated.
So I read about the prospect of a grid layout. All of the articles I found are oriented toward an 'artistic' explanation (golden ratio ect). I am a coder at heart, I need a clear & logical reason to use a grid layout (for example: 'columns can be easily stacked on top of each other on mobile screen, and expand horizontally on larger screens'). Can someone give me the pros and cons of applying a grid system to my website? Personally do you think using a grid system is good?
If the answer is yes, should I use a premade grid system like from Twitter Bootstrap/Foundation or just make one for my own? All of the other features are unnecessary for me an irrelevant to my problem.
Thanks! :D
I agree with #kunalbhat that this might not be the best area to ask this but since you did I will try to answer it.
The grids are designed allow for speed and adaptability. Speed in multiple senses. The first part of the speed is the speed of writing the code. You can easily get the layout you want when you are using the grid system and everything aligns correctly. You don't have to remember your tables and columns and col-spans, etc.
The second speed is modifying your code. Inevitably you will need to go back and make changes, with a grid this is easily to do. Changing a col-md-7 to a col-md-6 easily makes a little tweak in the layout of your page that can easily be tracked and performed.
You mentioned responsive design, both Bootstrap and Foundation have responsive grids. The grids will snap to different sizes based on the viewport size. However you have control as well. For example if you want something to take 1/12th the screen in desktop, 1/4th on a tablet, and 100% on a phone that is easily done with Bootstrap and Foundation, both have grid classes that target specific viewports.
The also provide visibility classes based on those viewports.
For the "bloated" part that is easily solved. Using SCSS you can easily only import portions of a library. For example for one project I was on I only imported the Grid and it was considerably smaller.
I happen to think that this is a SO question, simply because of one of the main cons of CSS grid systems: semantic.
I think semantic is important for a web developer and having a class named col-md-7 is not the most semantic thing to do.
But I like grids, because they are easy and quick to use, so I started to use LESS. Because it allows me to use variables and functions(mixins) in CSS, I can build my own grid system on my CSS rather then on my HTLM.
You can start on Frameless and customize your own 'classes'.

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/

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

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.

Resources