Stop Supporting Old Browsers!

As of today I’m making a symbolic stand.  This week I’ve stopped supporting legacy web browsers in my code.  No more shims, polyfills or hacks to make my HTML or CSS code run.

Why am I taking this stand?  In the name of PROGRESS.

You see in the old days roads were travelled by foot, carriage or horseback.   Now we use cars.  We call this progress.

The transition from vinyl to cassette to CD to MP3 is another example of progress.  

In a couple of months we’re having analogue TV closed down.  We’ll be required to buy a new TV or install a set top box in order to decipher a digital signal.  Progress again.

In the name of progress I no longer support old browsers.  Any of them.  I make no apologies for this.  Websites I create may not display perfectly or at all in your old browser.  This is not my fault or my problem – this situation entirely YOUR fault and YOU are to blame.

By refusing to update your old browser you’re lagging behind.  Dragging the chain.  Watching VHS videotapes.  Playing records on your gramophone.  What can you do?  You can update your browser to the most current version, in any flavor of OS for free – so what are you waiting for?  

If IE7 doesn’t display a page I created or does something strange with links don’t whine and moan to me – just update the thing, or be left behind.  Either solution is fine by me.

My tipping point in taking this stand is quite simple.  Browsers that do not support the HTML5 semantic elements get left behind.  In CSS I use Media Queries to transform the layout (responsive design) depending on the width of the viewport, so support for Media Queries is also critical.

Here’s a guide to which browsers do the business. At present 83.84%* of browsers support the HTML5 semantic elements. 



Here's how the support for CSS Media Queries stacks up.  The good news is that media queries are almost exactly as well supported as the HTML5 elements with 83.72%* coverage.



If your browser doesn’t cut the mustard – it’s time to replace it.  Did I mention it’s free to do so?  Good.

* source www.caniuse.com

Classless CSS

I found a very thought provoking article by Heydon Pickering on the Smashing Magazine website Classes? Where We’re Going, We Don’t Need Classes!. In the article, Heydon makes a strong case that the use of classes is

"as antiquated and inappropriate for styling as the table is for layout"

Heydon argues that tying semantic HTML to CSS classes is unnecessary and actually harmful to the interoperability of the HTML. Heydon naturally dislikes Object Orientated CSS as a further impediment to the purity (and therefore transportability) of the HTML. In his thinking, the HTML should be separated from the CSS, not tied to it via classes. To put it into his own words...

"An element that insists on looking the same wherever it appears is a bit like a Briton who travels from country to country refusing to speak the native language and burping the English national anthem. It’s aggressive and inappropriate."

Aggressive and inappropriate. I love that.

Q:

So what is to be done to introduce classless CSS?

A:

Paradigmatic styling.

Paradigmatic styling is using the right element for the job and styling it appropriately. We have a toolbox stuffed with tools with which we can apply styling to individual elements without resorting to classes. Appropriate use of microformats and CSS selectors make the use of classes highly suspect.

Conclusion:

Like I started out saying - this is a thought provoking article. I'm not sure I'm willing to go cold-turkey and forgo using classes in my CSS right away, but you can bet that I'm going to severely question my use of classes from now on.

Oh, and the comments posted after the article make fascinating reading!

HTML5 & CSS document encoding

I always knew it was right and proper to declare the type of encoding in a HTML document. Specifying the encoding type means that characters in the content are correctly interpreted and displayed.

HTML5 has a brand new attribute, charset which makes the declaration cleaner and simpler than the old method.  In the past (HTML 4.01) we would have written:

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">

Now in HTML5 we write:

    <meta charset="UTF-8">

How easy is that? Additional stuff you might want to know:

1. UTF-8 - Specifies character encoding for Unicode.  This should be your default encoding type unless you have some specific need to have another encoding type e.g. to specify another character set.
2.  Metadata is used to provide information about the HTML document.  It is not displayed on the page, but is able to be interpreted or parsed by browsers or search engines.
3. <meta> tags always go inside the <head> element.  The encoding needs to be within the first 1024 bytes of the document, so place it immediately inside the <head> tag.
4. An alternative to the meta charset element is to use a Unicode Byte Order Mark (BOM) character at the start of the file.  I do not recommend this system over the <meta> method.

What you didn't know....

You should also specify the encoding type in your external CSS documents!  When I read this I had a really? moment. I hadn't known that.  Now I do - and so do you.

Like the HTML5 spec above, the encoding for CSS documents should appear at the very start of the document.  Here's how to write the encoding:

    @charset "UTF-8";

This declaration tells the browser to read the following CSS file as UTF-8.  Easy.

Proportional Media Queries - ems!

Found this excellent blog post by Lyza Gardner (post date March 28, 2012).

The EMs have it: Proportional Media Queries FTW! 

In this article Lyza expounds the virtue of using not pixels in media queries, but ems.  I'd always used pixels and though I was pretty cool doing it.  

