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.

• 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-08-27

  Styling the search input in webkit

  On a recent project I had to create a search input that looked the same across all browsers. I wanted to use the new HTML 5 search input, but in Safari, it styles the input for you:

  

  To make this render as a normal input you only need a couple of rules:

  
  input[type=search]
  {
         -webkit-appearance:textfield;
         -webkit-box-sizing:content-box;
  }
  
  ::-webkit-search-decoration
  {
      display: none;
  }
  

  -webkit-appearance tells the browser to render the search field as it would any other text input field.

  ::-webkit-search-decoration turns off the space that is created on the left of the input where the recent search dropdown normally is.

  

• 2010-08-16

  CSS Form Reset

  Last week Nathan Smith, the creator of 960.gs, put up a template for a form reset. I added the search box styling. It’s turning out to be a really nice starting point for form styling. Although I want to do some testing with box-sizing on form elements as it could solve some cross browser woes.