Two useful CSS / SCSS tips

We all struggle with #CSS specificity issues in our codebase as our tech-debt increases while fighting with frameworks that we should try to be avoiding in the first place! But you may have to work with an existing one at times. Here are a couple of ways to avoid and mitigate the issues:

1. To increase specificity in tough cases without using too many selectors, IDs etc.(of course NO !important). Try using the same class twice. A very legit tip which works great, straight from the horse's mouth, from #MDN (Mozilla Developer Network). eg .my-class.my-class { property: value; more rules etc. }
2. If you happen to use #ReactStrap components, you will end up with a lot of generic classes used by the framework everywhere in your components, whether they make sense or or not (eg. the notorious .form-group class). Result... a lot of unwanted paddings and nested paddings on your DOM elements which make your alignments off.
   
   Do yourself a favor and make a little #CSS #reset of your own by setting padding: 0 (and/or similar resets as needed) on all those pesky .form-group, .col, col-n... flex-column what have you, and start with a clean slate. You may need to use !important as a legit use-case if you need to override any !important in the framework itself.
   
   Then add back just a few margins and/or paddings on a couple of parent elements and enjoy the "clean" aligned results!
   
   If your #UI still "jagged", rinse and repeat on more generic classes. Your CSS / #SCSS will only get "cleaner" / better after this.
   

Please donate to this non-profit and/or share:

https://gofund.me/90dcb3f7

Thanks in advance!

Thoughts and notes from, An Event Apart conference

About four years ago, the main theme, mantra in all of "web world", including social media, blogosphere, meetups and conferences was "responsive web" which pretty soon turned into "responsible web" as web pages seemed to have had an immediate need to go on a "diet" to do well in the speed and performance aspect, more so in relation to keeping up with the responsive aspect.

