Anyway, I was thinking about how to do implement it the other day. I haven’t done one of these in a long time and the only other time I did one it involved crafting separate, albeit small, style sheets for the larger text sizes. I didn’t want to go that way again. Basically, I just didn’t want to write new style sheets- even small ones.

What’s a fella to do?

zoom

So, thinking about it a little bit, I seized upon using the non-standard CSS zoom property. Supported in Internet Explorer (zoom:1 is often used for a hasLayout toggle) and Webkit browsers, it would represent a simple (1 line!) CSS solution to this problem. It’s also one that I like better aesthetically as the site looks the same, just bigger. I figure there’s a reason all browsers have moved to this behavior when hitting ctrl+.

The problem was figuring out an equivalent for FireFox and Opera which don’t support zoom

Enter CSS 2D Transform

A little searching and experimenting later I came up with the idea of using CSS Transforms and the scale value to approximate zoom in browsers that lack support.

Let’s see how I did it.

As you go through the following keep in mind this hasn’t actually gone through testing yet so something weird could yet shake out. I just wrote this code yesterday, so you guys can be my sanity check.

Also, is anyone else doing this?

Here’s the markup. We had this done weeks ago.

<!-- yes, we get the gas face for href="#"
I don't like them either.
I'll rewrite it to use just LIs, I swear.
-->
 <ul id="font-size"><li class="text">Text Size:</li>
  <li><a href="#" class="default">default font size</a></li>
  <li><a href="#" class="larger">larger font size</a></li>
  <li><a href="#" class="largest">largest font size</a></li>
  </ul>

The first thing I did was write a small chunk of code that runs on $(document).ready()

(yes, this is a jQuery project.)

//using the jQuery cookie plugin to get a pre-set value;
var fontSize=$.cookie('font_size');
//if it exists, set the body.className right now
//and...
//the user gets their size of choice right away
if (fontSize) {
	$(document.body)
    	  .removeClass("largest larger default")
          .addClass(fontSize);
}
$("#font-size li a").click(
	function(e){
		var $body = $(document.body),
		newClass = this.className;
		//if it doesn't already have the chosen class
    	       if (!$body.hasClass(newClass)) {
               //clear any old ones and add the new one
			$body
				.removeClass("largest larger default")
                                .addClass(newClass);
		}
                //saving the choice in a cookie
		$.cookie('font_size',this.className);
                //and finally, stop the clicks
		e.preventDefault();
	}
)

Cool. So far so good. We’ve got classes on the body indicating how big the user wants to see the site.

Before we look at the CSS, there’s one more bit of JavaScript we need to look at as I almost immediately envisioned a problem with the above scenario.

If i was using CSS Transforms to scale the pages in Firefox and then Firefox eventually implemented zoom, things would get wonky. We don’t want that. I had to future-proof the code a little bit.

So, what I needed was a test for the presence of a valid zoom CSS property. Turning to Modernizr (since it was already in use on the site) I used the handy Modernizr.addTest method to test for zoom. Here’s the one I cobbled together.

     Modernizr.addTest('zoom', function () {
//create a div
        var test = document.createElement('div');
//if there's a valid property in the browser
//it will return ""
//undefined means the browser doesn't know
//what you're talking about
 	    if (test.style.zoom === undefined) {
		    delete test;
		    return false;
	    }
	    delete test;
        return true;
    });

And finally, we’ve got the style sheet.

/*
we add a .default class, so we can reset the page with
the mechanism defined above
*/
body,
body.default {
	font:13px/1.231 arial, helvetica, sans-serif;
	color:#222;
	background:url(images/page-bg.jpg) center repeat-y;
	min-width:960px;
	overflow-x:hidden;
}
/*
here's our class for browsers without a zoom property,
this sets the transform's origin. In this case it defines
the point from which our scale will happen.
We want it to row from the center and from the top,
so 50% and 0 it is.
*/
.no-zoom body {
	-o-transform-origin:50% 0;
	-moz-transform-origin:50% 0;
}
/*
classes for browsers with zoom
*/
.zoom body.larger {
	zoom:110%;
}
.zoom body.largest {
	zoom:125%;
}
/*
and classes for browsers that don't support zoom
*/
.no-zoom body.larger {
    -o-transform: scale(1.1);
    -moz-transform: scale(1.1);
    transform: scale(1.1);
}
.no-zoom body.largest {
    -o-transform: scale(1.25);
    -moz-transform: scale(1.25);
    transform: scale(1.25);
}

And that’s that. Here’s a quick demo to see it in action. You can also view source here.

Performance

I did a quick V8 Benchmark comparing scaled/zoomed performance in several browsers to see if there are any issues. The following table shows that there really isn’t much difference. Clearly this isn’t a definitive test as it’s only a small run of tests in one benchmark on one machine, but it was nice that nothing shook out in this first pass. I’m going to look at doing a DOM heavy test as well as something with some animation (maybe even Canvas?)

I kind of like it.

CSS 101 from Matt Murphy on Vimeo.

Slides.

It’s pretty good- minus the difficult with actually showing the jsfidddle code on the projector.

