Front-End Style Guides - Anna Debenham

Contents Preface

An Introduction to Style Guides Embracing Systematic Web Design Why a Front-end Style Guide? Building Your Own Front-end Style Guide Front-end Style Guide Examples and Tools The Future of Front-end Style Guides

Further Reading

Front-end Style Guides by Anna Debenham Published in 2017 by Anna Debenham ISBN: 978-1-5272-0460-7 Editor: Cennydd Bowles Technical Editor: Paul Robert Lloyd Cover design: Geri Coady On the web: maban.co.uk Please send errors to [email protected] Copyright © 2017 Anna Debenham All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage and retrieval system, without prior permission in writing from the publisher. A catalogue record of this book is available from the British Library.

3

This book was originally published by Five Simple Steps in 2013 before they closed their doors. My thanks go to Emma and Mark Boulton, and everyone who worked on producing the original, including Owen Gregory, Paul Robert Lloyd, Jo Brewer, Nick Boulton, and Colin Kersley. This edition was edited by Cennydd Bowles and tech edited by Paul Robert Lloyd. Geri Coady designed the beautiful front cover. I am so grateful to be able to work with such talented people. Thank you, Cennydd, for your love and support while writing this.

4

My first encounter with a style guide came during one of my first client projects. I was working with an agency, writing the HTML and CSS for some new pages on a corporate intranet. I was given a style guide – a monster PDF covering details like logo positioning and what colours to use. The pages had already been designed but didn’t match the guidelines, so I was asked to make sure the final site did. Since the document I was given was intended for print projects, the colours were all Pantone colours that I had to convert to hex values, and the measurements were all in points that I had to convert to pixels and ems. I spent hours reading the document, struggling to follow the guidelines while translating them for the web. I felt it was strange that I was given so much documentation about making something for print, but none about making something for the web. It wasn’t until I started an internship at Clearleft that I encountered style guides that were built for the web and integral to client projects. Clearleft’s team was the first I worked with that designed templates – article templates, product detail templates, product list templates – rather than pages. They thought about websites in a modular way. Natalie Downe, one of Clearleft’s front-end developers at the time, referred to these webbased style guides as “pattern portfolios”, each pattern relating to an individual module on the site. A pattern portfolio held, on a single HTML page, every module on the client’s website, and was produced as a developer deliverable to help the client integrate the markup Clearleft had written into the client’s content management system (CMS). Style guides for the web have come a long way since then. They’re not just intended to be used as documentation – they are also systems used for prototyping. Since I wrote the first edition of this book in 2013, I produced the Style Guide Podcast with Brad Frost. We interviewed a number of people about the types of style guides they’d built for clients or within teams at their organisations. Many of the lessons I took from those discussions have found their way into this updated edition. 5

An Introduction to Style Guides Style guides set a precedent, demonstrating how a designer or developer expects the site to be maintained and built upon going forward. Style guides are useful tools for communicating intent between designers and developers, but they can also help those with jobs that don’t necessarily involve design, such as copywriters, editors, and product owners. Armed only with a Word document, some stock images, a style guide, and perhaps a set of customisable templates, employees and contractors can ensure the organisation’s message will remain on-brand rather than look sloppy or inconsistent. The UK’s National Health Service (NHS) is a giant organisation that benefits from having design guidelines, and for good reason: patients need to feel not only comfortable when they’re treated, but also well informed. Guidelines explaining how to make signage clear and consistent, text in leaflets readable and accessible, and tone of voice trustworthy and straightforward help meet these goals.

Types of style guide There are lots of different types of style guide, online and offline, and I like to incorporate aspects of these into mine. Some style guides are stricter than others. Brand style guides can be very strict (“Thou shalt not use less than 2cm of white space around a logo”); others are more relaxed. I like those that are in-between, because there are often cases when you have to bend the rules.

6

CONTENT AND EDITORIAL STYLE GUIDES An editorial style guide ensures consistency in the content used throughout a publication or website. It may include rules around grammar, preferred spellings, date formats, and capitalisation. A marketing department might produce tone of voice documentation to ensure all messaging to the user – such as microcopy, email notifications, and tutorials – sounds like it’s written by the same person. MailChimp’s Voice & Tone is one such resource, and it’s fantastic. Full of examples of how MailChimp gives feedback to users, it provides educational explanations of why something should be written in this way.

It’s good to capture a site’s tone of voice to avoid inconsistency when several people write content. Content Management Systems have made it easier for anyone to publish content, but without proper guidance, using the wrong tone can mean you come across as unprofessional or even rude.

BRAND IDENTITY GUIDELINES

7

Brand guidelines, also known as corporate identities, are documents that describe how an organisation wishes to be perceived by the public in their communication methods, from advertising to customer support interactions. They vary in depth and complexity. They can be quite lightweight, such as Dropbox’s, which sets out the corporate colours and how to use the logo.

Other brand guidelines are more rigid and provide a lot of detail, like The Scout Association’s visual identity guidelines (PDF), which cover every conceivable aspect of the brand. Big organisations often have substantial guidelines because the larger they are, the more challenging it is to control their identity. Strictly enforced guidelines remove ambiguity and help maintain the brand’s desired values. After all, minor inconsistencies can have a bigger negative impact when operating at scale. Some brands don’t translate well from print to the web, so it’s important to take into account the differences between media when putting a style guide together. For example, typefaces in print guidelines will often be

8

optimised for print rather than screen, and logos and iconography may be unsuitable for conversion into SVG.

CODE CONVENTIONS Code conventions are useful when several people are working on the same codebase. Code conventions mention things like whether to use spaces or tabs for indentation, and underscores or camelCase for variable names. These conventions keep code maintainable and make it easier for people, often working remotely, to collaborate. GitHub has its own Ruby and CSS guidelines. These contain advice about file organisation in projects, naming conventions, and formatting guidelines. As the guidelines are extensive and open source, hundreds of people who don’t work at GitHub have forked their CSS guidelines for use in their own projects. This is good for GitHub because it means potential hires may already be familiar with the code standards they follow. Good guidelines tell you what to do: “Keep selectors as short as possible.” A great set of guidelines tells you why: “Keep selectors as short as possible, to keep specificity down and performance up.” An excellent set of guidelines goes further and backs up the reasoning with further reading. I particularly like Harry Roberts’s CSS guidelines because this is exactly how he writes his. If you write guidelines in this way, it will be invaluable for new developers as it helps them learn best practices. There are tools that will help you maintain consistency in your guidelines, such as Hound, which creates a pull request on GitHub if your code doesn’t meet your team’s code conventions, or JSHint, which can be integrated into your code editor or build process to flag up style violations in your JavaScript.

