Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Four Noble Truths (of Stylesheets)

The Four Noble Truths (of Stylesheets)

Chris Eppstein

June 30, 2012
Tweet

More Decks by Chris Eppstein

Other Decks in Technology

Transcript

  1. The Four
    Noble
    Truths
    (of Stylesheets)
    Saturday, June 30, 12

    View Slide

  2. You are suffering.
    (we were too)
    http://inguen.blogspot.com/2009_02_01_archive.html
    Saturday, June 30, 12

    View Slide

  3. STYLESHEETS
    are the source of your suffering
    http://wikibon.org/blog/wp-content/uploads/2011/10/5.„eg
    Saturday, June 30, 12
    It is the nature of CSS to devolve into madness.
    Duplicated styles, code spaghetti, inconsistent UI, lots of decision-making and no clear path.

    View Slide

  4. You can be free from
    suffering.
    http://www.indiegamemag.com/media/lightbulb.jpg
    Saturday, June 30, 12
    You don’t have to live like this.

    View Slide

  5. Living style guides &
    self-discipline
    will free you from your suffering
    http://www.tsf.net.au/gallery/var/albums/Tidy-Cabling/46-cluster_back2.„g?m=1294131614
    Saturday, June 30, 12

    View Slide

  6. Development
    Speed
    Re-use
    Flexibility
    Repetition
    Requires
    Reduces
    Requires
    Reduces
    Saturday, June 30, 12
    These tradeoffs are fundamental to software.

    View Slide

  7. “Why is it so slow to make new
    pages that look similar?”
    Hand coded CSS
    Saturday, June 30, 12

    View Slide

  8. I need to reuse my classnames.
    Saturday, June 30, 12

    View Slide

  9. and save time
    Saturday, June 30, 12

    View Slide

  10. There we go
    Saturday, June 30, 12

    View Slide

  11. I’m so fast now.
    CSS
    FRAMEWORKS
    Saturday, June 30, 12

    View Slide

  12. “Change this bit here, will ya?”
    Saturday, June 30, 12

    View Slide

  13. But if I change that, it will affect
    these other things.
    Saturday, June 30, 12

    View Slide

  14. “Why?
    They’re not related.”
    Saturday, June 30, 12

    View Slide

  15. I need to NOT reuse my
    classnames. Sometimes.
    Saturday, June 30, 12

    View Slide

  16. I’m so flexible now.
    Scoped Sass Styles
    &
    Content Semantics
    Saturday, June 30, 12

    View Slide

  17. “Why is it so hard to roll out
    this change across the site?”
    Saturday, June 30, 12
    It’s faster than it was,

    View Slide

  18. I didn’t know those
    things were related.
    Saturday, June 30, 12

    View Slide

  19. “Of course they are!”
    Saturday, June 30, 12

    View Slide

  20. Make design-oriented concepts
    that can vary in appearance.
    Saturday, June 30, 12

    View Slide

  21. Application
    Concept
    Framework
    Let’s work on this together.
    Saturday, June 30, 12

    View Slide

  22. “Change how this concept looks?”
    “Use this concept instead.”
    Saturday, June 30, 12

    View Slide

  23. No problem.
    Saturday, June 30, 12

    View Slide

  24. “Perfect!”
    Saturday, June 30, 12

    View Slide

  25. Good naming of
    appropriate concepts
    is the key to
    maintainable software.
    Saturday, June 30, 12
    This is not just a stylesheet concept. This is a fundamental truth of software development.

    View Slide

  26. How do I know if a concept
    is appropriate?
    Saturday, June 30, 12
    a concept is appropriate if is independent of other concepts or when its relationship to other
    concepts is unambiguous.
    a concept is appropriate if it lives in the application domain.
    a concept is appropriate if it supports the creation of appropriate concepts.

    View Slide

  27. What makes a good name?
    Saturday, June 30, 12
    A good name is short.
    A good name conveys understanding about a concept.
    A good name is omits little knowledge about its concept.

    View Slide

  28. Naming a concept
    changes it.
    Saturday, June 30, 12
    Once you name a concept you change the concept into whatever concept that name invokes in
    another person.
    Any concept worth creating is a concept worth naming well. Take the time to name it right, or
    it will be misunderstood and misused.
    This is the source of most software defects.
    This is hard for designers because they speak a visual language. they can concisely convey
    concepts visually for which there is no concise terminology.
    It’s ok to make up words.

    View Slide

  29. Accept
    your
    Constraints
    http://candidkerry.files.wordpress.com/2011/09/bound-with-chains-of-the-spirit-and-of-men11.jpg
    Saturday, June 30, 12
    We work with browsers and we are beholden to how they work.
    You cannot fight this. You cannot escape it. Accept it.

    View Slide

  30. Fundamentals
    • Reset
    • Additive-only
    • Page Layout
    • Containers
    • Typography
    • Background
    • Foreground
    • Spacers
    • Interaction States
    • Medias
    • Height
    • Differences OK
    Saturday, June 30, 12
    We must embrace these fundamentals. Our concepts cannot fight them or they are not
    appropriate to our application.

    View Slide

  31. Saturday, June 30, 12
    Eric Meyer’s Reset. TURN OFF ALL THE STYLES.

    View Slide

  32. Additive by Nature
    Styles Inherit and Cascade.
    “Turning off” styles is a code smell.
    Saturday, June 30, 12

    View Slide

  33. Constructing an Object
    Saturday, June 30, 12
    From each category you can usually only pick 1 class to apply to the same element.

    View Slide

  34. Constructing an Object
    Saturday, June 30, 12
    From each category you can usually only pick 1 class to apply to the same element.

    View Slide

  35. Constructing an Object
    Saturday, June 30, 12
    From each category you can usually only pick 1 class to apply to the same element.

    View Slide

  36. Constructing an Object
    Saturday, June 30, 12
    From each category you can usually only pick 1 class to apply to the same element.

    View Slide

  37. Constructing an Object
    Saturday, June 30, 12
    From each category you can usually only pick 1 class to apply to the same element.

    View Slide

  38. Constructing an Object
    Saturday, June 30, 12
    From each category you can usually only pick 1 class to apply to the same element.

    View Slide

  39. Constructing an Object
    Saturday, June 30, 12
    From each category you can usually only pick 1 class to apply to the same element.

    View Slide

  40. Constructing an Object
    Unstyled
    Background
    Container
    Typography
    Foreground
    Margin/Padding
    Saturday, June 30, 12
    From each category you can usually only pick 1 class to apply to the same element.

    View Slide

  41. Constructing an Object
    .calming
    .shadow-box
    .reading-text
    .green-bg-type
    .vertically-padded
    Saturday, June 30, 12
    From each category you can usually only pick 1 class to apply to the same element.

    View Slide

  42. Style Concern: Layout
    • Grid - Provides the structure of a page.
    CSS3 will bring alternate layout methods.
    • Page layouts - Defines how primary
    elements adhere to the grid and respond.
    Blog Post
    Saturday, June 30, 12

    View Slide

  43. Style Concern: Typography
    • Defines how a collection of
    typographic elements are styled.
    • Vertical Rhythm
    • There is no default typography.
    Saturday, June 30, 12
    opt-in typography is not the industry standard approach. The industry is mostly wrong about
    this. Typographic inheritance is annoying.

    View Slide

  44. Style Concern: Typography
    • Defines how a collection of
    typographic elements are styled.
    • Vertical Rhythm
    • There is no default typography.
    Opt-in To Typography
    Saturday, June 30, 12
    opt-in typography is not the industry standard approach. The industry is mostly wrong about
    this. Typographic inheritance is annoying.

    View Slide

  45. Style Concern: Typography
    • Defines how a collection of
    typographic elements are styled.
    • Vertical Rhythm
    • There is no default typography.
    Saturday, June 30, 12
    opt-in typography is not the industry standard approach. The industry is mostly wrong about
    this. Typographic inheritance is annoying.

    View Slide

  46. Style Concern: Widgets
    • Styles for your interactive elements
    • SMACSS - Jonathan Snook
    Saturday, June 30, 12

    View Slide

  47. Saturday, June 30, 12
    In order to have consistent breakpoint behavior, Sass 3.2 has new abilities to define
    abstractions around styles using @content.

    View Slide

  48. Saturday, June 30, 12

    View Slide

  49. Height
    Is a Scary Word
    http://edge.ebaumsworld.com/mediaFiles/picture/1918624/81886902.jpg
    Saturday, June 30, 12
    except for positioned content, You almost never want to set the hight of anything that has a
    variable width or variable content (hint: that’s almost everything)

    View Slide

  50. Differences are OK
    http://www.snvdiversityrt.zoomshare.com/files/Diversity_Matters_photo_without_wording_.jpg
    Saturday, June 30, 12
    Pixel perfection is a pipe dream. Embrace progressive enhancement.
    Krys: tell designers this is ok. do you have some tips for how to design with enhancement/
    degredation in mind?

    View Slide

  51. Designer
    Saturday, June 30, 12
    Naming for Intent
    Design is not art. Design is science with an artistic flair.
    Suddenly your designs change, as intent becomes more of a focus than art.

    View Slide

  52. Naming is a
    Collaboration
    Designers must pick or approve the name.
    Unfortunately, designers are not often good at naming things.
    Saturday, June 30, 12
    Coders have to name everything they make, but designers don’t. Naming is a skill that must
    be developed. You have to learn to explain your intuition and instinct.

    View Slide

  53. Naming is Hard
    http://funnyphotosto.com/wp-content/uploads/2012/03/12/screaming.„g
    Saturday, June 30, 12
    Because designers think visually, sometimes a description is actually a paragraph, not just
    one or two words.

    View Slide

  54. Naming Docent
    Developers, your job is to help
    designers develop a shared
    vocabulary.
    Saturday, June 30, 12
    If you are a developer and a designer, you now have an excuse for talking to yourself.

    View Slide

  55. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  56. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  57. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  58. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  59. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  60. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  61. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  62. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  63. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  64. The Name Game
    Saturday, June 30, 12
    THESAURUS!!!

    View Slide

  65. Losing the Name Game
    Saturday, June 30, 12
    Sometimes you cannot find a good name, or you find some use of a design that doesn’t
    match the current name.

    View Slide

  66. Losing the Name Game
    Wait: Don’t name it
    Saturday, June 30, 12
    Sometimes you cannot find a good name, or you find some use of a design that doesn’t
    match the current name.

    View Slide

  67. Losing the Name Game
    Consistency: Change the design
    Wait: Don’t name it
    Saturday, June 30, 12
    Sometimes you cannot find a good name, or you find some use of a design that doesn’t
    match the current name.

    View Slide

  68. Losing the Name Game
    Give up: Pick two names
    Consistency: Change the design
    Wait: Don’t name it
    Saturday, June 30, 12
    Sometimes you cannot find a good name, or you find some use of a design that doesn’t
    match the current name.

    View Slide

  69. The Designer Wins
    http://blog.hubspot.com/Portals/53/images/charlie-sheen-winning.png
    Saturday, June 30, 12
    Don’t force a design change just because a name doesn’t match. Intuition is a tricky thing, if
    you trust your designer, trust their gut feeling. If you don’t trust your designer... :(

    View Slide

  70. Now you understand.
    • My site is so big
    • But I grok the
    fundamentals
    • But OMG where
    do I start?
    Saturday, June 30, 12

    View Slide

  71. CHANGE
    how you think
    Saturday, June 30, 12
    Think of each page, each project, each feature as part of a whole
    When you do this, living styleguide is almost inevitable

    View Slide

  72. Re-approach the Fundamentals
    Saturday, June 30, 12

    View Slide

  73. Styleguides Must
    Live in Code
    Saturday, June 30, 12
    styleguides traditionally are a document
    but no one refers to them so what’s the point
    consistency is the point - so apply the principals of usability and make a styleguide people
    can use
    make it in code.
    This is an actual screenshot of a page of our styleguide.
    But where do you start?
    It's better to show than to tell.
    Make a living styleguide for documentation and prototyping.
    This is your design catalog.
    Teach the design, don't just exemplify it.

    View Slide

  74. Elements
    Saturday, June 30, 12
    It’s common to think of pages in terms of areas, elements, and relationships.
    Have to break that down fundamentally and think of the building blocks of your elements.
    Add to traditional design mindset:
    Interchangeable elements
    Start with your content inventory. Then look carefully at the elements that live around and
    within your content.

    View Slide

  75. Elements
    Saturday, June 30, 12
    It’s common to think of pages in terms of areas, elements, and relationships.
    Have to break that down fundamentally and think of the building blocks of your elements.
    Add to traditional design mindset:
    Interchangeable elements
    Start with your content inventory. Then look carefully at the elements that live around and
    within your content.

    View Slide

  76. Saturday, June 30, 12
    It’s common to think of pages in terms of areas, elements, and relationships.
    Have to break that down fundamentally and think of the building blocks of your elements.
    Add to traditional design mindset:
    Interchangeable elements
    Start with your content inventory. Then look carefully at the elements that live around and
    within your content.

    View Slide

  77. Property Soup Le average sass stylesheet.
    Saturday, June 30, 12
    How should we organize our style properties? Alphabetize them! We
    can do better than this. We will organize our properties by style concern.

    View Slide

  78. Property Soup Le average sass stylesheet.
    Alphabetized
    Saturday, June 30, 12
    How should we organize our style properties? Alphabetize them! We
    can do better than this. We will organize our properties by style concern.

    View Slide

  79. Property Soup Le average sass stylesheet.
    Alphabetized
    Saturday, June 30, 12
    How should we organize our style properties? Alphabetize them! We
    can do better than this. We will organize our properties by style concern.

    View Slide

  80. Typography The non-color aspects of text.
    Saturday, June 30, 12
    Note how the typography and foreground are mixed up?

    View Slide

  81. Typography Typographic properties: font-xxx, line-
    height, bullets, text-xxx, margin
    Saturday, June 30, 12
    Explain the placeholder selector

    View Slide

  82. Container Not all paddings are from the same
    concern.
    Saturday, June 30, 12

    View Slide

  83. Container border, box shadow, padding
    Saturday, June 30, 12

    View Slide

  84. Background Background - this one is easy :)
    Saturday, June 30, 12

    View Slide

  85. Foreground border-color, color, shadow-color
    Saturday, June 30, 12
    you can’t declare text shadow color explicitly, so we have to put all text shadows in the
    foreground, otherwise the shadow details would be in the typography.

    View Slide

  86. Spacers margin & padding on non-typographic
    elements
    Saturday, June 30, 12

    View Slide

  87. An Object Description
    In Sass, we describe objects using words
    and high-level concepts,
    not style primitives.
    Saturday, June 30, 12
    Isn’t this simpler to understand if you’re reading the code?
    We read code more often than we write it. Be nice to your future self.

    View Slide

  88. An Object Description
    In Sass, we describe objects using words
    and high-level concepts,
    not style primitives.
    Saturday, June 30, 12
    Isn’t this simpler to understand if you’re reading the code?
    We read code more often than we write it. Be nice to your future self.

    View Slide

  89. An Object Description Our object description is longer now.
    Saturday, June 30, 12

    View Slide

  90. An Object Description Our object description is longer now.
    Not Re-Usable
    Re-Usable
    Saturday, June 30, 12

    View Slide

  91. A Sad Reality If you use @extend like this, your
    stylesheets will be huge.
    Saturday, June 30, 12
    So unless you need the flexibility that semantic markup brings for shared content, etc

    View Slide

  92. A Sad Reality Classitis provides a better user
    experience.
    Saturday, June 30, 12

    View Slide

  93. A Sad Reality Classitis provides a better user
    experience.
    Saturday, June 30, 12

    View Slide

  94. This is a GOOD Start
    Saturday, June 30, 12

    View Slide

  95. Progression of a Design
    Prototype
    Variations
    Multiple Uses
    Domain Concepts
    Presentational Concepts
    Concept
    App
    Styles
    Foundation
    Classes
    Mixin
    Library
    Saturday, June 30, 12
    This is a generalization, not a rule. Sometimes you skip a step, some concepts never appear
    in the foundation.

    View Slide

  96. Progression of a Design
    Prototype
    Variations
    Multiple Uses
    Domain Concepts
    Presentational Concepts
    Concept
    App
    Styles
    Foundation
    Classes
    Mixin
    Library
    Saturday, June 30, 12
    This is a generalization, not a rule. Sometimes you skip a step, some concepts never appear
    in the foundation.

    View Slide

  97. Library: ‣No output.
    ‣Mostly presentational in
    nature.
    Foundation: ‣Core, Shared Styles.
    ‣Maps Presentation to
    Domain.
    Application: ‣Features.
    ‣One-off Pages.
    ‣Experimental styles.
    ‣Server traffic patterns
    Saturday, June 30, 12

    View Slide

  98. Library: ‣No output.
    ‣Mostly presentational in
    nature.
    Foundation: ‣Core, Shared Styles.
    ‣Maps Presentation to
    Domain.
    Application: ‣Features.
    ‣One-off Pages.
    ‣Experimental styles.
    ‣Server traffic patterns
    Saturday, June 30, 12

    View Slide

  99. Library: ‣No output.
    ‣Mostly presentational in
    nature.
    Foundation: ‣Core, Shared Styles.
    ‣Maps Presentation to
    Domain.
    Application: ‣Features.
    ‣One-off Pages.
    ‣Experimental styles.
    ‣Server traffic patterns
    Saturday, June 30, 12

    View Slide

  100. Design
    Design
    Saturday, June 30, 12

    View Slide

  101. Saturday, June 30, 12

    View Slide

  102. Saturday, June 30, 12

    View Slide

  103. Interactions are essential
    design elements
    Saturday, June 30, 12

    View Slide

  104. Design Process || Dev Process
    Saturday, June 30, 12
    Do this and suddenly your design process and development process start to look alike.
    Hell, if you think that way, suddenly you start being able to design IN CODE.
    (I don’t think that way)

    View Slide

  105. Don’t worry, we’re
    almost done.
    Saturday, June 30, 12

    View Slide

  106. Benefits
    Everything has a place
    http://www.ultracraft.com/system/accessories/0000/0425/Drawer-Organizer-Metal_full.„g
    Saturday, June 30, 12

    View Slide

  107. Benefits
    File Size
    3.5 MB
    1.2 MB
    Saturday, June 30, 12
    Better factorization => less duplication. 2/3 reduction of total site-wide styles.

    View Slide

  108. Benefits
    Efficient communication
    Saturday, June 30, 12
    More efficient team thru better communication thanks to new vocabulary. completely
    Describing a page design can be done in ~15 minutes.

    View Slide

  109. Benefits
    Low Coupling
    Saturday, June 30, 12
    a clean separation in responsibilities, means changes breaks things less often in unexpected
    ways

    View Slide

  110. Benefits
    Built to last
    http://www.flickr.com/photos/wilhelmja/4233621517/
    Saturday, June 30, 12
    Ok. Pyramids are probably a bit of an exaggeration.
    These styles will be used and evolved for several years -- an eternity on the internet.

    View Slide

  111. Downsides
    ‣Learning curve
    ‣Harder to debug
    ‣Classitis
    ‣A lot of work
    Saturday, June 30, 12
    1-2 days of training to become capable. 3-4 weeks to be competent.
    It will take > 1 month for an experienced team to build a comprehensive styleguide.
    These styles will be used by a team. For the love of god, don't do
    this for your blog or a marketing/promotional site.

    View Slide

  112. Questions?
    Saturday, June 30, 12

    View Slide

  113. We like you.
    @shodoshan
    @chriseppstein
    Saturday, June 30, 12

    View Slide