The Cascade, Grids, Headings, and Selectors from an OOCSS Perspective, Ajax Experience 2009

22,717 views

Published on

The cascade is a poker game, but we've been playing our cards all wrong. Here Nicole suggests we stop trying to play to win to prevent code bloat, and simplify the cascade, using the order of the rulesets to allow overrides.

Published in: Technology
4 Comments
114 Likes
Statistics
Notes
No Downloads
Views
Total views
22,717
On SlideShare
0
From Embeds
0
Number of Embeds
3,891
Actions
Shares
0
Downloads
0
Comments
4
Likes
114
Embeds 0
No embeds

No notes for slide
  • Who am I?

    I am a front-end architecture consultant, working on w3c beta, facebook. My focus is building building scalable CSS. That might mean millions of visitors, thousands of pages, or any site like a blog where content creation goes on long after the look and feel has stabilized.

    Even Faster Websites, Layers Magazine, Smush it, Yslow.
  • Speaking the same language... avoid lingo, focus on what matters to design
  • Which of these will be applied in case of conflict?

    No idea, the order of the classes makes no difference.
  • The color will be blue, no problem to declare things multiple times.

    The last property value pair will win
  • Blue is ignored because the browser doesn’t understand the british spelling. Red will be applied.
  • Foo will be blue, you can define the same thing as many times as you like, the last definition will win. Much like variables.
  • If the same values are declared in both stylesheets, moreStyles.css will win because it comes after styles.
  • The paragraph will be red. IDs win over classes.
  • Inline styles win over external stylesheets and styles in the head
  • Important wins over everything, including inline styles
  • Certain properties are passed to child nodes. If you set a font size for example, child nodes will have the same size font unless they have a more specific rule applied.
  • If you apply two classes to an element, it will have the property value pairs of both. The cascade resolves conflicts. This allows you to aggregate more abstract classes with more specific, so you don’t repeat code.
  • Flawed implementations,
  • Perfectly accessible or high performance website, and then the first newbie to touch it, ruins it. Our code should be robust enough that newbies can contribute while maintaining the standards we’ve set.
  • couple years coding in the basement by yourself before you are remotely useful.
    Profession needs to accommodate entry level, mid level, and architect level developers.
    Frankly, I’m tired of writing rounded corner boxes. I’ve done it 1000 times already. What I want is a system that allows newbies to do that part so I can focus on the architect level challenges.
  • And for good reason. Currently there is no consistency or predictability.
  • New (different) html pages should be able to be built without modifying the CSS.
  • CSS classes - some are like classes, others like properties, and some are objects
    Its about taking programming best practices and applying them to writing CSS.
  • Encourage reuse
  • If we build new HTML pages from a component library, new pages won’t require new css.
    So what goes into a component library. First up, content objects.
  • Anything else that should be consistent site-wide.
  • Consistency & Semantics
  • You might be asking “what are location dependent styles?”, lets look at a programming parallel.
  • Designing site-wide legos first, then pages can help.

    (better for flexible section) YDN homepage module, trying to use it on a 2 column layout
  • Not because you can't do it, anyone at this conf can position something to the left and something else to the right.

    Demo template and grids.
  • .mod{defines what it means to be a module}
    skins become really simple
  • .mod{defines what it means to be a module}
    skins become really simple
  • .mod{defines what it means to be a module}
    skins become really simple
  • .mod{defines what it means to be a module}
    skins become really simple
  • avoid the specificity game
  • avoid the specificity game
  • Need hacks for browsers other than IE5.5, 6, 7? You are doing something wrong.
  • Need hacks for browsers other than IE5.5, 6, 7? You are doing something wrong.
  • YUI contributor
    Work for Yahoo Home Page
    CSS buildr contributor
  • YUI contributor
    Work for Yahoo Home Page
    CSS buildr contributor
  • YUI contributor
    Work for Yahoo Home Page
    CSS buildr contributor
  • I was recently given the task of creating this module
  • The challenges: Cross browser, limited amount of time, high quality markup, accessible and of course only with css.
  • The challenges: Cross browser, limited amount of time, high quality markup, accessible and of course only with css.
  • The challenges: Cross browser, limited amount of time, high quality markup, accessible and of course only with css.
  • The Cascade, Grids, Headings, and Selectors from an OOCSS Perspective, Ajax Experience 2009

    1. 1. OBJECT-ORIENTED CSS scale to millions of users or thousands of pages
    2. 2. NICOLE SULLIVAN “stubbornella” on the web
    3. 3. SLIDES http://www.slideshare.net/stubbornella
    4. 4. THE STATE OF CSS
    5. 5. THE “C” IN CSS understanding the cascade
    6. 6. BROWSER DEFAULT STYLES ❖ Browsers have internal default stylesheets ❖ They are all different ❖ Use reset.css from YUI to level the playing field
    7. 7. CLASS ORDER <p class=”message error”>Borken!</p> The order of the classes makes no difference.
    8. 8. ORDER OF THE PROPERTY VALUE PAIRS .foo{color: red; color: blue;}
    9. 9. BROWSER IGNORES BITS IT DOESN’T UNDERSTAND .foo{color: red; colour: blue;}
    10. 10. ORDER OF THE RULESETS .foo{color: red;} .foo{color: blue;}
    11. 11. ORDER OF THE STYLESHEETS <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http:// www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <link rel="stylesheet" type="text/css" href="styles.css" /> <link rel="stylesheet" type="text/css" href="moreStyles.css" /> </head> <body> <p>My page</p> </body> </html>
    12. 12. SPECIFICITY? Sort of like a game of poker
    13. 13. FROM THE SPEC: ❖ Count 1 if the declaration is from is a 'style' attribute rather than a rule with a selector, 0 otherwise (= a) (In HTML, values of an element's "style" attribute are style sheet rules. These rules have no selectors, so a=1, b=0, c=0, and d=0.) ❖ Count the number of ID attributes in the selector (= b) ❖ Count the number of other attributes and pseudo-classes in the selector (= c) ❖ Count the number of element names and pseudo-elements in the selector (= d)
    14. 14. IT GOES ON... ❖ The specificity is based only on the form of the selector. In particular, a selector of the form "[id=p33]" is counted as an attribute selector (a=0, b=0, c=1, d=0), even if the id attribute is defined as an "ID" in the source document's DTD. ❖ Concatenating the four numbers a-b-c-d (in a number system with a large base) gives the specificity.
    15. 15. ROUGHLY SPEAKING... We need to calculate specificity faster...
    16. 16. ID AND CLASS #nav p{color: red } .nav p{color: blue }
    17. 17. INLINE STYLES <p style=”color: green;”>My page</p>
    18. 18. !IMPORTANT p{color: red !important} <p style=”color: green;”>My page</p>
    19. 19. CSS INHERITANCE body{font-size: 18px;} <body> <p>This text is 18px.</p> </body> http://www.w3.org/TR/CSS2/propidx.html
    20. 20. AGGREGATION OF RULES <p class=”message error”>Boo</p> <p class=”message hint”>Boo</p> <p class=”message help”>Boo</p>
    21. 21. POWERFUL misunderstanding of CSS has led to a mess...
    22. 22. CODE IS TOO FRAGILE. Even the cleanest code gets ruined by the first non-expert to touch it.
    23. 23. REQUIRE EXPERT ABILITY JUST TO GET STARTED. this is not a sign of maturity.
    24. 24. CODE RE-USE IS ALMOST NONEXISTENT people don’t trust other developers’ code.
    25. 25. FILE SIZE JUST KEEPS GETTING BIGGER As the site evolves we continuously modify the CSS.
    26. 26. WHAT IS THE MOST IMPORTANT MISTAKE TALENTED CODERS ARE MAKING? Writing really clever modules.
    27. 27. THE SIZE OF THEIR CSS WILL INCREASE in a 1:1 relationship with the number of blocks, pages, and complexity of content.
    28. 28. WHAT IS OBJECT-ORIENTED CSS? A philosophy? A framework? A tool?
    29. 29. MORE LIKE AN EVOLUTION OF THE LANGUAGE it makes CSS more powerful
    30. 30. HOW IS IT DIFFERENT? ul{...} ul li{...} ul li a{...}
    31. 31. HOW IS IT DIFFERENT? ul{...} ul li{...} ul li a{...} Until now, we focused all our effort here
    32. 32. HOW IS IT DIFFERENT? ul{...} ul li{...} ul li a{...} But, the architecture lives here
    33. 33. TERMINOLOGY CAN BE CONFUSING so forget about a 1:1 mapping with either CSS or OOP
    34. 34. ALL OF THE CODE IS OPEN SOURCE: ON GITHUB http://wiki.github.com/stubbornella/oocss/
    35. 35. selector heading module grid
    36. 36. selector heading template grid
    37. 37. HEADINGS reusable Lego
    38. 38. Heading Level 1 Heading Level 2 HEADINGS Heading Level 3 Getting the look and feel you want with the semantics you Heading Level 4 need. Heading Level 5 Heading Level 6
    39. 39. REUSING ELEMENTS MAKES THEM performance “freebies”
    40. 40. COMPONENTS ARE LIKE LEGO Mix and match to create diverse and interesting pages.
    41. 41. AVOID DUPLICATION Wasting performance resources on components that can’t add value.
    42. 42. NEARLY IDENTICAL MODULES Headings 3 and 5 are too similar.
    43. 43. Rule of thumb: If two modules look too similar to include on the same page, they are too similar to include together in a site, choose one!
    44. 44. AVOID LOCATION- DEPENDENT STYLES Sandboxing is better than spaghetti, but leads to performance problems
    45. 45. AVOID WHAT?
    46. 46. FUNCTION AREA()
    47. 47. FUNCTION AREA()
    48. 48. FUNCTION AREA()
    49. 49. EVERY NOW AND THEN...
    50. 50. RETURNED DIAMETER
    51. 51. BROKEN.
    52. 52. IN CSS WE DO THIS ALL THE TIME
    53. 53. BROKEN.
    54. 54. A Heading should not become a Heading in another part of the page.
    55. 55. AVOID EXAMPLE #weatherModule h3{color:red;} #tabs h3{color:blue} ❖ Global color undefined for h3, so it will be ‣ unstyled in new modules, ‣ developers forced to write more CSS for the same style
    56. 56. AVOID EXAMPLE h3{color:black;} #weatherModule h3{color:red;} #tabs h3{color:blue} ❖ Global color defined (better!) ❖ Weather and tabs override default h3 ‣ three styles for h3 cannot co-exist in the same module ‣ default style cannot be used in weather and tabs without costly overrides ❖ Weather and tabs h3 can never be used outside of those modules
    57. 57. CONSISTENCY Writing more rules to overwrite the crazy rules from before. e.g. Heading should behave predictably in any module.
    58. 58. TRY THIS INSTEAD h1, .h1{...} h2, .h2{...} h3, .h3{...} h4, .h4{...} h5, .h5{...} h6, .h6{...} ❖ Global values defined ❖ Semantics respected (while allowing visual flexibility) <h3 class=”h6”>Heading</h3>
    59. 59. NEED MORE THAN 6 HEADINGS? Really? Any duplicates? Any too similar?
    60. 60. STILL NEED MORE HEADINGS? .category{...} .section{...} .product{...} .prediction{...} ❖ Extend the heading object via a class on the object itself ❖ Avoid using the cascade to change display of nested objects
    61. 61. selector heading template grid
    62. 62. TEMPLATE & GRIDS Be flexible - extensible height and width
    63. 63. TEMPLATE • 807 bytes • 13 lines of code • easily extended to custom page and column width
    64. 64. GRIDS • 574 bytes • 14 lines of code • Percentage widths adapt to different page sizes • Includes halfs, thirds, fourths, and fifths • No gutters • Infinite nesting and stacking
    65. 65. Grids control the width
    66. 66. Content controls height
    67. 67. FIXED DIMENSIONS limit the ways in which a module can be reused
    68. 68. selector heading template grid
    69. 69. TAMING SELECTORS sanity for our stylesheets
    70. 70. SIZE OF THE CSS FILE AND IMPLIED HTTP REQUESTS are the biggest factor for CSS performance
    71. 71. REFLOWS AND RENDERING TIME are (much!) less important
    72. 72. DUPLICATION IS WORSE THAN STALE RULES because we have tools to deal with the latter
    73. 73. DEFINE DEFAULT VALUES Don’t repeat this code in every object
    74. 74. #weatherModule h3{color:red;} #tabs h3{color:blue} DEFINE DEFAULT VALUES Don’t repeat this code in every object
    75. 75. X #weatherModule h3{color:red;} #tabs h3{color:blue} DEFINE DEFAULT VALUES Don’t repeat this code in every object
    76. 76. X #weatherModule h3{color:red;} #tabs h3{color:blue} DEFINE DEFAULT VALUES Don’t repeat this code in every object h1, .h1{...} h2, .h2{...} h3, .h3{...} h4, .h4{...} h5, .h5{...} h6, .h6{...}
    77. 77. DEFINE STRUCTURE IN A SEPARATE CLASS Don’t repeat this code in every object block inner hd bd ft
    78. 78. div.error{...} STYLE CLASSES rather than elements
    79. 79. X div.error{...} STYLE CLASSES rather than elements .error{ most of the code goes here }
    80. 80. X div.error{...} STYLE CLASSES rather than elements .error{ most of the code goes here } div.error{ } p.error{ exceptions only } em.error{ }
    81. 81. div{...} ul{...} p{..} AVOID STYLING ELEMENTS unless defining defaults
    82. 82. div{...} X ul{...} p{..} AVOID STYLING ELEMENTS unless defining defaults .error{...} .section{...} .products{...}
    83. 83. html body .myModule div .hd{...} .myModule2 .hd {...} GIVE RULES THE SAME STRENGTH Use cascade order to overwrite previous rules
    84. 84. X html body .myModule div .hd{...} .myModule2 .hd {...} GIVE RULES THE SAME STRENGTH Use cascade order to overwrite previous rules .myModule .hd{...} .myModule2 .hd{...}
    85. 85. .mod .hd{...} .ie .mod .hd{...} .weatherMod .hd {...} USE HACKS SPARINGLY And don’t let them change your specificity
    86. 86. .mod .hd{...} X .ie .mod .hd{...} .weatherMod .hd {...} USE HACKS SPARINGLY And don’t let them change your specificity .mod .hd{color: red; _zoom:1;} .weatherMod .hd{...}
    87. 87. .sidebar ul{...} .header ul {...} AVOID SPECIFYING LOCATION Apply classes to the object you wish to change
    88. 88. X .sidebar ul{...} .header ul {...} AVOID SPECIFYING LOCATION Apply classes to the object you wish to change .mainNav{...} .subNav {...}
    89. 89. AVOID OVERLY SPECIFIC CLASSES they’re all semantic, but limiting
    90. 90. AVOID OVERLY SPECIFIC CLASSES they’re all semantic, but limiting .vehicle{...} .motorcycle{...} .ducati{...} .ducatiMonster620{...} .nicolesDucatiMonster620{...}
    91. 91. AVOID OVERLY SPECIFIC CLASSES they’re all semantic, but limiting .vehicle{...} .motorcycle{...} .ducati{...} X .ducatiMonster620{...} .nicolesDucatiMonster620{...}
    92. 92. #myUniqueIdentifier{...} #myUniqueIdentifier2{...} AVOID SINGLETONS ids can only be used once in any given page Source: Chris Griego
    93. 93. X #myUniqueIdentifier{...} #myUniqueIdentifier2{...} AVOID SINGLETONS ids can only be used once in any given page Source: Chris Griego
    94. 94. Media Subheading Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. USE MIXINS to avoid repeating code Media Extended Subheading Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
    95. 95. .inner{...} .weatherMod .inner{...} .tr{...} .weatherMod .tr{...} .bl{...} .weatherMod .bl{...} ENCAPSULATION don’t access sub-nodes of an object directly inner
    96. 96. .inner{...} X .weatherMod .inner{...} .tr{...} .weatherMod .tr{...} .bl{...} .weatherMod .bl{...} ENCAPSULATION don’t access sub-nodes of an object directly inner
    97. 97. OOCSS: A REAL LIFE EXAMPLE Gonzalo Cordero Front-End Engineer @Yahoo! inc.
    98. 98. Who
    99. 99. Who
    100. 100. Who
    101. 101. Who
    102. 102. TO SHARE
    103. 103. TO SHARE
    104. 104. TO SHARE
    105. 105. DESIGN CONSIDERATIONS
    106. 106. DESIGN CONSIDERATIONS ❖ Cross browser compatible
    107. 107. DESIGN CONSIDERATIONS ❖ Cross browser compatible ❖ Multi-language support
    108. 108. DESIGN CONSIDERATIONS ❖ Cross browser compatible ❖ Multi-language support ❖ Accessible
    109. 109. DESIGN CONSIDERATIONS ❖ Cross browser compatible ❖ Multi-language support ❖ Accessible ❖ Aggressive deadline to complete both layout and functionality
    110. 110. The Puzzle
    111. 111. The Puzzle
    112. 112. The Puzzle
    113. 113. The Puzzle
    114. 114. RESULT
    115. 115. WEB COMPROMISES
    116. 116. WEB COMPROMISES ❖ Why does the “easy” turn so complicated?
    117. 117. WEB COMPROMISES ❖ Why does the “easy” turn so complicated? ❖ Why do we need to compromise?
    118. 118. WEB COMPROMISES ❖ Why does the “easy” turn so complicated? ❖ Why do we need to compromise? ❖ Why can’t we rely on a set of solid rules and structures? Like other platforms do?
    119. 119. OOCSS SAVES THE DAY
    120. 120. OOCSS SAVES THE DAY ❖ Single simple markup structure
    121. 121. OOCSS SAVES THE DAY ❖ Single simple markup structure ❖ Cross browser support (even IE 5.5!)
    122. 122. OOCSS SAVES THE DAY ❖ Single simple markup structure ❖ Cross browser support (even IE 5.5!) ❖ Very minimum CSS
    123. 123. OOCSS SAVES THE DAY ❖ Single simple markup structure ❖ Cross browser support (even IE 5.5!) ❖ Very minimum CSS ❖ Scalable, easy to apply to multiple designs
    124. 124. OCSS SAVES THE DAY
    125. 125. OCSS SAVES THE DAY
    126. 126. OCSS SAVES THE DAY
    127. 127. OCSS SAVES THE DAY
    128. 128. OCSS SAVES THE DAY
    129. 129. AFTER OOCSS
    130. 130. TO CONTRIBUTE
    131. 131. Why can’t the web have great tools to build and design interfaces?
    132. 132. What’s stopping us?
    133. 133. CSSBUILDR ❖ If we said we could reuse the same structure over and over again, what’s stopping us from doing so? ❖ Different modules and page grids can be easily built. ❖ Plug and Play, Mix and Match.
    134. 134. CSSBUILDR: TECH SPECS ❖ Create and modify module contours, backgrounds, font- colors, etc. ❖ In two to three clicks you get a plug-and-play ready module that works cross browser. ❖ Built on top YUI.
    135. 135. THANK YOU DEMO TIME ❖ ygonzalocordero@me.com ❖ Twitter: goonieiam

    ×