WISH
                    CSS


                                 LIST
 WISH
wish wish wish wish wish wish wish
http://laughingsquid.com/css-is-awesome/
GOALS

❖   CSS is already awesome, but it can be even better!



❖   Make CSS a better declarative language
❖   Abstract repeating patterns in the code
❖   Do not make CSS a programming language
USABILITY
❖   CSS is already awesome, but it can be easier to author!



❖   Make CSS easier for newbies
❖   Improve performance by dramatically reducing the amount of
    code
❖   Make the language more robust with more useful browser
    warnings
VARIABLES
                                       make global changes easier




Reference: CSS Variables,Glazman and Hyatt
DEFINE VARIABLES
                                variable group


  @variables hex {
  
 facebookBlue: #3b5998;
  
 highlight: #FF9933;
  }
                   variable name


@variables <var group name> { <var name>: <value> }
CALL VARIABLES

  h2, h4, h6 {
  
 /* call var */
  
 color: hex.facebookBlue;
  }
                              variable name
variable group


      <var group name>.<var name>
PROTOTYPES
organize code into logical abstractions
EXAMPLE PROTOTYPE
                 mod
               block
                  inner
                          hd




                          bd




                          ft


Example based on the standard module format from YUI
DEFINE PROTOTYPES
                             prototype


  @prototype .mod {
  
 margin: 10px;
  
  }




@prototype <class name> { property: value; }
DEFINE PROTOTYPES
                             prototype


  @prototype .mod {
  
 margin: 10px;
  
 children: b, .inner;
  }
              allowed nested children


@prototype <class name> { property: value; }
MODIFY PROTOTYPES
                  sub-node is a property
                  of the prototype
.mod .inner {

 position: relative;
}




Inner becomes a property node of .mod
EXTEND PROTOTYPES
                           prototype

.weatherMod {

 extends: .mod;
}
            extends key



weather now has all the properties of mod,
          including sub-nodes
EXTENDS - UNDER THE
      HOOD

@prototype .mod,
.weatherMod{ ... }
.mod .inner,
.weatherMod .inner { ... }
.weatherMod { ... }



  normal cascade order is respected
PROTOTYPE
          ENCAPSULATION

      .leftCol .inner { /* invalid */
      
 color:red;
      }               sub-node is a property
                      of the prototype mod



inner belongs to mod and leftCol doesn't extend mod the
    ruleset is invalid and should be ignored by the UA
MIXINS
combine small bits of repeating code
DEFINE MIXINS


@mixin .clearfix {

 zoom:1;
}
                           mixin




@mixin <class name> { property: value; }
MODIFY MIXINS
.clearfix:after {

 content: ".";

 display: block;

 height: 0;

 clear: both;

 visibility: hidden;
}


Any selector which references “.clearfix”
          modifies the mixin
INCLUDING MIXINS
                               mixin

.line{

 include: .clearfix;
}
            include key


copies clearfix property value pairs to the
       current location in the code
MIXINS - UNDER THE
        HOOD
                        property value
.line {zoom:1;}         pairs are copied
.line:after {           from clearfix to

 content: ".";         line

 display: block;

 height: 0;

 clear: both;

 visibility: hidden;
}
USE MIXINS FOR SMALL
BITS OF REPEATING CODE
  remove non-semantic classes from the html
         like clearfix or rounded7px
MIXINS ARE NOT
             CASCADED
Property value pairs are invoked as if they were declared at the
                  current location in the code.
PROTOTYPE SUB-NODES
    define the relationship between
   sub-nodes of the same prototype
SHOULD THIS BE POSSIBLE?
does it add enough value to justify the additional complexity?
I FOUND MYSELF WRITING
  COMMENTS LIKE THESE

/*
               margin top =
        bottom height - corner height
*/



Values are predictable and easy to calculate because the
            complexity lives in the abstraction.
SUB-NODES EXAMPLE
.flow .bottom {
  height:4px;
  margin-top:-4px;
  }                             bottom corner
                   margin top =        -
.flow .bl {                     height   height
margin-top:-6px;
}

         example from my open source project,
 corner height is defined as 10px in the .mod prototype
SUB-NODE VALUE
         CALCULATION
.mod .bottom {
  height: 5px;        calculation of margin based
}                     on defined values
.mod .bl {
  height: 10px;
  margin-top:
       .bl.height - .bottom.height;
}

       <subnode node class>.<css property>