HUMAN INTERFACE GUIDELINES 9

As new input methods such as speech and gesture become more popular, interaction guidelines have become more important. These guidelines are not just matters of visual style but also cover interaction. Human Interface Guidelines (HIGs) seek to standardise these interactions within a particular product’s ecosystem, so as not to confuse a user with inconsistent responses to interaction. Apple first published its influential HIG decades ago, and continues to develop them for macOS, iOS, and its other platforms today. These are written for people building apps for Apple’s platforms. I particularly like Microsoft’s HIG on designing for the Kinect for Xbox (PDF), which includes examples on the nuances of designing an interface that can be controlled via voice, gesture, or using a controller.

FRONT-END STYLE GUIDES In 2005, Dave Shea wrote a markup guide for his projects. It’s a basic page with headings, lists, and paragraphs, and one of the first documented examples of a front-end style guide. Since then, front-end style guides have become broader and deeper. Some include colour swatches, like a branding style guide; others include coding standards. Front-end style guides come in many forms, but they share a purpose: to make building and maintaining a website easier. Unlike a print style guide, a front-end style guide uses real code and works in a browser. It’s not a PDF or a series of screenshots: it’s HTML that demonstrates a site’s main styles, suggests how and when the styles should be used, and offers example markup. A front-end style guide grows organically with a site throughout its lifetime, acting as a reference and preventing duplication of code and design patterns. The style guide references the same main CSS file as the 10

site it’s built for. As new features are added or designs tweaked, site owners update the style guide. If the style guide is truly living, it will pull in new components automatically, so it is always up to date. Front-end style guides excel at encouraging collaboration between designers and developers. I love sitting down with designers and going through the guide, making tweaks straight in the CSS. This collaboration saves a lot of time that I used to spend switching between mock-ups and live sites. It also preserves sanity, and prompts great conversations about responsive design, such as “How should this table of data work on narrow screens?” or “Should we reduce the height of this masthead when the viewport is short?”

Terminology I find terms like ‘styleguide’ and even ‘patterns’ to be quite problematic in the generic sense that they are often used. The word ‘styleguide’ has so much baggage attached to it relating to its use over the years as a static design deliverable that I generally try and avoid it altogether. —Mark Perkins, “On Building Component Libraries”, 28 April 2016 You’ll notice in the examples that follow that many people use different words to describe the same thing. Front-end style guides are still in their infancy, and a lot of terms exist. Just make sure the name you choose for your style guide makes sense based on what you’re building, and use the terminology you’ve chosen consistently.

ELEMENTS, PATTERNS, AND COMPONENTS Elements, patterns, and components are the distinct parts of your interface, such as a news teaser with an excerpt, date, and image, a header 11

for a blog, or even a simple ordered list. In his article Atomic Design, Brad Frost uses the term atoms for basic building blocks that are not particularly useful on their own, such as a button for a search box, an input field, or a label. Atoms combine to create molecules that perform a specific function – for example, by combining the aforementioned button, input, and label we make a search form. Organisms are groups of molecules combined, such as the search form in a site header, alongside some navigation.

A visual explanation of atomic design principles from patternlab.io.

Thinking of design patterns in an atomic way makes what we build more flexible. We assume that the same atoms and modules could be combined in many ways, in combinations we might not have imagined when building them. Splitting things up in this way helps users of an atomic pattern library understand how modules are assembled. Separating the modules from the layout helps make a site more maintainable: if the layout changes, such as increased column width, modules can simply expand to fill it. While I like the Atomic principles and I think about them when I’m writing front-end code, my preference is to stick with the word “component”. I find the Atomic terminology too rigid – it’s not always obvious whether one of these building blocks is an atom, molecule, or organism, and I don’t want to pass on this confusion to the client.

12

STYLE GUIDES, DESIGN SYSTEMS, PATTERN LIBRARIES, AND COMPONENT LIBRARIES The term pattern library is sometimes used when discussing style guides. A style guide explains how things are going to look, whereas a pattern library tends to focus on how they are assembled. Style guides are a fantastic tool for designers, and pattern libraries are generally more useful for developers, but there will be some overlap. The term design system is frequently used as an overarching term covering core principles, language, design, and tools used to implement these. Its application may be similar to a component library, but with more emphasis on behaviour and interaction.

Google’s Material Design is an example of a design system. It describes the overall goals of a design across all of its web and app products.

Design systems are a particularly useful tool for creating a common design language for an organisation’s many different products, from websites to mobile apps. In Brad Frost’s book Atomic Design, he describes how style guides are a key part of design systems: “The cornerstones of good design

13

systems are style guides, which document and organize design materials while providing guidelines, usage, and guardrails.” Be careful when using the term “style guide” on its own, as it can have connotations of print media. The terms “pattern library” and “component library” are more accurate, but can be confusing for clients, so I tend to use them only when I’m talking with web teams. “Pattern library” and “component library” can also be restrictive, as your style guide may also contain things like branding and content guidelines. This is why I like the term “front-end style guide”. Your front-end style guide could contain a pattern library, but it could also have a section on tone of voice. It’s a useful all-encompassing term. Front-end style guides aren’t just for developers. The people I’ve worked with who have been most excited by them are designers who are familiar with using or producing print style guides. There are plenty of tools and techniques for building front-end style guides for those who don’t code, which I’ll go into later.

14

Embracing Systematic Web Design The various types of style guide come into their own at different stages of a project. Some are most appropriate during design exploration, others at the end of a project. The options vary in depth and focus, from design to development. Some are good for prompting discussion, others are better as handovers to other developers – but they’re all useful approaches to different challenges.

Common processes Not all web style guides are what I would call front-end style guides, which are written in the same markup and reference the same CSS that is used on the real site. Some style guides are more tools for promoting discussion between designer and client. The technique you choose should depend on your preferences, your skills, the project, and the client.

STYLE TILES During the design exploration phase, producing mood boards can feel too abstract, but jumping straight in and producing a mock-up can be premature. Samantha Warren’s style tiles sit between the two. In the early design stages, Samantha recommends creating a series of graphics files that have different styles, and presenting these – rather than 15

