Anthony Short / Notes & Whims

• 2010-10-19

  WDS 2010 Open Sequence

  I was there when they showed this at the Web Directions South opening keynote. I love what CSS can do now.

• →

  Laptop thief backs up victim's data, mails it to him

  For around a week later, the professor says he received an envelope. Inside was a USB stick…

  No, it held all the data from his laptop. The thief, it appears, took pity and spent perhaps hours making sure that the professor got all of his unbacked-up information back.

  Source: jessedodds

• 2010-09-24

  Using variables in @media queries

  One thing that I’ve discovered recently after playing with a little bit of responsive web design with Sass, is that it would extremely useful to use variables to store the @media query string to help with encapsulation.

  Why?

  The media queries we’re using to modify our layouts are becoming more robust and numerous. We have queries for mobile, tablets, wide-screen, landscape, portrait and of course, standard displays.

  @media screen and (min-width: 1700px)
  {       
      body
      {
          font-size: 1.3em;
      }
  }
  
  @media (max-width:1024px)
  {   
      body
      {
          font-size: 1.1em;       
      }
  
      .article
      {
          width: 35em;
      }
  }
  

  While these are all really just different screen widths, our layout might change significantly at a certain point to accommodate the new screen real estate in a more usable way.

  Preferably we’d only write each of these media query blocks once. But if we’re properly encapsulating our components we don’t want to mix out components into a single media query. That wouldn’t be very DRY now would it?

  Here’s an example component I’m using to let me know which layout is being used (using media queries). It’s positioned at the top of the window, and the content changes based on the current query that is being satisfied:

  #debug
  {
      position:absolute;
      top:0;
      left:0;
      color:#fff;
      content: ' ';
  }
  
  @media screen and (min-width:1025px)
  {
      #debug::after
      {
          content: 'Normal';
      }
  }
  
  @media (max-width:1024px)
  {
      #debug::after
      {
          content: 'Tablet';
      }
  }
  
  @media screen and (min-width: 1700px)
  {
      #debug::after
      {
          content: 'Wide-screen';
      }
  }
  
  /* Normal Styles */
  
  @media screen and (min-width:1025px)
  {
      body
      {
          font-size: 1.2em;       
      }
  
      .article-main
      {
          width: 45em;
      }
  }
  

  And so on. These are points in my design where the layout changes drastically. Whether the layout is fluid or fixed doesn’t particularly matter, as different items might float, un-float, clear etc. to form the new layout.

  What if I decide to change the ‘normal’ or ‘tablet’ width to something else later on? I can either squeeze all of my components into the single query, or write the same query twice.

  I’d like to be able to do this SASS variables:

  #debug
  {
      position:absolute;
      top:0;
      left:0;
      color:#fff;
      content: ' ';
  
      @media $media_screen
      {
          &
          {
              content: 'Normal';
          }
      }
  
      @media $media_tablet
      {
          &
          {
              content: 'Tablet';
          }
      }
  }
  

  Perhaps there’s a better way to implement something like this that I’m not seeing, but I think this could be an elegant solution to help encapsulate @media queries.

• →

  Which CSS structure do you prefer, single-file or multi-file, and why?

  I’ve been thinking a lot lately about the benefits of both, specifically related to the ‘OOCSS’ approach to CSS development and with tools like Sass. This has all been discussed before, but with these new tools for CSS development, I think it’s worth another discussion.

  Single file CSS gives you:

  • The ability to easily see the cascade and related styles
  • See the available styles to avoid duplication and redundancy as more people add to it over time
  • A more easily editable stylesheet. There’s no need to flick between multiple open files and decide which style came first

  The downsides of single-file CSS might be:

  • No re-usable components. (But do we really RE-USE that many CSS components?)
  • The single file becomes unruly over time we hundreds and hundreds of lines
  • Now that we’re being responsive with our designs, the media queries can start to add up and add a butt load of extra styles to our files.

  With the modular nature of multiple files we get:

  • The ability to re-use code across multiple stylesheets, be it different themes, newer versions of the site design, or different sites entirely.
  • We break up our styles into the content, container, structure and style much more clearly.
  • Perhaps it’s easier to find certain styles when you know the structure of the files

  The downsides:

  • Splitting into multiple files often means we duplicate styles and structure. Eg. Trying to get all of your type into the type.css.
  • Added time spent thinking about where styles should go.
  • The total number of files can get very, very large making it semantically valuable, but a nightmare to maintain, as all of the related styles are scattered.

  Your thoughts?

• 2010-09-11

  No, you don't own it

  Regarding software licensing:

  “You agree that you will not redistribute, transmit, assign, sell, broadcast, rent, share, lend, modify, adapt, edit, license or otherwise transfer or use the Digital Content. You are not granted any synchronization, public performance, promotional use, commercial sale, resale, reproduction or distribution rights for the Digital Content.”

  Then what CAN you do with it?