CSS pattern libraries

Download CSS pattern libraries

Post on 17-Aug-2014




1 download

Embed Size (px)


CSS pattern libraries, and important tool for any front end web developer


<ul><li> PATTERN LIBRARIES CSSPATTERN LIBRARIES </li> <li> Who is this guy? </li> <li> Began in the web in 1995 Full CSS sites in 2002 Skills: UX, front-end dev, training Recently: CSS pattern libraries </li> <li> I have helped develop HTML/ CSS pattern libraries for very large sites (media and university sites) and complex applications (banking applications). </li> <li> In some cases, there are literally hundreds of CSS, SCSS or LESS les to review and optimise as part of the process. </li> <li> pages Moving away from </li> <li> A few years ago, many front end developers approached websites and web applications as a series of pages. </li> <li> Pages were often designed and built as complete entities. This meant that page components were often closely tied to their relevant pages. </li> <li> More recently, the focus has shifted from full page layouts to re-usable components. </li> <li> A re-usable component could be a layout grid structure, a button, an input, a drop-down, a menu, a heading, a table, or even a pullquote. </li> <li> pattern libraries HTML/CSS </li> <li> HTML/CSS pattern libraries are used to resolve commonly used interface components. These components are created as HTML and CSS code and documented, so that they can be easily re-used as needed. </li> <li> The terms style guide and pattern library are often used interchangeably. </li> <li> A style guide is a set of standards for implementing the overall design, and can include corporate branding, color schemes, layout and more. </li> <li> Style guides are used to ensure uniformity of the design or brand across all aspects of the website or application. </li> <li> On the other hand, HTML/CSS pattern libraries generally document code components for all aspects of the website or application. </li> <li> On larger web projects, style guides and HTML/CSS pattern libraries are generally separate entities. </li> <li> For smaller web projects, style guides and pattern libraries are often combined into one overall entity. </li> <li> cons? Pros and </li> <li> Why use a pattern library at all? ! Easier to build sites Easier to maintain sites Easier to hand over Better workow Shared vocabulary Promotes consistency </li> <li> What are the downsides? ! Time-consuming to write Often done post-project Serve current need only </li> <li> Pre-existing pattern libraries </li> <li> There are a wide range of pre-existing pattern libraries available today. </li> <li> Some of these pattern libraries have a simple purpose - such as responsive grid systems. </li> <li> Grid-based CSS libraries 1140 CSS Grid Mueller Grid System Responsive Grid System Responsive Grid System Less Framework 960 Grid System Susy 320 and up http://cssgrid.net/ http://www.muellergridsystem.com/ http://www.responsivegridsystem.com/ http://responsive.gs/ http://lessframework.com/ http://960.gs/ http://susy.oddbird.net/ https://github.com/malarkey/320andup </li> <li> Others are considered full frameworks that oer a wide range of components. </li> <li> These can include: ! Reset styles Grid systems Typography styles Browser xes Common user-interface component styles </li> <li> Complex CSS libraries Bootstrap Foundation Skeleton YAML Inuit Kraken GumbyFramework http://twitter.github.com/bootstrap/ http://foundation.zurb.com/ http://www.getskeleton.com/ http://www.yaml.de/ https://github.com/csswizardry/inuit.css/ https://github.com/cferdinandi/kraken http://gumbyframework.com/ </li> <li> There are some great benets to using an existing framework: ! ready-to-use solution can pick &amp; choose components easy implementation quick prototyping great for teams </li> <li> There may also be some downsides: ! may not suit your project no need for a complex library someone elses conventions generic look </li> <li> Bootstrap </li> <li> Bootstrap vs. mid-range website </li> <li> Bootstrap vs. University data site </li> <li> Bootstrap vs. Banking application </li> <li> Should you use a pre-existing framework? It depends on the needs of the site and your team. There is no one answer. </li> <li> Assuming you want to create your own CSS pattern library, how do you go about it? </li> <li> abstraction Understanding </li> <li> Abstraction is essential to any CSS pattern library. </li> <li> The process involves: ! looking for components that may be repeated within the layout dening their characteristics creating HTML/CSS patterns for them 1. ! 2. 3. </li> <li> An example: coloured boxes </li> <li> These boxes look like they have similar characteristics. If they were resolved into a pattern, this would make our HTML and CSS more ecient. </li> <li> What are the key things to keep in mind when creating any pattern? </li> <li> Avoid using IDs </li> <li> All patterns needs to be class- based so they can appear as many times as needed within an HTML document. </li> <li> /* avoid */! #signup-box { }! </li> <li> Avoid naming based on content </li> <li> We should avoid naming patterns based on the content, as we want to reuse these patterns often within the layout. </li> <li> /* avoid */! .signup { }! .member { }! .member-news { }! .wiki { }! .support { }! .database { }! ! /* preferred */! .box { } </li> <li> Avoid location- based styles </li> <li> All patterns should work regardless of where theyre placed within the layout. </li> <li> /* avoid */! .sidebar .box { }! .main .box { }! ! /* preferred */! .box { } </li> <li> Avoid widths </li> <li> Ideally, patterns should avoid dening widths. Patterns should be allowed to spread to the width of any parent container. </li> <li> /* avoid */! .box-wide { width: 500px; }! .box-medium { width: 240px; }! .box-small { width: 120px; }! ! /* preferred */! .box { /* no width defined */ } </li> <li> Keep patterns as simple as possible </li> <li> Patterns should be dened as simply as possible. Otherwise they can become restrictive. </li> <li> .box! {! ! border-bottom: 5px solid #C8C8C8;! ! background-color: #e6e6e6;! ! /* may not be suitable */! ! margin-bottom: 1em;! } </li> <li> Dont undo </li> <li> Patterns should not be written to undo other rules. For example, the element: </li> <li> We could be tempted to style the element with a coloured background - as it looks like this is the default appearance for all elements. </li> <li> /* default style */! h3! {! ! padding: 1em;! ! color: white;! ! background-color: red;! } </li> <li> But what happens if we needed to use an element later, and it doesnt have a background-color? We might have to write a rule to undo our previous one. </li> <li> /* default style */! h3! {! ! padding: 1em;! ! color: white;! ! background-color: red;! }! ! /* undoing default style */! .no-background ! {! ! padding: 0;! ! color: #000;! ! background-color: none;! }! </li> <li> It is best to avoid over-styling elements or patterns so that they do not have to be undone later. </li> <li> /* default style */! h3! {! }! ! /* only when background needed */! .class-name! {! ! padding: 1em;! ! color: white;! ! background-color: red;! }! </li> <li> Avoid dependency on HTML structure </li> <li> Patterns should not rely on the HTML structure. What happens if the structure changes in some instances - like a dierent heading level being used? </li> <li> <div>! ! ! <div>! ! <div>! ! ! <div>! ! ! /* avoid if possible */! .box h3, .box h4! {! ! padding: 10px; ! ! background-color: orange; ! }! ! </div></div></div></div></li><li> It is always better to create a class-based pattern for any specic styling needs. </li> <li> <div>! ! ! <div>! ! <div>! ! ! <div>! ! ! /* preferred */! .box-heading! {! ! padding: 10px; ! ! background-color: orange; ! }! </div></div></div></div></li><li> Modules, modifiers &amp; descendants </li> <li> How can we let developers know that our new class called box-heading relates to the box class? </li> <li> <div>! ! ! <div>! </div></div></li><li> We could use a naming convention that was originally dened as part of BEM: ! http://bem.info/ </li> <li> And then extended by Nicolas Gallagher: ! http://nicolasgallagher.com/about-html-semantics- front-end-architecture/ </li> <li> And then modied slightly again by Harry Roberts: ! http://csswizardry.com/2013/01/mindbemding- getting-your-head-round-bem-syntax/ </li> <li> This naming convention is based on the idea that page layouts can be broken down into a series of re-usable modules. </li> <li> If a module needs to be modied or extended, a module modier would be used. </li> <li> If a module has child elements that need to be styled, a module descendant could be used. </li> <li> These dierent types of class names need to be relatable and recognisable. </li> <li> /* Module */! .module-name {}! ! /* Module modifier*/! .module-name--modifier-name {}! ! /* Module descendant*/! .module-name__descendant-name {}! ! /* Module descendant modifier*/! .module-name__descendant--modifier {}! </li> <li> ! ! ! ! ! ! ! <div>! ! ! </div>! ! ! <div>! ! ! </div>! </li> <li> Module descendants </li> <li> With this naming convention, we can now add two module descendants to our HTML markup: </li> <li> ! <div>! ! ! ! ! ! ! ! ! ! ! </div>! </li> <li> .box! {! ! margin-bottom: 1em;! ! border-bottom: 5px solid #C8C8C8;! ! background-color: #e6e6e6;! }! ! .box__heading! {! ! margin: 0;! ! padding: 10px 15px;! ! text-transform: uppercase;! }! ! .box__content { margin: 15px; }! </li> <li> Module modifiers </li> <li> But what about the boxes that are very similar, but have some unique characteristics - like the decorative cog image? </li> <li> If we needed to modify or extend the original module, we would create a modier class name. </li> <li> ! <div>! ! ! ! ! </div>! </li> <li> However, in this case, we need to modify the box__content class. We need to create a module descendant modier. </li> <li> ! <div>! ! ! ! ! </div>! </li> <li> .box__content--cog! {! ! padding-right: 100px;! ! background-image: url(cog.png);! ! background-repeat: no-repeat;! ! background-position: 100% 0;! }! </li> <li> Helper classes </li> <li> In one of the boxes, there is a piece of text that is aligned to the right. How do we solve this? </li> <li> We could make it another module descendant - and apply this to the link. </li> <li> .box__link {}! ! !...</li></ul>