Although we feel comfortable enough at this time to say that the Web industry has matured enough to understand the concept of "one-web" that works well on all platforms and devices and the term "responsive web" or "mobile web" is hopefully getting obsolete and web now inherently means "responsive web" as it was always intended to be, I am not yet sure if we have reached the point where websites are as fast and lean as they can be. Striving to be fast and lean is where the web seems to be focused right now (or needs to, if it isn't already). This was aptly represented by the focus of the An Event Apart Conference in San Francisco, Nov 2015, especially considering the fact that there were two talks exclusively focused on this topic and many others also included a heavy focus on the same topic as well.

Here's my consolidated "Cliff Notes" of sorts from:

Design Decisions through the Lens of Performance by Yesenia Perez; Desgining for Performance by Lara Hogan; Modern Layouts: Getting out of our ruts by Jen Simmons and CSS Grid Layout by Rachel Andew.

NOTE: I may have added general contextual information and resources here, which may not have been directly elaborated on, at this conference.  All the resources and links included here are public resources shared by the speakers and others.

The need for faster websites

Although the need for faster websites is unequivocally established and felt (or has been made to feel, as in Facebook 2G Tuesdays), here's a bit of a refresher on the need for faster websites:

• Average size of websites now — 2.16MB! Increasing every week! 
• Online shoppers expected pages to load in 2 seconds — and at 3 seconds, a large share abandon the site.
• People will visit a Web site less often if it is slower than a close competitor by more than 250 milliseconds.
• 20% is the magic number that makes a web-page perceptibly faster/slower than its nearest competitor.
• Visiting your website actually costs your users money! https://whatdoesmysitecost.com 

Ref: "For Impatient Web Users, an Eye Blink Is Just Too Long to Wait,” New York Times, February 29, 2012"

What makes up the page weight?

• Images (biggest contributor)

http://httparchive.org/interesting.php

• Custom web fonts (note that iOS 9 and many others give an option to disable custom fonts make sure you don’t have any gotchas with system fonts). 
• Third-party scripts (tracking, marketing analysis, user analysis, heat maps and more). These tend to cause more http requests as well.
• UI Interactions that mostly translate to Javascrip/jQuery scripts. 
• Stylesheets: Not the biggest contributor but can easily get bloated with overly complex layouts and numerous breakpoints (and frameworks if used in the 'kitchen-sink' model).

Apart from the usual Web Page Speed tests, time for first render etc. the term Page speed index was also discussed... Lower the better. 
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/june/speed-index--how-it-works-and-what-it-means/

The best Speed Index score was 819. The average was 3,658 (median 3,106), while the poorest had a score of 8,582.

Why do we end up with bloated websites? 

 

Slow, heavy sites are a result of…

• Poor planning
• Poor communication
• Poor awareness

Fast sites build trust.

Yesenia made a bold statement with "Performance is a design feature. Not a technical concern." What I think she alludes to is, if there have been decisions made at the marketing, UX and Design phases of the web project that cause it to be "heavy", no amount of optimization in the later phases will help you much to make it much leaner, so make sure it is built on strong but lean foundations. 

On a similar note:

"Deciding a page can’t exceed 500kB when a mock-up containing three carousels and a full-screen high-resolution background image has already been approved isn’t going to do you much good."

—Tim Kadlec

If an “approved page layout” already has a carousel/full page background image, textures, parallax scrolling, tons of web-fonts, videos, numerous JS/jQuery UI  interactions and “must-have” third party tracking scripts and much more, optimization won’t help you much to get your page load faster.

How can we change this?

• Create Reusable UI patterns that use common CSS; similar UI interaction patterns > common JS > Less code.
• Use the same basic pattern and add minor variations for different conditions.
• Simplify.
• Consolidate the number of colors and font-weights in custom web-fonts.
• Choose inherently smaller size images (shallow DOF, less texture, fewer details/noise).
• Optimize images further https://imageoptim.com/ (has links for automation too).
• Use responsive images. Thanks to Jason Grigsby's Herculean effort, we have an exhaustive 10 part essay on responsive images. 
• Use svg, svg sprites and icon-fonts when possible (smaller sizes).
• Use CSS to create banners, backgrounds, gradients and whereever it is possible to replace images.
• Remove unnecessary elements in markup ('divitis'); Clean up code; Don’t use “Kitchen sink” framework elements; drop rarely used CSS/JS libraries; Create the same effect, interactions with fewer lines of code and use plugins sparingly.
• When there are no other options, lazy-load below the fold images.
• Load scripts asynchronously (taking care of dependencies).
• Create a performance budget http://danielmall.com/articles/how-to-make-a-performance-budget/
• A Grunt task for keeping up with performance budget.
  https://github.com/tkadlec/grunt-perfbudget  

The above are predominantly design oriented tasks related to performance optimization as discussed in the talk and there is a lot more that can be addressed in code and on the server and this is by no means an exhaustive list. In this write-up as I am focusing more on the former.

Key takeaways from the performance talks 

• Prioritize performance from the beginning.
• Set a performance budget and prioritize as a project goal. Retroactive doesn’t really work.
• Who is responsible for performance? No more performance cops or janitors. Change Culture.
• Include performance goals in project specifications and documents. 

Front-end technologies we can look forward to, get excited about

Talk from Jen Simmons on "Layout should serve the content" and Rachel Andrew on CSS Grid Layout.  

Notice something on the web these days...?  

http://www.novolume.co.uk/blog/all-websites-look-the-same/ 

Summary: Web is not print, but it is OK to borrow or be inspired from print elements that were previously not possible on the web, as long as they are accessible, compatible with multiple viewports and user-friendly. Be careful of tab-orders and screen readers and don't over-do, or go overboard.  Many of these technologies may not work in all the browsers just yet, but most may be conducive to be used as progressive enhancement at this time. Below are some of those, many of which we are already using in although in smaller doses. 

• CSS Shapes
• CSS Regions
• Multi-column layout
• Flexbox
• Dynamic Grids
• CSS Grid Layout

Where are we on the browser support for these?

http://caniuse.com/#search=css%20shapes 

http://caniuse.com/#search=css%20regions 

http://caniuse.com/#search=CSS%20Grid%20Layout

If you are thinking... Why Did You Tell Me About All This Stuff I Totally Can’t Use Yet?!

The answer is: Do Websites Need To Look Exactly The Same in Every Browser?

Find out here ;) http://dowebsitesneedtolookexactlythesameineverybrowser.com/

To sum up in one sentence... Progressive enhancement is the key.

CSS Grid Layout