SUB-NODES - UNDER THE
            HOOD
❖   Use this syntax to define the relationship between the nodes
    of an object



❖   Can only access nodes of the current object
❖   Can only access defined values (not computed style)
❖   Not intended to substitute for good flexible layout!
OUTCOMES
  if the method and syntax are right,
the code should meet the stated goals
RESULTS ARE
      PROMISING
       In the parent node, if we
      express these relationships,
      the predictability of simple
         skins can be improved



Reference: Gonzalo Cordero, Jenny Han Donnelly, Chris Klaiber
EASY PEASY
        The complex bit is harder, but
  the implementation of skins is dead simple.


.gonzalo {extends: .mod;}
.gonzalo,
.gonzalo .inner,
.gonzalo b {
  background-
  image:url(gonzaloModule.png);
}
EASY PEASY
        The complex bit is harder, but
  the implementation of skins is dead simple.


.gonzalo {extends: .mod;}
.gonzalo,
.gonzalo .inner,
.gonzalo b {
  background-
  image:url(gonzaloModule.png);
}

                             two rules to create
                          this rounded corner box
MUCH LESS CODE
  easier to work with newbies
FLICKR PHOTO CREDITS



❖   Steampunk Gears, Needles, Rods 'n Such by Buz Carter
LET’S KEEP TALKING...
                http://stubbornella.org
            “stubbornella” on the web...
      twitter, dopplr, slideshare, everywhere...


        http://github.com/stubbornella/oocss/
http://groups.google.com/group/object-oriented-css
WISH
                    CSS


                                LIST
WISH
wish wish wish wish wish wish wish