Anyway, today I’m going to continue to talk about the technical interview process. This time with an anecdote culled from my time on the other side of the desk.

I was interviewed a while ago by someone who was significantly junior to me. I think he had maybe 3 years of experience. I was supposed to have been interviewed by someone who would have been a peer at the company, but that fell apart and it fell down to a junior resource. He asked me two questions over a span of ten minutes. Both were worth commenting on, but I’m going to focus on the first one as it illustrates something pretty important about who you have interviewing people and what they should be expected to be able to figure out about a candidate.

We get on the phone, trade pleasantries and then he gets started. He asks me the following question:

“You have a div with a width of 300 pixels. It’s got a margin of 10 pixels. How big is the box?”

Do you see a problem with that question?

If you’re trying to test someone on knowledge of the W3C box model, margin is meaningless.

The way to ask that question is to use padding. Margin sits outside the (visible) box. It’s part of the element’s total offset width, but it’s not part of the visible width. More importantly, that’s true no matter what box-model you’re dealing with. So, if you’re asking about the box, without borders or padding, 300px is going to be 300px no matter what the margin is.

Here’s a jsfiddle which illustrates that using the CSS3 box-sizing property. Inspect away.

So, faced with knowledge of all the above, I asked a follow-up question:

“Okay, you’re trying to see if I understand the box model. Cool. So, do you want the size of the div visually (the width of the box) or do you want its offset width? Margin is outside the box so it’s meaningless for the width of the box.”

At this point things broke down. I won’t go into details (especially since .it’s been over a year,) but the thing I walked away from the conversation with was the plain fact that he wasn’t prepared for anything other than a number to come back as an answer. I was going to be judged solely on the calculation I did. Things fell apart because his question was poorly worded, focused on the wrong property and he wasn’t confident enough on the topic to clarify so that I could provide the correct answer. We talked about it for about five minutes and I still don’t know what the “right” answer was.

As a note, I actually mentioned box-sizing:border-box. I’m pretty sure that ended up making things worse.

When I do quizzes like this (and I don’t- I prefer whiteboard/coding sessions), I’m looking for questions. A lot of times the questions and comments are going to tell me more about a candidate than a quick answer. Questions and comments expose depth. Depth of knowledge = good.

The thing is, to be able to do that I need to absolutely know the subject I’m asking about. Otherwise… you get what I experienced, five minutes of frustration and embarrassing gaps in the conversation.

The takeaway?

In a technical interview, only have people cover topics that they really know. If you want junior people to interview, coach the hell out of them on the subjects they’ll be asking about so that they don’t end up wasting anyone’s time.

“What’s your favorite JavaScript library and why?”

At which point, I think I fell asleep.

Sweet.

Here are the slides. I’ll have some video soon (either of this one or of the upcoming version I’m giving at Design Camp Boston.)

Thanks to the folks from Boston PHP for the opportunity and to the guys over Bocoup for hosting.

Formatting

During development I format my CSS with selectors on one line and then each property on its own line. The declarations are indented 4 spaces. I like this style because my interest is always in the properties, not the selectors. I can find any selector I need with CTRL+F and then I can easily scan down the list of properties to do my business.

It looks like this:

#main article strong {
	font-weight:bold;
}
#text #main article blockquote {
	background:#efefef url(http://d1eucpngoftcha.cloudfront.net/_assets/styles/images/bq-bg.png) no-repeat;
	color:#600;
	font-style: italic;
	margin: 15px auto 30px auto;
	padding: 30px 30px 15px 75px;
}
#text #main article blockquote cite {
	color:#333;
	font-size:90%;
	font-style:normal;
}
#text #main article ul {
	font-size:14px;
	margin: auto auto 30px 15px;
}

Some people take that approach and indent related or child styles and additional 2 or 4 spaces. That allows for hierarchical scanning and organization and makes (for some people) an easier-to-read style sheet. That looks like this:

.post-list li a{
	color:#A8A8A8;
}
    .post-list li a:hover{
        color:#000;
        text-decoration:none;
     }
     .post-list li .author a, .post-list li .author a:hover{
         color:#F30;
       	 text-transform:uppercase;
     }

Other people like to scan the file for selectors, so they produce CSS with selectors and declarations on one line. I personally have a hard time with this style, but some people I know swear by it, so I present it here:

  #wrapper                        {width:800px; margin:0 auto;}
  #header                         {height:100px; position:relative;}
  #feature .post                  {width:490px; float:left;}
  #feature .link                  {width:195px; display:inline; margin:0 10px 0 0; float:right;}
  #footer                         {clear:both; font-size:93%; float:none;}
  #footer .wrapper                {float:none;}

Whatever style you use, it’s good practice to minify your CSS before pushing to production so that all the extra characters you pump into your sheets for ease-of-use as a developer don’t slow down the experience of your users.

Shorthand

There are two ways to approach many families of CSS properties: verbose and shorthand. Verbose properties look like this:

.verbose {
    font-family: "Times New Roman", Times, serif;
    font-size: 12px;
    font-style: italic;
    line-height: normal;
    font-weight: bold;
    color: #003333;
    background-color: #FFFFCC;
    padding-top: 5px;
    padding-right: 10px;
    padding-bottom: 15px;
    padding-left: 20px;
}