Specs are still not finalized on this, but in a better shape than flexbox. No confusion with multiple syntaxes as it happened with flexbox. Get involved and give feedback. May not be ready for prime-time/production yet, but can be used in prototyping as of now. Provides many options that aren’t available or hard to achieve currently, the most notable being separation of content and presentation and content choreography (yes, as in changing the content in different viewports without actually changing source order in the DOM). Of course a polyfill is in the works as well.

Resources:

http://thewebahead.net/ 

https://github.com/jensimmons/thelayoutsahead (what’s possible with these technologies and demos on the git repo).

CSS Grid Layout: The latest working draft http://www.w3.org/TR/css-grid-1/

https://rachelandrew.co.uk/archives/2015/09/02/css-grid-and-the-box-alignment-module/

https://rachelandrew.co.uk/archives/2015/07/28/modern-css-layout-power-and-responsibility/

http://fremycompany.com/BG/2014/CSS-Grid-Polyfill-Level-1-346/

Examples:

https://rachelandrew.co.uk/presentations/css-grid 

 
http://codepen.io/collection/lrmwd/ 

 
http://blogs.adobe.com/webplatform/2013/10/23/css-shapes-visual-storytelling/

http://blogs.adobe.com/dreamweaver/2015/11/introduction-to-canvas.html

Susy the class-less wonder; more reasons to "Grunt"

A more descriptive title for this post would've been... "Semantic, responsive frameworks with Susy (& Co.) and Sass", but obviously I am going for the cheese-factor here... Anyone recognize the allusion to a certain Seinfeld episode in the first part of the title? Never mind you newbies too young for Seinfeld ;-)

I have been sitting on the first part of this blog post almost for the past 5 months since I first used Susy "framework". Recently when this Smashing magazine post beat me to it, I almost thought rather not bother writing another "been there done that" post but I suppose this could be sort of a TL;DR version while also covering some quick basics, hopefully in a more overview angle.

I've made this into a two-fer including yet another reason to "Grunt" as there seemed to be a segway for that. Even if you have been using Grunt, stick around for this cool grunt task find.

Why a semantic grid?