So what's the difference?  Pixels have a fixed size.  Ems do not - they are based on the current font size.  If the viewer increases the font size a pixel based media query is likely to fail.  The em unit media query is still going to work.

Fortunately it is not hard to change the base unit of your media queries.  Here's how:

1. We assume that the base font size is 16px - because it is a pretty good guess as most browsers use this as the default font size.

2. We know that 16px = a font size of 100% = 1em.  With me so far?

3. Take all those pixels based media queries and divide them by 16 and substitute the em unit.  Bingo.

e.g.

@media only screen and (max-width: 1040px)  {
}

@media only screen and (max-width: 960px)  {
}

Becomes
 

@media only screen and (max-width: 65em)  {
}

@media only screen and (max-width: 60em)  {
} 

Show and hide, simply, using CSS

I was recently laying out a new HTML5 website.  I needed a list in a sidebar to act like a vertical menu, with sub-items hidden until the parent item was hovered over.

In previous situations I would have used javascript to show and hide the items using a unique element id.  This method is a bit passe these days, so here is my CSS solution.

We'll start with a handful of nested lists

<!DOCTYPE html>   <!-- HTML5 document declaration -->
<html lang="en">
   
    <head>      
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <title>ShowHideDemo</title>
        

      <style type="text/css">
        

       </style>

    </head>

    <body>
        <ul>
            <li>Fruit
                <ul>
                    <li>Apple</li>
                    <li>Orange</li>
                    <li>Banana</li>
                </ul>
            </li>
            <li>Animals
                <ul>
                    <li>Goat</li>
                    <li>Sheep</li>
                    <li>Pig</li>
                </ul>
            </li>
            <li>Paint.NET   
                <ul>
                    <li>Plugins</li>
                    <li>Layers</li>
                    <li>Forum</li>
                </ul>
            </li>
        </ul>
   
    </body>   
</html>

We want to hide the sub-items by default.  We can achieve this with a tiny little bit of CSS.  Place the following snippet in between the style tags in the above document.

                li ul {display: none }

This tells us that any Unordered List (ul) that is a child of a List Item (li) should not be displayed.  Easy.

Now we want to display the hidden items when the parent item receives the focus (hover).  Add this line of CSS below the last one, keeping it inside the style tags.

                   li:hover ul {display: block}

This states that any Unordered List (ul) that is a child of a List Item (li) that has the focus (hover) should be displayed (as a block).

That's it!   Mousing over the parent item, displays the sub-menu.  Just what I wanted.  Of course there is still a little styling to be done, but this doesn't change the core code of the effect.

<!DOCTYPE html>   <!-- HTML5 document declaration -->
<html lang="en">
  
    <head>     
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <title>ShowHideDemo</title>
        <style type="text/css">
                li ul {

                      display: none;  

                      width: 200px;   

                        -webkit-border-top-right-radius: 8px;
                       -webkit-border-bottom-left-radius: 12px;
                      -moz-border-radius-topright: 12px;
                      -moz-border-radius-bottomleft: 12px;
                      border-top-right-radius: 12px;
                      border-bottom-left-radius: 12px;
                     -webkit-box-shadow: 2px 2px rgba(0,0,0,.6);
                     -moz-box-shadow: 2px 2px 2px rgba(0,0,0,.6);
                     box-shadow: 2px 2px 2px rgba(0,0,0,.6);
                     background: #DFFF8E; 

}
                li:hover ul {

                  display: block;
                  position: relative;
                 margin-bottom: 8px;
                 -webkit-animation: fadeIn 1s;
                 -moz-animation: fadeIn 1s;
                -ms-animation: fadeIn 1s;}
  
    @-webkit-keyframes fadeIn {
    from { opacity: 0; }
      to { opacity: 1; }
}

@-moz-keyframes fadeIn {
    from { opacity: 0; }
      to { opacity: 1; }
}

@-ms-keyframes fadeIn {
    from { opacity: 0; }
      to { opacity: 1; }
}
        </style>
    </head>

    <body>
  
        <ul>
            <li>Fruit
                <ul>
                    <li>Apple</li>
                    <li>Orange</li>
                    <li>Banana</li>
                </ul>
            </li>
            <li>Animals
                <ul>
                    <li>Goat</li>
                    <li>Sheep</li>
                    <li>Pig</li>
                </ul>
            </li>
            <li>Paint.NET  
                <ul>
                    <li>Plugins</li>
                    <li>Layers</li>
                    <li>Forum</li>
                </ul>
            </li>
        </ul>
  
    </body>
     
</html>

Here we're using some color, width, rounded corners and shadowing to style the sub-menu.  All using CSS.  The final touch is a nice little transition which fades the sub-menu in  using the opacity value.

So why didn't I use display:block and display:none instead of the visibility: hidden statement? 

Simple: the visibility:hidden statement does not display the item, but it does display the same amount of whitespace that the content would have taken if it were visible.  This would have spaced out my parent menu items rather than keeping them together.

Note:  I'd always use separate style sheets.  The code shown above includes the styling to make copying and pasting easier.