Taming CSS Complexity is a collection of 11 CSS-packed chapters that are all about performance- and developer-friendly coding. In order to achieve a well-rounded coding experience, the Smashing Magazine authors have explored the complexity of CSS from different perspectives, balancing rather specific hands-on tips and more general coding best practices.
Among other hot topics, this eBook covers how to design layouts with Flexbox, Atomic Design with Sass, and takes a look at the most common CSS issues. Experimental techniques such as the “Clown Car Technique” provide innovative approaches to new challenges, and an insight into the BEM methodology helps to improve the overall quality of front-end code. To simplify your daily coding routine, valuable tricks on how to structure and style your code have also been included in this eBook.
TABLE OF CONTENTS
- Semantic CSS With Intelligent Selectors
by Heydon Pickering
- Absolute Horizontal And Vertical Centering In CSS
by Stephen Shaw
- How To Benefit From CSS Generated Content
by Gabriele Romanato
- The Problem Of CSS Form Elements
by Gabriele Romanato
- Clown Car Technique: Solving Adaptive Images In Responsive Web Design
by Estelle Weyl
- The "Other" Interface: Atomic Design With Sass
by Robin Rendle
- Simple Responsive Images With CSS Background Images
by Stephen Thomas
- Designing CSS Layouts With Flexbox Is As Easy As Pie
by David Storey
- The Evolution Of The BEM Methodology
by Maxim Shirshin
- Using White Space For Readability In HTML And CSS
by Louis Lazaris
- Why Coding Style Matters
by Nicholas C. Zakas
- Formats: PDF, EPUB, Kindle (DRM-free)
- Pages: 169
- Language: English
- Released: October 2013
- Publisher: Smashing Magazine GmbH
- ISBN (PDF): 978-3-94454054-2
- ISBN (EPUB): 978-3-94454055-9
- ISBN (KINDLE): 978-3-94454056-6
Excerpt From Chapter 1
Semantic CSS With Intelligent Selectors — by
“Form ever follows function. This is the law.” So said the architect and “father of skyscrapers” Louis Sullivan. For architects not wishing to crush hundreds of innocent people under the weight of a colossal building, this rule of thumb is pretty good. In design, you should always lead with function, and allow form to emerge as a result. If you were to lead with form, making your skyscraper look pretty would be easier, but at the cost of producing something pretty dangerous.
So much for architects. What about front-end architects — or “not real architects,” as we are sometimes known? Do we abide by this law or do we flout it?
Excerpt From Chapter 6
The “Other” Interface: Atomic Design With Sass — by
As front-end developers and designers, we’re constantly refining two interfaces simultaneously: one for visitors who load the website, the other for developers who have to tackle the code in the future, when ad- justments or full-scale redesigns must be made. Yet we tend to assign the role of “user” to the first group, often forgetting that the code we write must work for developers in a similar way. We shouldn’t forget that developers are users, too.
If this is the case, then our convention for naming and organizing files is critical if we are to ensure active (and efficient) development in the future. But do we really design the partials, files and directories that make up this interface with a particular set of users in mind, with a set of clear goals, combined with precise, well-defined documentation? I don’t think we do.