Shorthand looks like this:

.shorthand {
    color: #003333;
    font: italic bold 12px/normal "Times New Roman", Times, serif;
    background: #ffffcc;
    padding: 5px 10px 15px 20px;
}

Once you’re used to it, shorthand is much faster to write and it takes up a lot less space. So… use shorthand. To get you started, here’s a fancy guide Dustin Diaz put together a few years ago. It’s out of date for newer properties, but it’s useful for the stuff you’re going to use every day.

One thing that’s super-useful to remember is the TRBL acronym which give the order of values in properties like margin and padding.

Reset Style Sheets

Much has been written about reset style sheets. I’m not going to add to the noise here. The point of them, simply, is to level the playing field across browsers so that you start from a common point when creating styles for your site or application.

I use one, and suggest you do too. As to which one, for a while I used a variation of Eric Meyer’s reset reloaded with the later addition of the following line in place for HTML5 sites to set proper display types for the new elements:

article,aside,canvas,figure,footer,header,hgroup,menu,nav,section,summary {
    display:block;
}

For my latest project we’re using this HTML5 Reset, which is based on Meyer’s sheet and adds several HTML5 enhancements.

I like it.

Organization

I organize my style sheets by area of the page, seriously influenced by the order in which I work on things.

The basic structure might look something like this:

_____________________
|   Copyright                |
------------------------
|   Common colors         |
------------------------
|   Reset Section          |
------------------------
|   Basic Typography     |
------------------------
|   #Header                 |
------------------------
|   #Content                |
------------------------
|   #SideBar                |
------------------------
|   #Footer                 |
------------------------
|   #Random Widgets    |
------------------------

I try to comment each section clearly and comment where appropriate outside of the sections to illustrate strange and wondrous constructions.

A small (production) snippet might look like this:

/* -------- COLORS ---------
lightest gray: efefef
light gray: ccc
medium gray: 999
darker gray: 666
darkest gray: 333
light blue links: 69F
body light blue links : 4B87C2
dark blue links : 036
visited: 306
red 930
--------------------------*/
/*reset section*/

html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {
	margin: 0;
	padding: 0;
	border: 0;
	outline: 0;
	font-weight: inherit;
	font-style: inherit;
	font-size: 100%;
	font-family: inherit;
	vertical-align: baseline;
}
ol, ul {
	list-style: none;
}
caption, th, td {
	text-align: left;
	font-weight: normal;
}
table {
	border-collapse: separate;
	border-spacing: 0;
}
caption, th, td {
	text-align: left;
	font-weight: normal;
}
blockquote:before, blockquote:after, q:before, q:after {
	content: "";
}
blockquote, q {
	quotes: "" "";
}
footer, section, article, nav, header, aside, figure, dialog {
	display:block;
}
body {
	font: 13px Verdana, Arial, Helvetica, sans-serif;
	color: #666;
	background-color:#ccc;
	padding-bottom:50px !important;
}
strong {
	font-weight:bold;
}
em {
	font-style:italic;
}
/*main div- holds the rest of the site*/
#container {
	margin: auto;
	width: 992px;
	background-color:#fff;
}
/*************header*****************/
#header {
	padding-top:20px auto auto 0;
	border-right:10px solid #fff;
	border-left:10px solid #fff;
	position:relative;
}
/*the anchor inside the h1*/
#container #header h1 a {
	text-decoration:none;
	color:#999;
	font: bold 30px Consolas, Inconsolata, "Lucida Console", Monaco, "Lucida Sans Typewriter", monospace;
}
#header h1 strong {
	color:#333;
	margin-right:-16px;
}
#header h1 em {
	color:#666;
	margin-right:-16px;
}
#header h1 a:hover {
	text-decoration:underline;
}
/*tagline*/
#respond, #container #header .title {
	font-size: 18px;
	color: #999;
	margin-top:10px auto 20px auto;
	font-style:italic;
}
/*end header*/
/************************main content area*****************/
/*overflow:auto clears floats like magic*/
#content {
	overflow:auto;
	border-right:10px solid #fff;
	border-left:10px solid #fff;
}
/*main copy area*/
#container #copy {
	width:600px;
	border:1px solid #999;
	padding: 16px 10px 16px 12px;
	float:left;
	-moz-border-radius: 12px; /* FF1+ */
	-webkit-border-radius: 12px; /* Saf3+, Chrome */
	border-radius: 12px; /* Opera 10.5, IE 9 */
	-moz-box-shadow: 0px 0px 8px #999; /* FF3.5+ */
	-webkit-box-shadow: 0px 0px 8px #999; /* Saf3.0+, Chrome */
	box-shadow: 0px 0px 8px #999; /* Opera 10.5, IE 9.0 */
	margin-bottom:20px;
}
/******************************/
/* AND SO ON                                   */
/******************************/

Again, it’s useful to minify your CSS to strip out all of those comments and all of that whitespace. Comments are good for development though, so be sure to use them.

and there you have it. some info on some very basic, but very important CSS practices. Next time we’ll start to look at common techniques.

Should be fun.