full mock-ups – to the client. These style tiles encourage clients to focus on appearance rather than layout. Quicker to produce than a detailed mockup that can can be easily dismissed, style tiles are great starting points for discussion.

Three style tiles Samantha created for The Examiner to help them decide upon a design direction.

Although the intention is to design style tiles using graphics software, they’re also easy to include in a front-end style guide. There is even a Compass extension that lets you do this, and a marked-up equivalent if you want to produce a web-based style tile. Style tiles are particularly helpful if the client or product owner doesn’t know what they want, or doesn’t have a visual direction figured out. They’re not throwaway deliverables – you can use a chosen tile as the foundation of your front-end style guide, before most of the design work has even started.

ELEMENT COLLAGES Dan Mall takes style tiles a step further. He describes element collages as “an assembly of disparate pieces without specific logic or order”. I often have ideas for pieces of a site in bursts. A full comp often requires ideas to be fully realized. An element collage allows me to document a thought at any state of realization and move on to the next. —Dan Mall, “Element Collages”, 13 November 2012 16

Like style tiles, element collages are tools to facilitate conversations, but they arrive further along in the design process, or even straight after a style tile has been selected. The most valuable thing element collages do is focus the client on how a particular feature will work, independent of surrounding layout. Now we have a seemingly infinite number of devices, screen sizes, and resolutions to worry about, breaking out of the canvas helps the designer and client think more about how a component is going to work in context of the site as a whole, rather than on a specific page.

An element collage produced by Clearleft for Code for America. Here, the elements were placed on a horizontal rather than vertical canvas to avoid it looking too much like a page mock-up.

Element collages are perfect for designers who aren’t yet comfortable putting their designs straight into code, but want to move away from full mock-ups. Both style tiles and element collages are intended as discussion pieces. There’s a sensible trend away from grand reveals towards experimentation and showing little and often. Although element collages are intended to be displayed in the browser, they are static images, so each interaction state has to be illustrated with a separate visual.

17

STYLE PROTOTYPES Digital agency Sparkbox’s style prototype is similar to an element collage, but is displayed in the browser and is interactive. A style prototype is a web page containing some of a site’s typographic elements, button styles, and photographic styles. One problem with presenting static mock-ups is that fonts and colours can look unexpectedly different in a browser and on different devices. Style prototypes help solve this problem and, since they are responsive, can be tested easily on different devices. One of the greatest challenges we all face in this era of responsive web design is achieving a balance between efficient workflow and effective client deliverables. It was with this in mind that the Style Prototype was born. —Jeremy Loyd, “Our New Responsive Design Deliverable: The Style Prototype”, 6 August 2012

Jeremy Loyd of Sparkbox states that style prototypes are not intended as branding mood boards, and are best suited to projects that have an existing brand: “In a sense, it is a safety measure intended to avoid rehashing (or completely scrapping) site designs in which hours of time and budget have been invested.”

18

Style prototypes help demonstrate how different styles feel in the browser. They capture things like button hover states and interactions on a detailed and granular level.

COMPONENT LIBRARIES Component libraries are collections of all the components on a site, displayed in one place. They act as deliverables for other developers rather than as design conversation pieces. The first component libraries I encountered were Natalie Downe’s “pattern portfolios”, which she produced as a developer at Clearleft. These were long pages that contained all of the components she’d built for a site. These components sat between the site header and footer as though they formed a single template, but holding all the site’s content types.

19

This component library was a lot like Dan Mall’s element collage, which came later, except that rather than being a static image, it was written in code. One of the reasons Natalie created pattern portfolios was to prove that components didn’t have to be tied to a specific page, and that they were like bricks: distinct from one another, but able to be stacked and slotted together to form a page. Dimensions aren’t rigidly enforced, so the modules are flexible enough to live in a narrow sidebar or at full width in an article. In fact, the component library shown was not responsive to start with, but was adapted to be responsive later with little effort, as all the components were originally built to fit any width. Some time later, as part of his process of building a responsive site, Jeremy Keith extended Natalie’s concept into a “pattern primer”, which presented components alongside their markup. This pattern primer acted like an encyclopaedia of all the components on the site, how they looked, and how to reproduce them. Unlike a component library, the page itself didn’t look like the final site: each module was shown on the page at 100 per cent width.

20

The code for Jeremy’s pattern primer is on GitHub.

That’s the way I’ve been starting most of my projects lately: beginning with the atomic units of content and styling them first before even thinking about layout. This ensures that those styles are extremely robust—because they don’t depend on any particular context, they can be safely dropped into any part of a page. —Jeremy Keith, “Pattern Primer”, 19 November 2011 The documentation for front-end frameworks like Bootstrap and Foundation share a similar format. Examples of components are presented alongside their markup, with explanations of how to use the modules. In his article “Responsive Deliverables”, Dave Rupert suggests that customised, small, Bootstrap-like systems could become “self-documenting style guides that extend to accommodate a client’s needs as well as the needs of the ever-evolving multi-device web.” Component libraries are ideal for the development and testing phases. Since the entire site’s components are in one place, it’s easy to view a library on multiple devices to check everything works and confirm that 21

styles or interactions don’t contradict each other. Components should be flexible and work as expected even if they live on different pages. I’ve found component libraries most effective as deliverables after the site has been developed, particularly if there’s any additional work to be done. Component libraries have been especially useful to me when I’m writing markup and CSS but handing over my work to developers who will integrate it with their CMS. Having patterns alongside the corresponding markup makes life easier for these developers – it means they don’t have to pick through my code to find what they need.

22

Why a Front-end Style Guide?

Benefits of front-end style guides A front-end style guide is a declaration of an agreed and tested way that a site’s owner wants it to be maintained. The more accessible this documentation is, the easier it’ll be for other people to use. If the documentation isn’t there, people are going to have a hard time maintaining the site. Preparing a style guide improves standards: you’re likely to be more thorough in your decision-making.

INCREASE INTEGRITY If it’s comprehensive enough, a style guide will reduce the likelihood of naked (unstyled) elements. Elements that often get missed out in design mock-ups include styles for the different list types, tables, form fields, block quotes, and hover, active, and focus styles on links. Rather than asking the designer to style every possible element, create something the designer can refer to and tweak. A basic stylesheet, complemented by a style guide showing how elements look, makes it easy to sit down with the designer and work through it. Creating a basic boilerplate stylesheet means you don’t have to start from scratch for every project. If you often add the same CSS to every project (say, removing bullet points from lists within a
element), a 23