You wouldn't probably be reading this post if you didn't feel the need for semantic frameworks... We all know the pains of frameworks in general, dependencies of framework files; mark-up littered with presentational classes (small-12, medium-6, large-3 and what have you) although some frameworks have mixins to prevent those; version updates; bloat to some extent if not used responsibly, although not much compared to all those tons of crazy un-optimized images on your page (can't help bringing that up).


To clarify, Susy isn't the only framework to use this semantic approach, just the one that I've used... I hear the latest version of Foundation, 6.0 (not yet released as of this writing) is also one that's going towards that.

A few key things you need to know about Susy:

It isn't really a framework per se as in, a file/s (grids and more) that you physically include in your <head> as in Bootstrap or Foundation etc. So it doesn't add any additional files/size to your Sass, or compiled CSS files!!

Although you can install it as a Ruby gem, I want to really stress that it can be used stand-alone without any Ruby dependencies. Just include the Susy folder in your project folder as below!

You can use it with Compass if you are already using it, but, not a dependency.

You do need to be using Sass though. Sorry, "Less"er folks... another reason to switch to Sass :-b Some Sass compilers didn't work at the time of my use (threw some errors), and the one that worked for me is the Koala compiler.

But, more importantly, although Sass is used while in the pre-processor stage, it isn't really a dependency in the final output. Once CSS is compiled, all the widths, columns and gutters are converted into straight percentages and can be ported into any environment as just straight CSS without the need for any framework files.

So then, you may ask, why not just use plain percentages manually to begin with? Frankly for the kind of complex responsive layouts we use these days, I'd rather keep my code "DRY" and not have to calculate percentages, gutters, margins, suppressing margins for the last-child, first-child and so on for every other div or complex product grids, with different configurations in each media-query etc.,  but rather focus on layout and quick delivery (set it and move on!).

So how does Susy does the "magic" of sizing your columns, with gutters, margins, margin suppression etc. The pics below are self-explanatory. 

You set all your grid variables like below in the settings file (which you will be importing to your Sass files...

You will be using it in your Sass file like below although not the best complex use-case scenario (btw, the breakpoints below are just basic Sass mixins I used. Nothing special referring to Susy, but the @include span is).

And you will get the compiled CSS output like below... Ta Da!

One more (rather two more) reason/s to use Grunt

Although it isn't quite possible to port Susy to Less in a completely automated way, there is a Grunt task for converting Sass to Less in general! Better to just convince others to use Sass, I guess. 


Here's a cool Grunt task for Sass > Less that someone has cared to share on Github.


In general if you just want to "cleanify" your pre-processor compiled CSS, eg. when porting/delivering it to another environment, perhaps as a front-end deliverable, here's the Grunt task to "cleanify" pre-processor output.


I've also wondered if all that ugly pre-processor CSS output with ungrouped media-queries for each element would cause performance issues, but I read this post testing that hypothesis which assured they didn't find significant performance issues with the pre-processor CSS output. Nevertheless it is still good to clean up . Kidding aside, these tasks can be really useful in real-world situations. 


To clarify, I didn't write the above grunt-tasks but just recognizing and linking to someone else's good work. I have personally used the second one and I love the output! Not sure how you would accomplish things like above (and lots more) without Grunt.


If you can think of some grunt-work, there's perhaps a Grunt task for that and someone has already shared it for the world to use. Good to use it and spend the time on something more challenging or less "grunty (or the interns could work on something more interesting  ;)) If you still aren't convinced to use Grunt, read the famous Chris Coyier's post on using Grunt.


A few notes from when I was trying to install Node and Grunt below. These may seem simple enough but will save you a lot of time wondering why your grunt task isn't running or some other snafu.

• You need to first install Node JS (lots of details in the above post).
• If Node JS install isn't working, install with sudo command.
• You MUST HAVE the package.json (which will have your dependencies and your Grunt tasks) in your project root directory and the Gruntfile.js (which will have your grunt tasks).
• You will be installing packages via npm (node package manager) and they all get downloaded into separate folders, but I found it way simpler to just put the necessary grunt tasks js files right into just the "tasks" folder off of your project root and just referencing directly in your Gruntfile.js (if you have it elsewhere, make sure you configure your paths right).

Hope this will be helpful to some. In general they serve as my own reference for later :) 

To Sass or Not to Sass?

First things first. If you are looking for advanced tips and tricks on Sass, to know everything about it, you might want to look elsewhere… like some of these articles listed here and a ton of others on the web. Some of these also talk more about cons, things to keep in mind etc. esp. the one on Lea Verou’s blog and one from CSS-Tricks.

http://css-tricks.com/video-screencasts/111-get-yourself-preprocessing-in-just-a-few-minutes/
http://css-tricks.com/musings-on-preprocessing/
http://www.codeschool.com/courses/assembling-sass
http://css-tricks.com/lingering-misconceptions-on-css-preprocessors/
http://css-tricks.com/sass-style-guide/
http://lea.verou.me/2011/03/on-css-preprocessors/
https://gist.github.com/pfulton/2730670
http://sass-lang.com/
http://thesassway.com/

Who is this post for?

If you are someone who has heard about Sass, kinda like it, not sure if you want to start learning it, since you have a ton of other new things to learn on your plate already, and want to hear from someone who has just made the leap into learning Sass, yes, this is the place.
Also, this post is not just about Sass, but more of how I incorporated Sass into my current project, things that made learning it easy (for my style of learning) and more fun.
To make things easy, Read/Do PART II only after you’ve read/done the suggested things (reading list) in Part I. It won’t make much sense otherwise.

Let me jump right in with some points/pointers in order.

PART I: Say hi to CSS pre-processors (Sass here):

1. It might not be the best way to start learning or trying to understand Sass by getting on the main Sass website. Try the other websites first, starting with basics and experiences from people I have listed on the top.
2. What is Sass in simple terms: I think of it as “CSS shorthand” … Writing CSS in a terse format, nesting selectors the way things make sense, using variables for the things you repeat (think of your brand colors, typography elements, media query breakpoints and more), keeping all your CSS for specific items separate (for some of us “monks”) but still be able to bring in only the bits and pieces we want together (@import) and then compiling it so it outputs CSS as we know it. Ooh compiling, command line… I am outta here… No stay with me… cue in some super-woman music and enters this amazing little software called CodeKit (more recently mixture.io and others do similar things, but I haven’t tried that).
3. http://incident57.com/codekit/ Yes, CodeKit makes Sass and playing with Sass and frameworks just SO MUCH FUN! Compiling, command-line, Fuhgeddaboudit! It does it all for you. More about it later. Oh, btw, that’s just for Mac and there might be something called Scout app for Windows, I think Mixture.io works on windows as well. May be some others too. Check it out.
4. Addendum: If you'd rather stick with CLI workflow, checkout Node JS with Grunt workflow.
5. OK, sounds good, how do I start?
6. Get a general idea about CSS pre-processors and Sass from the few links listed on top, read some basic articles, video tutorials if you wish, but don’t linger too long with nitty gritties to make you want to give up! Get an idea of mixins, learn about Compass, but you don’t need to start using compass right away. Baby steps if you’d like.
7. I am guessing you’ve already decided on on which “flavor” of CSS pre-processor you want to use i.e. Sass (.scss) vs LESS. If you are not sure, to make it easy on you, I’ll say Sass, but if you want to find out for yourself, read this http://css-tricks.com/sass-vs-less/
   

PART II: OK, how do I really start? 

1. Get CodeKit (or mixture.io or whichever software you’d like to use to make compiling easy). Of course you have just the straight command-line options as well. Read about CodeKit and how it works. It is more than just a Sass compiler. It concatenates, minifies your files and even reduces your image sizes further (like Kraken.io or such).
2. You are gonna need a fancier HTML editor than Dreamweaver… this is no WYSIWIG stuff! I went for Sublime Text, go for what ever floats your boat.
3. Now just get started on a project. Huh, but I am not ready yet!! Yes, you are. If you still aren’t sure, start on a smaller one.
4. If it is possible to use a CSS framework in your workflow, it’s the easiest way to learn by example. Get a framework that has the Sass version. I chose Foundation 4 by Zurb and it is awesome! You can see how they’ve used variables, mixins, best practices and learn compass too if you wish and by the time you are done with the project, you’ve also learnt the basics and more of Sass. http://thesassway.com/projects/zurb-foundation
5. Gone are the days of having to “customize” the framework and select only the components you need and still having to look at 100s of lines of code in your CSS if you have to edit something. With Sass, you just import the pieces you need for each template (home, back page etc.). Once you point your project to the framework in CodeKit, it finds all your imported Sass files for you. You don’t even need to specify paths for it, CodeKit just knows. Just watch this…
6. http://incident57.com/codekit/video/frameworks.mov
7. Now for something even better, if you have to customize a certain file a lot eg. _global.scss or _type.scss to fit your branding, leave those files alone in the framework folder and put a copy of those, with the same name in YOUR PROJECT Sass folder and customize all you want. CodeKit will first look for files in your Sass folder and then look in the framework folder.
8. If you are customizing just a few things, just over-ride them in your home.scss instead after @imports where you are importing all Sass goodies.
9. Remember, CodeKit concatenates and minifies all other .scss files and CSS for you and outputs a CSS named differently from your home.scss (with a suffix etc.) so make sure you are linking to that CSS file in your html file etc. (after this step it is just your basic CSS and HTML). Yes, this has to be all done locally and it may be hard if your CSS/Sass is edited by a team. Chris Coyier talks about it in one of those links.
10. Codekit also concatenates JS files and minifies it. You can get several levels of minification. With JS, I find it the lowest level is better as some scripts don’t work with minification (make sure you have back-ups).

I’ve talked about variables, mixins @import, ease of using frameworks and more to inspire you to use Sass, but wait there’s more…
I can’t conclude without talking about the live refresh in CodeKit. Make some changes in your Sass (probably a bunch of changes, even better) wait, don’t hit save yet, Keep your browser window open on the side or other monitor (your project folder that CodeKit is “watching” for changes. As you would know from CodeKit docs, it only works with webkit browsers). Now hit save and see the “instant magic” in the browser window!!

I REST MY CASE!
This is just meant to be a pointer or starter or inspiration for using Sass and in no way a full guide/workshop or "how to"s on Sass. Hope it inspires you to use Sass in your next project.
Here is my first project, using Sass with CodeKit and Foundation 4 Framework, and yes the wireframes in the beginning werer created in Balsamiq.
http://www.behance.net/gallery/WVU-Research-Redesign-UIUX-%28wireframes%29-Screenshots/9527457