CSS Wish List @JSConf

  • 1.
    WISH CSS LIST WISH wish wish wish wish wish wish wish
  • 2.
  • 3.
    GOALS ❖ CSS is already awesome, but it can be even better! ❖ Make CSS a better declarative language ❖ Abstract repeating patterns in the code ❖ Do not make CSS a programming language
  • 4.
    USABILITY ❖ CSS is already awesome, but it can be easier to author! ❖ Make CSS easier for newbies ❖ Improve performance by dramatically reducing the amount of code ❖ Make the language more robust with more useful browser warnings
  • 5.
    VARIABLES make global changes easier Reference: CSS Variables,Glazman and Hyatt
  • 6.
    DEFINE VARIABLES variable group @variables hex { facebookBlue: #3b5998; highlight: #FF9933; } variable name @variables <var group name> { <var name>: <value> }
  • 7.
    CALL VARIABLES h2, h4, h6 { /* call var */ color: hex.facebookBlue; } variable name variable group <var group name>.<var name>
  • 8.
    PROTOTYPES organize code intological abstractions
  • 9.
    EXAMPLE PROTOTYPE mod block inner hd bd ft Example based on the standard module format from YUI
  • 10.
    DEFINE PROTOTYPES prototype @prototype .mod { margin: 10px; } @prototype <class name> { property: value; }
  • 11.
    DEFINE PROTOTYPES prototype @prototype .mod { margin: 10px; children: b, .inner; } allowed nested children @prototype <class name> { property: value; }
  • 12.
    MODIFY PROTOTYPES sub-node is a property of the prototype .mod .inner { position: relative; } Inner becomes a property node of .mod
  • 13.
    EXTEND PROTOTYPES prototype .weatherMod { extends: .mod; } extends key weather now has all the properties of mod, including sub-nodes
  • 14.
    EXTENDS - UNDERTHE HOOD @prototype .mod, .weatherMod{ ... } .mod .inner, .weatherMod .inner { ... } .weatherMod { ... } normal cascade order is respected
  • 15.
    PROTOTYPE ENCAPSULATION .leftCol .inner { /* invalid */ color:red; } sub-node is a property of the prototype mod inner belongs to mod and leftCol doesn't extend mod the ruleset is invalid and should be ignored by the UA
  • 16.
    MIXINS combine small bitsof repeating code
  • 17.
    DEFINE MIXINS @mixin .clearfix{ zoom:1; } mixin @mixin <class name> { property: value; }
  • 18.
    MODIFY MIXINS .clearfix:after { content: "."; display: block; height: 0; clear: both; visibility: hidden; } Any selector which references “.clearfix” modifies the mixin
  • 19.
    INCLUDING MIXINS mixin .line{ include: .clearfix; } include key copies clearfix property value pairs to the current location in the code
  • 20.
    MIXINS - UNDERTHE HOOD property value .line {zoom:1;} pairs are copied .line:after { from clearfix to content: "."; line display: block; height: 0; clear: both; visibility: hidden; }
  • 21.
    USE MIXINS FORSMALL BITS OF REPEATING CODE remove non-semantic classes from the html like clearfix or rounded7px
  • 22.
    MIXINS ARE NOT CASCADED Property value pairs are invoked as if they were declared at the current location in the code.
  • 23.
    PROTOTYPE SUB-NODES define the relationship between sub-nodes of the same prototype
  • 24.
    SHOULD THIS BEPOSSIBLE? does it add enough value to justify the additional complexity?
  • 25.
    I FOUND MYSELFWRITING COMMENTS LIKE THESE /* margin top = bottom height - corner height */ Values are predictable and easy to calculate because the complexity lives in the abstraction.
  • 26.
    SUB-NODES EXAMPLE .flow .bottom{ height:4px; margin-top:-4px; } bottom corner margin top = - .flow .bl { height height margin-top:-6px; } example from my open source project, corner height is defined as 10px in the .mod prototype
  • 27.
    SUB-NODE VALUE CALCULATION .mod .bottom { height: 5px; calculation of margin based } on defined values .mod .bl { height: 10px; margin-top: .bl.height - .bottom.height; } <subnode node class>.<css property>
  • 28.
    SUB-NODES - UNDERTHE HOOD ❖ Use this syntax to define the relationship between the nodes of an object ❖ Can only access nodes of the current object ❖ Can only access defined values (not computed style) ❖ Not intended to substitute for good flexible layout!
  • 29.
    OUTCOMES ifthe method and syntax are right, the code should meet the stated goals
  • 30.
    RESULTS ARE PROMISING In the parent node, if we express these relationships, the predictability of simple skins can be improved Reference: Gonzalo Cordero, Jenny Han Donnelly, Chris Klaiber
  • 31.
    EASY PEASY The complex bit is harder, but the implementation of skins is dead simple. .gonzalo {extends: .mod;} .gonzalo, .gonzalo .inner, .gonzalo b { background- image:url(gonzaloModule.png); }
  • 32.
    EASY PEASY The complex bit is harder, but the implementation of skins is dead simple. .gonzalo {extends: .mod;} .gonzalo, .gonzalo .inner, .gonzalo b { background- image:url(gonzaloModule.png); } two rules to create this rounded corner box
  • 33.
    MUCH LESS CODE easier to work with newbies
  • 34.
    FLICKR PHOTO CREDITS ❖ Steampunk Gears, Needles, Rods 'n Such by Buz Carter
  • 35.
    LET’S KEEP TALKING... http://stubbornella.org “stubbornella” on the web... twitter, dopplr, slideshare, everywhere... http://github.com/stubbornella/oocss/ http://groups.google.com/group/object-oriented-css
  • 36.
    WISH CSS LIST WISH wish wish wish wish wish wish wish

Editor's Notes

  • #2 Stephen talked yesterday about how the CSS working group seems to focus on special effects over real fundamental changes. Special effects are great, but we need *more*. The language needs better ways to express all the things i&amp;#x2019;ve been talking about.
  • #10 Example, YUI standard module format.
  • #11 Imagine you could define a css class to be an prototype, a repeating pattern of code off which more specific objects could be built.
  • #14 Important because, as we saw before, order matters.
  • #26 Let&amp;#x2019;s look at what the code is doing. Is there another way to arrive at this magic number? To not need to do the calculation by hand in each specific instance of the object?
  • #27 Let&amp;#x2019;s look at what the code is doing. Is there another way to arrive at this magic number? To not need to do the calculation by hand in each specific instance of the object?
  • #28 Let&amp;#x2019;s look at what the code is doing. Is there another way to arrive at this magic number? To not need to do the calculation by hand in each specific instance of the object?
  • #35 Stephen talked yesterday about how the CSS working group seems to focus on special effects over real fundamental changes. Special effects are great, but we need *more*. The language needs better ways to express all the things i&amp;#x2019;ve been talking about.