boilerplate stylesheet can help. You can add accessibility benefits as well, such as giving abbreviations a dotted underline, so they’re present in all your projects from the start.

ENCOURAGE MAINTAINABILITY Designing for maintainability isn’t just about ‘what happens if I look at this in 2 years time’, it’s about writing good quality code now. —Natalie Downe, “CSS Systems for writing maintainable CSS”, 27 September 2008 Producing a style guide encourages more meaningful code. Just writing a style guide forces you to think about the semantics of the elements you’re using. My markup has become more thoughtful since I set out to make it publicly accessible and engaging: I want people to read it and use it! A style guide also promotes writing object-oriented CSS and developing distinct, reusable modules rather than binding functionality to a particular page. Building the foundations of a style guide during the design phase should reduce the number of CSS overrides and help modularise your site build.

EDUCATE YOUR TEAM AND CLIENTS A style guide can help clients to think of websites as systems rather than distinct pages. It can also promote best practice. Write up why you’ve done something a particular way and others will follow. By reading Paul Robert Lloyd’s Barebones style guide, I learned when elements like and are most effective and appropriate. Reflect on the techniques you’ve adopted: are they still worth following, or are they merely how you’ve always done things? 24 BOOST QUALITY ASSURANCE TESTING A web-based front-end style guide makes browser testing straightforward: just load it up to test all the features. Assess your style guide frequently, such as at the end of every sprint, testing in multiple browsers and devices as you build. Using tools like Ghostlab, Browsersync, and BrowserStack, you can check your style guide on multiple browsers and devices simultaneously. Run this testing throughout the build, otherwise it will become a source of stress right before a deadline. When you’re rapidly iterating, inconsistencies can creep in. Having all your modules in one place during code review helps keep track of what’s new, what’s a duplicate, and what’s not being used. CATCH ACCESSIBILITY ISSUES Installing a browser plugin such as total11y allows you to review common accessibility issues like colour contrast. 25 Here, total11y has flagged up where text doesn’t contrast enough with the background to be easily readable to people with low vision. Having all your patterns listed on one page means you can test them at once without having to go through every single template. If you start building your style guide during the design phase, you’ll be able to catch accessibility issues when they’re easier to fix. In a previous client project, we tested the style guide in different browsers very early and realised our web font looked terrible in Internet Explorer. If we’d noticed weeks into the build, it would have taken a lot more work to change. TRACK PERFORMANCE You can also use front-end style guides to measure how different features are going to affect performance. Working on Radio Free Europe’s redesign, Dan Mall and Tim Kadlec were told that, because of the nature of the content, some of the site’s users had been jailed or hanged just for accessing the site. Some of these people have been jailed or have been hanged just for accessing their website. So we can’t have a page loading in thirty seconds; that just can’t fly. —Dan Mall on Radio Free Europe’s style guide Since performance in this project was critical, Dan and Tim thought about performance from the beginning and let it influence their design decisions. Tim even created a Grunt task to measure how fast each pattern was loading. Lonely Planet also think a lot about performance. Each JS and CSS file has performance statistics logged in the style guide, and changes to these statistics are highlighted and plotted on a graph. 26 Lonely Planet’s performance monitoring from within their style guide. Lonely Planet’s method is a great way to visualise which files can be optimised to make the most impact. Since the performance statistics are public, there is an incentive to optimise aggressively and prevent file sizes creeping up with each release. ACCURATE PROTOTYPING Building elements straight in code gives a more realistic representation of how a design will look and feel. You can show it on different devices and browsers, get feedback straight away on whether something is going to work in practice, and address issues early on. Every time you build a new but commonly used feature, such as an image with a caption or pagination controls, remember to pull the module into your style guide. That way, you can use the style guide as a prototyping tool, slotting modules together to test new ideas. By using real code rather than a design tool, you’ll be able to see exactly what a new feature will look like on different devices, and how it will work alongside existing components. 27 Demonstrating how a design adapts on real devices rather than in static mock-ups makes responsive design discussions easier. Front-end style guides are also invaluable as a way of delivering work, especially in Agile projects where different parts of a website may be completed at different times. Rather than getting feedback on a whole system at once, you can deliver parts of it, and really focus that feedback on the individual components. BETTER INTEGRATION Your style guide can serve as a specification for developers who are doing CMS integration. Developers can see an overview of which modules need to be built and roughly how they’ll work. Adding usage notes alongside each module can be valuable. I record things like “This abstract has a maximum character count of 200” or “This is a byline. An article can have multiple authors, so the editor should have the option to add more than one”. Try to anticipate as many questions as possible and add answers as usage notes to make handover easier. Front-end style guides can also be a useful reference for content editors. Unless you’re using a WYSIWYG editor in a CMS, it can be difficult to know how content will look, or what styles exist and how to select them. If editors have to use Markdown, showing Markdown syntax in the style guide can act as a useful cheat sheet. 28 The South Tees Hospitals website is built with WordPress, so the style guide includes shortcode snippets that can be copied and pasted into a template. Offering shortcode instead of full markup can be more user-friendly than expecting an editor to grab some markup and edit the relevant content without making any errors. HELP RECRUITMENT While interviewing people on the Style Guide Podcast, Brad Frost and I found a common theme: companies that made their front-end style guides public found job applicants specifically mentioned the style guide as a reason for applying. When I saw it I thought it was beautiful and it’s why I wanted to join this team. —Jina on Salesforce’s style guide 29 Some style guides, like uSwitch’s, include a link to their recruitment page. Public front-end style guides attract a certain audience – often the very people you want to hire. Drawbacks of front-end style guides Style guides aren’t ideal for every project. The main objection is that it takes time to produce them. However, creating a generic guide that can be adapted for any project will save time in the long term. GUIDANCE CAN BE TOO INFLEXIBLE In 2012, Geri Coady wrote a blog post on the problem with style guides, arguing that some style guides can be so strict they do brands a disservice. Her post is worth reading because it addresses challenges that people using style guides can face and advises how you can avoid stifling creativity. 30 While it’s very important to keep the most critical elements of a brand consistent across all materials, there should be more opportunity for discussion with the brand guardians if new ideas are proposed. —Geri Coady, “The Problem with Style Guides”, 30 October 2012 Mark Boulton also talks about the perils of enforcing too much control: Policing a design system never works in my experience. It never works because people don’t like rigid systems, being told what to do, and will straight up do the opposite. Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it. —Mark Boulton, “Design systems and Postel’s law”, 17 May 2016 The emphasis here lies on “collaborate”. People will resist adopting a process they don’t feel a part of. Get team members involved in planning and building the style guide right from the start so they are more likely to want to maintain it. NEED INVESTMENT AT THE START Don’t wait until the end of the project to build a front-end style guide. Start putting it together from day one. Otherwise it’ll be a snapshot in time that people are less likely to maintain because they don’t feel emotionally invested. This is why it’s important to get the whole web team involved in making and maintaining it. That being said, you can still make a front-end style guide if the site already exists. It’s harder to do at this stage, but it can be a useful part of an audit into a site’s design and front-end code. Putting a style guide together post-build can take longer than if you were to start from scratch, especially if there’s poor documentation. You can end up on a treasure hunt for modules, and you’ll probably find instances where the same module is styled slightly differently in several places for no clear reason. Making a 31 front-end style guide after release is particularly challenging if the design hasn’t been built as a system: you have to determine whether a heading is styled differently because it’s part of a logical design language, or just a designer’s preference for blue. This is why it helps to create style guide components during the design stage, before development (you’ll probably already be doing something similar if you’re working in an Agile environment). You define default styles then explain when, why, and how they can be overridden. The process of building a style guide acts as a design audit of the site, and you can often find ways of merging two (or more) similar styles. If you have to create a style guide after the build, get your designers’ feedback on when certain modules need to be styled differently. Try to eliminate duplication. If the designer understands basic CSS and can get in the stylesheet and tweak the margin, padding, line height, and font sizes, so much the better. REQUIRE CONTINUED MAINTENANCE Zombie style guides — style guides that aren’t maintained and part of your process. They die and rot. They eat your brains. —Tweet from Jina, 2 Sep 2015 A style guide that’s out of date is almost as useless as no style guide at all. The ongoing challenge is making style guides that are powered by the live site, using the same styles, the same content, and the same codebase. One way to make sure your style guide is kept up to date is to appoint someone on the team as an evangelist: someone who keeps it in check, and makes sure new patterns are always added. For example, there’s an entire team at the Marriott International hotel group dedicated to maintaining their style guides. 32 While most companies are unlikely to be able to justify that outlay, having someone regularly checking and maintaining the style guide and nagging others to contribute and refer to it will go a long way. Ian Feather worked on a clever strategy to stop Lonely Planet’s style guide becoming zombified: the team hooked the style guide up to an API, meaning the markup used is synced with the live site. Lonely Planet call their system “Rizzo”. Rather than have HTML snippets displayed alongside components, they display the code needed to pull in the markup. Ian built two previous versions that became zombies, but now the style guide has an API, it’s always up to date and doesn’t require active maintenance. NOT A REPLACEMENT FOR CONVERSATIONS No matter how good your pattern library or documentation is, it’s not a replacement for talking to the client or the rest of your team. A style guide 33 isn’t something to build, hand over, and forget about. Dan Mall adopts the approach that every deliverable has to come with a proper conversation: “Don’t rely heavily on a deliverable to solve this for you: rely on your listening skills to solve it for you”. Documentation is like a plant – without care it will wilt and die. If you grow it with the team who are inheriting it, and they take part in nurturing it from a seedling, they’ll know how to look after it when you’re not there. Present it to them at the end of the project and they’ll leave this strange gift in the darkest part of the office until no amount of water will revive it. 34 Building Your Own Front-end Style Guide While there are many tools out there (see “Tools for making front-end style guides” later in the book), this section discusses building your own style guide from scratch. Step 1: Conduct an interface audit If you’re creating a new style guide for an existing site, it’s often an opportunity to standardise the design, and check with the designer that they didn’t unintentionally create two styles for the same thing. If you’re trying to convince someone of the value of creating a style guide, an interface audit will highlight just how useful a style guide could be. An interface audit involves going through a site, taking screenshots of every unique style (for headings, radio buttons, tabs, icons and so on) and placing them in a document. By collecting every element, you can check for styles that could be removed, merged, or replaced by existing styles. Consolidating styles makes the code leaner and the site more visually coherent and easier to maintain. 35 Brad Frost conducted an interface audit on his bank’s website to demonstrate how many different button styles there are. In his post on the topic, he also audited the buttons on a site that had a style guide. Unsurprisingly, the latter had fewer button styles. Sometimes many different styles are justified, but they must all have a reason for existing, ideally with their intended purpose documented in the component’s usage notes. Be aware that for every additional style, you’re increasing your code footprint and maintenance needs. In a talk about real estate business Trulia, Nicole Sullivan highlighted the importance of building a living style guide to improve the performance of front-end code. By auditing the site’s components, she was able to spot style duplications in the CSS and design inconsistencies, which are common when sites grow organically. After refactoring the code, she had reduced the HTML by 48 per cent, removed 135 KB of unused CSS, and made load time 21 per cent faster. Step 2: Create a boilerplate 36 You can save time spent setting up basic styles by creating your own boilerplate to reuse and modify for different projects. You could follow a simple recipe such as a page containing styles for simple elements like paragraphs, headings, and links, or you could build a complex collection of modular site patterns. You might already have the foundation of a front-end style guide in the form of a reset stylesheet. Create a basic HTML page with all the relevant text elements and you can check that your basic typography looks good. There are plenty of primers and boilerplates out there to help you get going. My favourite is Paul Robert Lloyd’s Barebones, which I’ll refer to several times in this chapter. Barebones is aesthetically neutral, which is one of the reasons I like it, but is specific to Paul’s needs, so you’ll need to customise it for your own use. Analyse each part and understand what it does before deciding whether it needs to be in your version. For your reusable foundation, your default styles should be as neutral as possible to make them easy to override and so they work in many situations. The HTML5 Boilerplate used to set the ::selection colour set to bright pink, making it easy to know which sites used the boilerplate just by highlighting text. On sites where this default had not changed, the style often looked out of place. To explore which components can have a place in a style guide, Tyler Sticka’s Styleguide & Boilerplate patterns spreadsheet lists many web style guides and the elements and features they include. BOILERPLATE TEXT ELEMENTS Start by creating an HTML page containing all the text elements you might have on a page: headings, links, paragraphs, emphasised and strong text, lists, and so on. Add headings with links, headings in lists, and maybe even elements you don’t use often, like and . 37 Once you’ve added a few text elements, add some styles in a CSS file. Check the base font size and line height work well together, and that nested lists don’t look cramped. BOILERPLATE TABLES AND FORMS Unless it’s an information-heavy site, I rarely see tables or forms in design mock-ups. The default browser styles aren’t pretty, so you should add some basic styles. This is a good opportunity to try the newer HTML input types like color and datetime to see how colour and date pickers will look. Remember to consider how tables should work if they’re wider than the content area. Demonstrate validation: what does a form look like when someone has entered an invalid email address? Consider inline messages such as “Please enter a valid email address”, messages about data submission like “This form contains some errors”, and messages about the page such as “This page has been saved”. Do you need a disabled button state? How should required fields be styled? 38 BOILERPLATE INTERACTIONS Design mock-ups often miss out how elements should look in various different states, particularly the focus state, which is important for keyboard and D-pad users. If no focus state design has been specified, I set it to match the hover style, but sometimes it’s handy to provide further visual feedback, such as a yellow background. Active states give feedback that’s especially useful for touch screen users. It’s like the down state when you press a button. Visual feedback confirms to users they have activated a button or link. The Draft US Web Design Standards style guide demonstrates the states of their different buttons. They also offer extensive documentation on when it is (and isn’t) appropriate to use these buttons, what sort of text is appropriate to have inside them, and button accessibility considerations. Step 3: Start regression testing 39 Check your default styles in different browsers and on different devices. Does anything break? Is text readable on a small-screen phone and a widescreen TV? Do links have enough contrast on low-resolution screens? Don’t forget to check how the page looks when it’s printed, and add print styles where necessary. This might seem like a lot of work, but if you get the basics right now, testing will be easier later on. Step 4: Build the components With your basic styles in place, start building a collection of components like progress bars, pagination, and carousels. Only add components that are needed. MailChimp only add new patterns when there’s a sound case for doing so, because new patterns come at a high cost in terms of additional code, maintenance, and increased cognitive load on users. MailChimp know that the more they add to their style guide, the more features they have to support and the more complex the style guide (and the site) gets. Aim to make all your components self-contained so if the component becomes obsolete, you can remove it without breaking something else. If you’re using Sass or Less, these files should have the same name as pattern files so they’re easier to find, and so you can see that the matching files are related. The width of the components should be independent of layout, so you can fit them into any space. That way, if the layout changes, you won’t have to update the patterns – they’ll just work anywhere. This technique is essential for responsive websites. Once you’ve built up a decent collection of components, put them on one page along with the corresponding markup. 40 In Barebones, the code is tucked away in a that has a show/hide toggle so the page isn’t too long; style guides for big sites can become unwieldy. Include whatever code – HTML, Markdown, or similar – someone would need to replicate that module on the site. Grabbing a style and reusing it on the site should be as simple as copying and pasting the relevant markup. Look at the editing interface of your CMS to uncover other elements to add, the ones that editors will need to use. Some CMSs spit out deprecated or unsuitable markup: tags instead of , and for (not ideal, but often out of your control); if markup like this is unavoidable, make sure your styles imitate those of the desired markup. For example, and tags should look the same where they’re being used interchangeably. Every component should have a unique name, clearly displayed. This shared vocabulary is important to remove ambiguity when referring to a particular pattern. It’s also helpful to ensure each component can be 41 accessed at a URL, meaning people can refer to it directly in online discussions. In her article “From Pages to Patterns: An Exercise for Everyone” for A List Apart, Charlotte Jackson outlines a team exercise for choosing component names. This exercise helps the team feel more invested in the style guide, which is important if you want it to be adopted and maintained over time. Usage descriptions and examples are particularly pertinent for content editors; for example, when and how to use strong text, block quotes, or definition lists. You can also add CMS integration instructions here, as mentioned earlier. When I write styles for the style guide itself, I prefix all class names with “.xx” so they’ll never clash with the main site styles. Some style guides take this further and display components in iframe s to avoid clashes with the library wrapper styles. FALLBACKS As you go, check your modules degrade gracefully when JavaScript is disabled, when they’re viewed in older browsers, and when images or SVGs don’t load. DESIGN FOR THE UNEXPECTED, CODE FOR THE EXTREMES Very long headings or double-barrelled names can cause unexpected problems, so your content examples should respond well when text flows onto multiple lines or is bigger than its container. Use the style guide as a way to show these extremes and prove that you can deal with these situations. On a news site, for example, how will the homepage look when two huge stories break at once? For a train company’s site, how would you inform 42 customers about all services being suspended due to industrial action? If you’re designing a site selling products, how would a product recall look? Rather than designing for any and every possibility, create a general style for vital and time-specific information. Step 5: Make the finishing touches NAVIGATION If your style guide is getting long, a table of contents will make finding a module easier. Some style guides split components into sections with navigation down the side. Others display everything on one page, with a select box to choose a specific component. While I prefer style guides where everything is displayed on one page – making it easier to spot style conflicts, and only needing one page load when testing on different devices – single-page style guides can get unwieldy. Splitting modules onto different pages also means you can group them by type. A common navigational structure is to group basic element styles (bare paragraphs, links, and headings) into their own section, followed by forms, navigation (site, pagination, breadcrumbs), and then components, often split into further groups. SWATCHES A common use of a style guide is to reference a particular colour. For example, if I need to use the brand colour, rather than hunt around in the site CSS, I’ll look in the style guide. If you’re using Sass or Less, put the variable name used for it next to the colour swatch. 43 The Bristol City Council website has colour swatches with names, hex codes, and an explanation of when each colour is used. You may want to include typography in a similar way, along with the font stack to show what the fallbacks are. Fallbacks are sometimes neglected, but your style guide is a great place to test them. You could even go further by adding a toggle that disables custom fonts for testing. ASSETS AND DOWNLOADS A style guide is also a great place for social media icons, backgrounds, logos, and other brand assets, so everyone has the correct versions in one place. No more lifting a pixelated logo off Google Images, or grabbing an old version of the Twitter logo. Like an identity style guide, you can include guidance on how to apply the branding along with downloadable assets. Consider your audience and make sure the style guide isn’t overwhelming for a non-designer. 44 LOCALISATION If your site takes text direction into account (perhaps through translation into a language read right-to-left, such as Arabic), you may need to adapt your styles. You could add a toggle on relevant elements to change the text direction, to check nothing breaks when the language isn’t written left-toright. BBC GEL’s right-to-left toggle on their style guide MOTION AND TRANSITIONS Perhaps your site uses transitions such as fade-outs. You might want to document these to ensure consistent timings are used, and code isn’t duplicated accidently. If you’re using a CSS preprocessor, create variables or mixins for these animations so they’re easier to reuse, and record the variations in your style guide. 45 Salesforce’s Lightning Design System has interactive demos of the animations they use. GRIDS AND TEMPLATES It’s a good idea to document your grid system to demonstrate how to make layouts. You can explain some of the theory behind grid systems to educate anyone who might work on your system in future. Starbucks’s style guide adds a toggle with debugging information such as screen width and grid and baseline overlays to demonstrate the dimensions. 46 RECRUITMENT CALL-TO-ACTION If you’re looking to increase the size of your team, link to your jobs page on your style guide. As mentioned before, style guides are a terrific recruitment tool and a way to show off your design and development chops. RELEASE NOTES Some style guides come with release notes to communicate changes. Large sites – where a minor CSS change can cause a big impact – may opt for version numbering, along with “alpha” and “beta” flags on individual modules. Buzzfeed’s style guide, Solid has release notes to help communicate when and why changes were made. The handover 47 When presenting your style guide to your client or team, some people will immediately see its value, and others won’t. Tailor your style guide’s format to the people who are going to be using it the most. Within the style guide, you could list who worked on the project, along with their contact details. It’s like being given a manual for your new house, with details of who did the plumbing in case your tap springs a leak, and what type of light fittings are used so you know what type of bulb to buy when one blows. Make your style guide public Many front-end style guides have been published online, which is not only a generous gesture, but also demonstrates that an organisation values code and design. Publication makes the style guide more accessible to content creators and external agencies, and when it’s public there’s more motivation to keep the code clean and up to date. Sharing was one part, the other part’s just kind of keeping us honest and making sure that we’re taking care of it, we’re maintaining it, just knowing that other people are looking and it’s a resource that just makes us feel like we have to keep up with it. —Federico Holgado on MailChimp’s Pattern Library In addition to the recruitment benefit, publishing your style guide also opens the doors to people outside your organisation to improve your design and code. A week after the US Web Design standards went live, Maya Benari tweeted that they’d merged nine pull requests from people outside government. In our first week since our debut, we’ve merged 9 PRs from non-govies on the U.S. Web Design Standards. Thank you! 48 —Tweet from Maya Benari, 3 October 2015 Consider publishing your style guide on a public repository like GitHub so people can submit changes and flag bugs. 49 Front-end Style Guide Examples and Tools Some of the following style guide examples are for large sites, some for small personal sites, and others are systems designed for reuse. They each face different challenges we can learn from. Don’t be intimidated by how these examples look. Your style guide doesn’t have to be a work of art. Sure, it helps if it looks nice because people will feel more proud of it, but a style guide is a tool. Start small and simple, and build on it as and when you can. Front-end style guide examples DRAFT US WEB DESIGN STANDARDS Inconsistent UIs across government websites spurred 18F – an office within the US General Services Administration – to put together the US Web Design Standards. It’s exciting to see governments focusing on style guides not only as a way to make their sites less confusing to users but also as a way to save public money – they’re not having to reinvent the wheel with every new site. 18F have put together a set of common UI elements that have already been usability-tested and meet accessibility standards. These components are intended to be reused to maintain visual consistency across US government websites. Alongside the patterns are guidelines on how to adapt them in a way that maintains these standards. 50 We aim to give the American people a sense of familiarity when using government services, while allowing agencies to customize these tools to fit their unique needs. —18F, on the US Web Design Standards 18F haven’t just open-sourced their code; they are open-sourcing their workflow and research. There’s a Trello board for the MVP (Minimum Viable Product) of the US Web Design Standards, and it’s public, so you can see discussions that went into designing components – like this date picker, based off one the GOV.UK team built and wrote about. 51 A discussion on 18F’s MVP Trello board about the GOV.UK date picker. It’s fantastic to see a government’s web team share their research publicly, which then influences the decisions another government’s web team makes. LONELY PLANET As well as a clever API that injects live content, Lonely Planet’s “Rizzo” style guide has other neat features. The Lonely Planet style guide has a section devoted to design assets: colours, typography, and icons. You can search for an icon and select its colour via a dropdown. A JavaScript section demonstrates how interactive components work and the parameters that can be changed. There’s also documentation on Git workflow, the decision-making process behind moving from icon fonts to SVGs, and code conventions for writing JavaScript and CSS. 52 The style guide has plenty of examples to clearly demonstrate how changing different parameters affects the generated component. It’s a well-considered and -structured style guide with lots of inspiring examples. THE BBC GLOBAL EXPERIENCE LANGUAGE The BBC has produced a style guide called Global Experience Language (GEL) for its web products. GEL also covers the specifics of designing for TV, mobile, and tablet. I recommend studying it because GEL is packed with insights. Since the BBC has a massive audience, its design teams spend a lot of time thinking about and researching design for diverse environments. 53 GEL has come a long way in the past few years – it’s not just a style guide but a repository of well-written research about topics like motion, grids, and designing for touch. Sadly, it still lacks code examples, with design patterns presented as screenshots rather than snippets of code, but I like the direction it’s heading in. LIGHTNING DESIGN SYSTEM When creating your style guide, it’s important to think about your audience. While some style guides are made public to showcase a company’s design and development expertise, Salesforce published their Lightning Design System for developers who are building apps used by Salesforce customers. Salesforce wanted to make a seamless experience between their core and third-party apps. The Lightning Design System is extensive and detailed, leaving less margin for misinterpretation. 54 Components have flags indicating whether their development is stable or deprecated. The style guide includes accessibility guidelines and a per-component breakdown of the class names used and whether they’re required. Having to justify every class ensures only what’s needed is included. CODE FOR AMERICA Code for America have a team of staff and volunteers who maintain a range of microsites for each city, so their style guide offers relaxed guidelines that allow people creativity in appropriating their city’s microsite to its individual culture. The Code for America style guide is also open source, with lots of contributors . 55 The Code for America style guide has reusable design assets such as logos and icons, and documentation on how the grid system works. All components are listed on a single page and at the full width of the screen to make device testing easier. There are also examples of the components in situ in example templates. Tools for making front-end style guides The list of style guide tools is ever growing, so your best bet is to head to styleguides.io where you can find tools specific to the language you’re working in. Here are a few of my favourites. PATTERN LAB If you’re looking for help generating a style guide, Pattern Lab is a great tool. Brad Frost, Dave Olsen, and Brian Muenzenmeyer’s tool splits groups of content into atoms, molecules, organisms, templates, and pages, which come together to form a “pattern lab”. 56 Atomic design gives us the ability to traverse from abstract to concrete. Because of this, we can create systems that promote consistency and scalability while simultaneously showing things in their final context. And by assembling rather than deconstructing, we’re crafting a system right out of the gate instead of cherry picking patterns after the fact. —Brad Frost, “Atomic Design”, 10 June 2013 The responsive pattern lab is an example of the Pattern Lab system. It can toggle the width of the container so you can quickly see what templates look like at different viewport sizes, and you can manually edit the viewport width in ems. Pattern Lab may be more than a small site needs, but it’s ideal for larger sites with multiple templates. It has many useful features and supports multiple languages. FRACTAL Built by Mark Perkins, Fractal is a tool for creating living component libraries. It uses Node.js, and like Lonely Planet’s living style guide, it can 57 pull in live content via an API, so the markup for the components in the library can be from the same codebase as the components used on the site. Fractal generates multiple outputs for components – raw HTML, template code, JSON and even the CSS it uses. It can also display detailed information about a component (such as what other components reference it), and allow you to add usage notes. Fractal is used for documenting 24ways.org’s components. The website’s CMS is Perch, and the Perch snippets required to populate the site are displayed in Fractal’s “View” tab. As a system, Fractal is comprehensive and flexible – an excellent framework for building living style guides. TYPECAST 58 Typecast is purely for prototyping typography in the browser. You can style text, change the typeface and font size, and see how it looks. Padding, margin, and line heights can be tweaked, along with a baseline grid, and it generates decent CSS. Typecast gives you default text to style – headings, paragraphs, lists – and you can simply click on an element to change its style. I’m not sure whether to call Typecast a true style guide – it doesn’t, for example, generate colour swatches, but it’s great as a first step. Since text is such a big part of a website, designing the typography first will help set solid foundations. You can paste in your own content and choose from thousands of fonts. It also outputs a stylesheet, generates a style guide, or you can download a PDF of the styles you’ve created. Since Typecast is built specifically for the web, measurements are in pixels and ems. KSS KSS is a documentation syntax that generates a style guide via comments in your CSS. You write sample markup in your CSS files as comments, and KSS turns these into a style guide. It demonstrates interaction states well and outputs usage notes, markup, and the classes needed to customise an element. One downside of KSS is you end up duplicating your markup – once for the site and once for the style guide. CRAFT This isn’t strictly a tool for building a front-end style guide, but it’s still worthy of a mention. If your workflow is still heavily ingrained in using graphics software, Craft by InVision will eliminate the problem where multiple mockups have to be edited when a single style changes. It’s a set of graphics software plugins that allow you to pull in live data from your API into your designs, and keep your assets in sync with your team. 59 Designing with real data will help make your mockups more representative of what they’ll look like on the live site. 60 The Future of Front-end Style Guides It feels like we measure the success of a web project the day it launches – does it look good, do people like it, does it allow visitors to do what they need? It’s better, though, to measure success over time. Websites are like houses – sometimes we are their architects, and sometimes we are building managers. It’s all very well to build a beautiful house, but if it becomes uncomfortable to live in over time and we can’t easily modify it, it’s not done its job. Dan Mall proposes baking in time after the project to revisit the style guides he delivers to clients. This is brave, because it admits the system is not going to be perfect at first. Dan uses this extra time to see what’s working, what’s not working, and how the style guide can be improved, making tweaks based on this feedback. This approach should be adopted for any project. It’s not right to throw documentation at a client, hope for the best, and then dust your hands off. When you deliver your style guide to the client, it should be like handing over a welcome manual to a new house. It should explain what light bulbs are used and where to buy them, the contact details of a reliable electrician and plumber, the type of floor cleaner to use, and Pantone numbers of the paint used if you need to make touch-ups. Front-end style guides offer a gateway to a more systematic approach to development, aligning with principles such as making code more DRY (“don’t repeat yourself”) and techniques like OOCSS (object-oriented CSS), SMACSS (scalable and modular architecture for CSS), and BEM (block, element, modifier). 61 We should design websites to be flexible and easy to change so they can respond to a business’s changing needs. They should remain as comfortable (if not more) to live in over time as they were when first built. A front-end style guide offers a way to do this, providing the framework and tools required to maintain a site’s cohesiveness and functionality. A style guide isn’t a silver bullet – it needs good practices, care, and attention. Its success should be measured not by how good it is when it launches, but by whether it is kept up to date and referred to months, even years, later. 62 Further Reading I have set up a repository on GitHub with Brad Frost that brings together tools, examples, books, podcasts, presentations, and articles about style guides. Over 300 resources have been added by the community: styleguides.io. I also ran a podcast with Brad about style guides. It’s a short series with twelve guests. Many of the quotes in this book were taken from that podcast. 63 64 </div> </div> </div> </div> </div> </div> </div> </div> <div class="modal fade" id="report" tabindex="-1" role="dialog" aria-hidden="true"> <div class="modal-dialog"> <div class="modal-content"> <form role="form" method="post" action="https://idoc.tips/report/front-end-style-guides-anna-debenham-2-pdf-free" style="border: none;"> <div class="modal-header"> <button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button> <h4 class="modal-title">Report "Front-End Style Guides - Anna Debenham"</h4> </div> <div class="modal-body"> <div class="form-group"> <label>Your name</label> <input type="text" name="name" required="required" class="form-control" /> </div> <div class="form-group"> <label>Email</label> <input type="email" name="email" required="required" class="form-control" /> </div> <div class="form-group"> <label>Reason</label> <select name="reason" required="required" class="form-control"> <option value="">-Select Reason-</option> <option value="pornographic" selected="selected">Pornographic</option> <option value="defamatory">Defamatory</option> <option value="illegal">Illegal/Unlawful</option> <option value="spam">Spam</option> <option value="others">Other Terms Of Service Violation</option> <option value="copyright">File a copyright complaint</option> </select> </div> <div class="form-group"> <label>Description</label> <textarea name="description" required="required" rows="3" class="form-control" style="border: 1px solid #cccccc;">

Front-End Style Guides - Anna Debenham

Recommend Documents