When styling headings (or really anything) we want three big goals to be met:

1. DRY – Do not repeat yourself. We want to set headings once and never (ok, rarely!) repeat those font styles or selectors. This will make our site easier to maintain.
2. Predictable – The heading should look the same no matter where on the page it is placed. This will make creating new pages and content easier.
3. Keep specificity low and selectors as simple as possible. This will help with performance and keep the site from growing more and more tangled over time.

The html5 section tag is weird. It dramatically changes the way we use headings. It also changes the way browsers and assistive technologies are meant to interpret those headings. The spec says:

“The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.”
The HTML5 Spec

The spec goes on to warn us that sections are not really meant to be used just because you want to attach a style a particular piece of content:

“The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.”
The HTML5 Spec

People seem to have blocked out this last (very important) bit, so I’ll reiterate. Sections aren’t really meant to be used by CSS for style purposes (at least not *only* for styles). So, if sections aren’t meant to be used to make my headings purty, why do they exist? They change the way the browser and assistive technologies interpret the importance of a heading relative to the other headings on the page. To understand this, you need to know a bit about the pitfalls of the way headings have been written up until now.

HTML Headings

Think back to the outlines you wrote for term papers in high school. Each bit of a website is meant to be like that, each heading corresponds to a piece of that outline, and you know when you go up or down a level by the heading level chosen. H2 is down one level from H1. And h6 is down four levels from H2.

THE TITLE IS THE H1
I. Big roman numerals are the H2s
   A. This is an h3
   B. This is also and h3
      i. Now we have an h4
      ii. And another h4
II. Big roman numerals are the H2s
III. Big roman numerals are the H2s
IV. Big roman numerals are the H2s

The trouble is, on a modern website or web app, this model isn’t a really natural fit. Especially if a site “mashes up” content from sources they don’t control (say for example adding a twitter feed to a blog), they may not be able to set the heading levels used by the mashup content. In this case, most developers, just include the new content, and the outline gets a little murkier.

A murky outline may be somewhat normal, because I’d take it a step further and say that, on most modern websites, the idea that the site has much in common with a high school term paper outline is a bit of a stretch — The section element tries to bridge the gap between the w3c’s outline view of the web and the way developers are really building sites. The section element essentially reorders the heading tree so that whatever headings are used, if they are wrapped in a section element, they will be made to fit in with other content on the page. They need only be internally consistent within each section.

<h2>Me on the web...</h2>
<h1>My Twitter Feed</h1>
<ul class="tweets">
 <li>Mmmm, cornflakes.</li>
 <li>Something inane...</li>
</ul>
<p><a href="more.html">More stuff on the web</a></p>

HTML5 Headings & Section Elements

If you wrap it in a section, the browser will interpret it as one level down from it’s parent heading.

<h2>Me on the web...</h2>
<section>
<h1>My Twitter Feed</h1>
<ul class="tweets">
 <li>Mmmm, cornflakes.</li>
 <li>Something inane...</li>
</ul>
</section>
<p><a href="more.html">More stuff on the web</a></p>

The section element also makes it clear that the list of tweets belongs to the Twitter feed, and the more link does not. This makes content more portable, which is okay — even if it maybe isn’t that important. However, it does seem to be confusing people about how they should style their headings. I think this bit of the spec might be confusing people:

Notice how the use of section means that the author can use h1 elements throughout, without having to worry about whether a particular section is at the top level, the second level, the third level, and so on.
The HTML5 Spec

This has lead people to think that they should only ever use h1s (which, is a fair interpretation of the working group’s note). However, lots of people have taken it a little too far because they didn’t read the second quote [1], where it says additional section elements shouldn’t really be used only to apply CSS styles. Admittedly a subtle difference, but important! Section elements are meant to help the browser figure out what level the heading really is, but not necessarily to decide how to style it. By tying styles to browser heading level interpretation, developers (trying to implement html5 from the spec) are ending up with selectors that look like this:

h1{font-size: 36px}
section h1{font-size: 28px}
section section h1{font-size: 22px}
section section section h1{font-size: 18px}
section section section section h1{font-size: 16px}
section section section section section h1{font-size: 14px}
section section section section section section h1{font-size: 13px}
section section section section section section section h1{font-size: 11px}

(Note: This is vastly simplified as I’ve only included sections and not the other sectioning elements like articles or asides. This is a more realistic, real life code sample.)

Let’s see how well this meets our goals:

Q: What if, semantically speaking, you need to add an additional section to a bit of html?

It will unintentionally change the way your headings look. If it is high enough on the document tree it could change your entire page. That seems badly unpredictable.

Q: What happens if the design calls for a 14px heading in a part of the site that is only nested two sectioning contents deep?

To make it work with the existing code, you would need to add additional unnecessary section elements. The spec pretty clearly states that section elements are not meant to be added just to change styles. Plus, that is just kind of gross.

Q: What if we create another rule that duplicates the 14px property value pair?

section.special section h1 {font-size:14px}

This clearly isn’t DRY. We’re repeating the code to set the font-size to 14px, and our specificity is starting to get weird. If we want a normal two-section deep heading (22px) we now can’t have it in the special section. We also can’t reuse the new rule anywhere else. Continue in this direction for a while on a project and you can end up with hundreds or even thousands of heading declarations. Eek! This isn’t meeting our stated goals at all.

(For more info about how this can get out of control, check out this video on how our current methods for styling headings are leading to bad outcomes.)

So, how do we style headings in an HTML5 world?

The answer is right there in the spec, next to the place where we learned to use only H1s. We shouldn’t use sectioning elements for styling. We should let them do the job they were designed for, which is sorting out the document tree, and solve styling issues another way that meets our goals better: with simple reusable class names that can be applied to any of our headings no matter how deep they may be in the sectioning content.

I recommend abstracting site wide headings into classes because then they are portable, predictable, and dry. You can call them anything you like. Jeremy Keith recommends something like:

.Alpha {}
.Beta {}
.Gamma {}
.Delta {}
.Epsilon {}
.Zeta {}

or

.tera {}
.giga {}
.mega {}
.kilo {}
.hecto {}
.deca {}
.deci {}
.centi {}
.milli {}
.micro {}
.nano {}
.pico {}

I keep it simple with:

.h1{}
.h2{}
.h3{}
.h4{}
.h5{}
.h6{}

It doesn’t really matter what system you choose as long as it is something easy for your team to remember. Then, no matter how many section levels deep your heading is nested, you can make it look just how you want:

<h1 class="giga">Me on the web...</h1>
<section>
  <h1 class="kilo">My Twitter Feed</h1>
  <ul class="tweets">
    <li>Mmmm, cornflakes.</li>
    <li>Something inane...</li>
  </ul>
</section>
<p><a href="more.html">More stuff on the web</a></p>

So now, your twitter feed, from the previous example, can be in the sidebar on an article page, or in the footer of your homepage, and it will still look the way it was designed to. Whether you are using html5 sections or not, you don’t want to repeat code or have it be unpredictable, so I think separating styles from how the browser generates the page outline is just sensible.

UPDATE 9/6: If you truly cannot change the HTML, even to add class names, then the only way to style that bit is to put a wrapper around it with a unique class and use descendent selectors to force the style you want. This should be the exception, not the rule! (Thanks Simon for pointing out that I wasn’t addressing one of the use cases I had talked about above)

<h1 class="giga">Me on the web...</h1>
<section class="tweetfeed">
  <h1>My Twitter Feed</h1>
  <ul class="tweets">
    <li>Mmmm, cornflakes.</li>
    <li>Something inane...</li>
  </ul>
</section>
<p><a href="more.html">More stuff on the web</a></p>

If you would like a far more eloquent walk through all the new html5 elements, get Jeremy Keith’s book HTML5 For Web Designers.

Thanks to Alex Kessinger and Josh for helping me solidify my thoughts around this by bringing up good questions on the CSS Lint Google Group.

CSS Lint is a tool to help point out problems with your CSS code. It does basic syntax checking as well as applying a set of rules to the code that look for problematic patterns or signs of inefficiency. The rules are all pluggable, so you can easily write your own or omit ones you don’t want.

Rules currently tested

• Parsing errors should be fixed
• Don’t use adjoining classes
• Remove empty rules
• Use correct properties for a display
• Don’t use too many floats
• Don’t use too many web fonts
• Don’t use too may font-size declarations
• Don’t use IDs in selectors
• Don’t qualify headings
• Heading elements should have a consistent appearance across a site.
• Heading styles should only be defined once
• Be careful using width: 100%
• Zero values don’t need units
• Vendor prefixed properties should also have the standard
• CSS gradients require all browser prefixes
• Avoid selectors that look like regular expressions
• Beware of broken box models

(We’ll allow you to turn off rules that hurt your feelings soon!)

Contribute

Many people have expressed an interest in contributing to the CSS Lint project. We were waiting to have a solid plugable architecture and API before taking contributions. The exciting news is that we are now ready! There are several ways you can contribute:

1. If you are comfortable with CSS, submit rule ideas. You must provide the rule name, a human readable explanation, browsers affected, and a test case.
2. If you are comfortable in JavaScript, fork the github project, code up a rule, and submit a pull request. You’ll need to provide all the same documentation requsted in item 1.
3. If you are comfortable with Node, test out the command line version, submit feature requests.

CSS Lint for Node.js

If you’d like a command line version of CSS Lint, you can install CSS Lint for Node.js using npm using the following:

sudo npm install -g csslint

Once installed, you can pass in any number of CSS files or directories containing CSS files to see the results. For example:

csslint test.css dir_of_css/ test2.css

You’ll receive the same errors and warnings as you would with the web interface.

I’ll let Nicholas speak for himself:

I’ll be … teaming up with my friend (and former Yahoo) Nicole Sullivan to do consulting work. Nicole and I have talked off and on about working together on outside projects after having fun working together on a couple of projects at Yahoo!. Between the two of us, we hope to provide a wide range of front-end consulting services including performance evaluations, general architecture, and of course, JavaScript and CSS. If you’re interested in hiring us, please email projects (at) stubbornella.org.
Nicholas Zakas

Please come see us at Velocity Conference on June 14.

I was prepping to speak at Webstock this year when I realized I didn’t want to give the talk I had proposed. I didn’t want to talk about the Mistakes of Massive CSS, because I realized it went deeper than that. In fact, in most cases, the things we considered best practices were leading to the bad outcomes we sought to avoid. I realized (unpopular though it might be), that we couldn’t make it work out well by trying harder. Each time we start a new project, we think “this time, I’m going to keep the code clean. This time the project will be a shining example of what can be done with CSS.” And without fail, over time, as more content and features are added to the site, the code becomes a spaghetti tangle of duplication and unpredictability.

It is time to let ourselves off the hook. There is nothing we could have done by trying harder. There is no magic juju that some other developer has that we don’t. Following our beloved best practices leads to bad outcomes every. single. time.

What are those flawed best practices?

• Classitis!
• Never add an non-semantic element
• Or, a non-semantic class
• Use descendant selectors exclusively
• Sites need to look exactly the same in every browser

Here is the video of my talk at Webstock 2011:

Classitis!

How in the world did we even get the idea that some aspects of CSS were good and others evil? Who decided and what data did they use to judge? Did their goals fit our goals? There is nothing wrong with using classes. In almost every case, classes work well and have fewer unintended consequences than either IDs or element selectors.

You should style almost everything with classes. The goal is to find a balance between classes that are too broad and include everything and the kitchen sink and classes that are too narrow. Generally speaking, you don’t want your classes to be so narrow that each one applies a single property value pair. It becomes extremely hard to evolve your design if every item is composed of mini-mixins.

On the other hand, if classes are too broad, you will have duplication. Try to find the middle ground where all the repeating visual patterns can be abstracted. This is hard, but very worthwhile. If you do it, your code will stay clean. You will finally see results from trying harder.

Classes are our friends. Seeing a lot of IDs is actually very bad. Run from this kind of code:

#sidebar #accounts #accountDetails h3{}

Never add non semantic elements

We don’t want to have unnecessarily heavy HTML with a lot of extra elements. On the other hand, adding an extra element can often provide a buffer between two sets of classes that weren’t necessarily coded to interact with one another. For example, I prefer to have the decorative elements of a container completely separated from its content.

Using a paragraph that happens to be inside a rounded corner box to make a corner decoration means that the container can never hold content other than a paragraph. If you want to include a UL you will need to duplicate all those styles. This doesn’t work.

You want your content to be marked up in beautiful HTML that uses a diverse set of tags like P, UL, OL, LI, H1-6, strong, em. Add a few extra wrapper elements to keep your content nicely cordoned off from your containers or separate out decorative flourishes! Your HTML will be clean and your CSS predictable.

Never add non-semantic classes

We absolutely don’t ever want to use classes like “bigRedHeading”, not because it is non-semantic, but because it isn’t future proof. As the design evolves, the CSS needs to keep pace. On the other hand, CSS needs abstractions. We need to be able to solve a particular problem really well, and then allow people to go on using that solution long afterward. Grids for example solve the layout problem. Once they have been implemented on a site, developers can spend time on more important features and stop re-implementing a layout solution over and over. Abstract solutions are necessarily disconnected from the content they happen to contain. This is something we should look for in a solution, not condemn.

The semantics debate has really gone too far. It is useful as a general principal, but often I see standards aware developers trying to stuff in semantics that never existed in the design. If the design didn’t make a distinction between two things visually, why add additional complexity? Classes work much better when we use them to represent visual semantics, rather than keeping them tied to content.

One more point on the topic. Screen readers don’t read class names. It is not an accessibility issue. (Thanks to John Foliot for confirming)

Use descendant selectors exclusively

Never has more terrible advice been given (ok, ok, I exaggerate, but for CSS, this is as bad as it gets). The descendent selector is *only* appropriate between multiple nodes of the same object (say, a tab container and its’ tabs), and even then, only when you are absolutely certain that there will never be any markup changes. Very hard to guarantee, no?

I have had a designer give me a tab container that had one group of tabs to the left and another grouping (usually more simply styled) to the right. In which case, if you had styled the UL using the descendant selector, you would be stuck overriding a bunch of styles you no longer needed. Classes are much much better and can be used in combination with the descendant selector when the nodes belong to the same object.

I guess the only time I use the descendant selector with elements is to style LI, and even then, I often get bitten when someone wants to nest those lists. Better support for the child selector will make that issue easier to fix. Ideally, we don’t want any styles flowing from container to content.

Even with the media block, you might consider putting a class on the media block which sets the styles of the image. It sounds reasonable until you realize that the image is actually its own object. You might have multiple nested media blocks and you will get very weird interactions unless you apply the image style class directly to the image itself.

In the middle layer, you might decide to create one display objects for each of the different types, and that would probably make the objects easier to use, but in the CSS layer, you don’t want to tie it all together like that.

Sites need to look exactly the same in every browser

Forking your design is bad, it makes testing even more complicated, but that doesn’t mean that pixel for pixel a site needs to be exactly the same in every browser. If you try to force the complexities of a modern design onto users of IE6, their user experience will suffer. The site will load slower and reflows and repaints will make the javascript sluggish. IE6 users need a reasonably fast user experience, they do not *need* rounded corners.

Anyway, enough ranting. Please do checkout the slides and video. I hope you find them useful.

If you don’t know what I mean, picture me with a color picker going pixel by pixel to try to figure out by hand where the color stops should be and what colors I should use versus extrapolate. Then, for each version, making an image of the gradient I’ve created, blowing it up so I can compare it to the image of the original. Rinse, repeat until I’ve come up with something that kinda, sorta approximates the original. Oh yeah, painful.

Which lead me to tweet the following:

There was a lot of response, many people re-tweeted saying that if I found such a tool, they wanted to know about it! Several others said it was interesting, but that the more complex cases would be difficult to navigate. Twelve hours later, Philip Tellis had gone from not knowing what a CSS 3 gradient was, to writing an open source command line tool to convert png to CSS. It solved for linear gradients, which is exactly what I needed to fix the performance of sites whose that had gotten sloggy. Most of these sites used linear gradients as images, which are notoriously difficult to sprite.

I was excited, to give it a try, and also, a little nervous to once again meet my nemesis, the command line. Then, before I could blink Zoompf took Philip’s BSD licensed code and created a hosted version (w00t! hosted version!):

In the mean time, Colorzilla, creators of several fab tools for designers, had also gotten word about my plea for a conversion tool, and they thought it would be a great addition to their own functionality. A couple days later they tweeted that they had a prototype up:

Perhaps I’m being a little too Californian, but I have a warm fuzzy feeling about our community. I think one of the biggest challenges we are going to face is the lack of tools we have relative to other communities. So when we can come together to build tools that will save loads of developer time, I kind of love it. Even better, Philip’s choice to open source his work meant that others were free to expand upon it.

Is anyone else doing something really cool with CSS 3 gradients? I’d love to hear more about it. The CSS 3 Pattern Gallery kind of blew my mind. With every example, the boundaries of what is possible expand.

I’m going to be hosting a workshop in which you will learn to build your own site using OOCSS techniques. By the time you leave you will have the skills necessary to write efficient, scalable CSS. You’ll understand the joy and pain of CSS3 and HTML5, and be ready to go build the next generation of websites and web apps.

Steve’s workshop is filled with Mobile yummy goodness. How do you figure out that your mobile app is slow before your clients start complaining? What’s even going on in there? In his workshop, Steve is going to open up the mobile black-box and teach you to take a peek inside.

I am super excited about Webstock, even more so now that I found out it will be a perf-geek-meet-up. New Zealand here I come!

The Importance of Page Weight

The weightier your page the slower the user experience. There are a few notable ways you can ease this correlation, but for the most part keeping your pages snappy is about being absolutely relentless when reducing and optimizing code. CSS is no exception.

On the other hand, a blank white page with unstyled black text and blue links would be very fast — but no one would care to visit. When we accept that we want sites which are both graphically interesting and fast we can begin to find ways to achieve what I think of as a one to many relationship between the amount of CSS we write and the potential layouts we can achieve.

The cure for bloat

Finding common denominators in our site will allow us to standardize the way we group related content, and the classes we use to style that content. You can think of these common denominators as the semantic building blocks of a high performance website. On a basic level that means that most sites have a particular way of displaying, for instance, a product. Perhaps with an image of the product to the left and a description of the product to the right. If that configuration appears throughout the site it should not be rewritten each time or we’ll have a 1:1 correlation between the size of the CSS and the complexity or number of pages in the site. These are the kind of sites that might start off fast but over the course of their lifetime become slower and slower. Once clean CSS becomes bloated with unnecessary recoding of semantically and visually identical elements.

Where do grids fit into the mix?

Grids are one of the simplest examples (to see, not to code) of patterns that can be abstracted across a site. The same basic three unit pattern which divides grouped content into three semantically linked chunks can be seen inside the main column content and also inside a module, defining different groups of content. In the next two pictures, I’ve outlined in orange the same grid being used two ways. Not coding this again and again is a huge performance win when multiplied over all the components and pages of a large site.

Image 1: Grids can be used to define the structure of the main column of a page.

Image 2: The same grids being used to break up the content within the body of a module.

It’s easy to see each piece of your site as a one-off, unique, something which will never vary — but performance dictates that we take a more sage approach. We need to abstract objects, the simple building blocks of your pages. The objects can then be combined to create pages and the pages combined to create entire sites.

Do not reinvent the wheel, grasshopper (at least not for a major client)

You may be tempted to write your own grids framework rather than use one that is already out there. The not invented here mentality is really hard to get around. If you really can’t resist the urge to write your own grids, do it for your blog, not a major international company. It’s a fun exercise, but the pitfalls are treacherous.

The Requirements & Constraints

• Grids and units can be nested inside each other to achieve complex layouts. The logic is very simple; any grid can be nested inside any other. Keeping constraints low simplifies CMS development. You should not need to write any additional CSS to make this possible or you start getting n! css rules. Yes, this is bad.
• Each unit controls it’s own destiny, uh, width that is. In CMS design, one of the most costly operations is when you need to make changes elsewhere in the DOM in order to generate display or behavior in the current location. Keep all the classes necessary for the unit to function on the unit itself. This will make page building much quicker and code easier to navigate.
• Unit width can be any fraction of the total width. Generally I create fractions up to fifths, more than that is probably overkill.
• Fewer templates. Templates are unique starting points for building pages. They complicate using a CMS because generally they aren’t designed so that you can go from one to another easily. Developers love to create new templates, while CMS users hate them. Try to refrain.
• No JS required. Using JS for basic layout is wasteful. We need JS to do other important things, thus we need to solve layout problems with CSS.

Redefining the template

Traditionally, a new template is created for each page type. Separate templates might be defined for one column, two column, and three column layouts, as well as home pages, main product pages, etc. Grids allow you to base all of these pages on the same template, which might include only the basic frame, header, body and footer. The template stays simple because grids allow you to break up any one of these regions into convenient units of content. You should then include a “save as a template” option. Your users can then define templates as they build pages in your CMS, saving at convenient points from which they can build pages. Having a common starting point, or one single base template will mean that users can undo any choice they’ve made.

More about templates in another article.

Grids solutions

So now that you know a bit more about how to choose a grids solution, go check out these frameworks to find the one that will work for you:

* YUI3 requires an extra sub-node wrapper for the gutter.

Any other grids frameworks I should have included?

Note: I wrote most of this article years ago, but never got around to publishing it because it wasn’t “perfect”. (Oh how annoying it can be to be me). If you notice anything out-of-date, please do bring it to my attention.

  content:" x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x ";
}

I wrote a while back about creating new formatting contexts with overflow: hidden. A new formatting context is desirable because it tells an element not to wrap around nearby floats, and to clear any floats it contains. Essentially a new formatting context makes an element behave like a column. Anyone who has tried to create a grids system or multi-column layout knows that that is no easy feat.

Zoom Baby

This is one case where Internet Explorer gets it right. Zoom triggers hasLayout, which creates a new formatting context, clears floats, and prevents float wrapping with none of the drawbacks of the standard solutions.

.lastUnit{
  zoom:1;
}

I wish we had a simple property value pair that would do the same thing in standards-based browsers.

.lastUnit {
  formatting-context: new; /* please! */
}

There are several ways of achieving the same thing in Safari, Firefox, Chrome, and Opera, but they each have drawbacks. For example:

Overflow Hidden Hides Stuff

Overflow hidden creates a new formatting context with very few side effects, and for many websites, it will still be the right answer, however it does have one major drawback. If any content within the element overflows its boundaries, it will be cropped. Normally, if you don’t specify a height (you shouldn’t need to), the element grows to the size of it’s content.

 .lastUnit {
  overflow: hidden;
}

However, on a complex site like facebook (and most applications), popovers, fancy buttons, and menus were cropped off because they were outside of the normal document flow and didn’t influence the height of the parent node. This forced me to look for another solution.

Table Cells Create a New Formatting Context

In the specification, several property value pairs create a new formatting context including; overflow (other than visible), table-cell, inline-block, and float. I set out to try them all. Other variations of overflow triggered a scroll bar that didn’t make me happy, and one of them (sorry, it was a year ago, I can’t remember) caused issues in RTL.

I began to test display: table-cell. I used the OOCSS grids test page in which each grid contains a heading and a paragraph filled with lorem ipsum text. To my astonishment, display table cell worked.

.lastUnit {
  display: table-cell;
}

The HTML of the last unit.

<div class="unit size1of5 lastUnit">
  <h3>1/5</h3>
  <p>i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i </p>
</div>

I was very pleased with myself, until I looked at the modules page. All of the modules in the last column were shrink-wrapped to the text. I began to explore what was different about my working grids and my broken modules. You can see the same issue on the facebook comments page. Notice how the comment box is far too narrow.

Comment box should be full width, but display table cell is shrink wrapping content.

I discovered that display table cell shrinks or grows to fit the content (much like a floated element). On my grids test page, the lorem ipsum dummy text was actually pushing the last column open to take all the remaining space on the line. I was getting the behavior I wanted, but it was triggered by the content, which is unacceptable for OOCSS, because OOCSS requires a strict separation of container and content. I couldn’t require text in the grids, in fact, I have no idea how people will use them.

Generated Content FTW

I realized that generated content was the only way to insert this text without requiring developers to muck up their HTML. As a bonus, generated content is not a part of the DOM, so it should be ignored by screen readers. I took a look at the specification and used the YUI clearfix implementation as a starting point for my solution (This is where things get a little bit crazy). My column, lastUnit, is still set to display table-cell, but we also add the following code:

.lastUnit {
  display: table-cell;
}
.lastUnit:after {
  clear: both;
  display: block;
  visibility: hidden;
  overflow: hidden;
  height: 0 !important;
  line-height: 0;
  font-size: xx-large;
  content: " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ";
}

Crazy, right? So let me show you what I’m doing here.

Understanding the Code

First, open the module test page in Firefox with Firebug enabled. The modules are inside thirds grids, which use the technique. Change visibility so that you can see how it works.

visibility: visible;

The generated text pushes my lastUnit open in much the same way the lorem ipsum dummy text did in the grids test page. They convince the browser that this element needs all of the space left after the width of floated siblings has been calculated.

Lets go through it piece by piece:

.lastUnit {
  zoom: 1;
  display: table-cell;
}

First, we create a new formatting context so that floats are not wrapped, margins do not collapse, etc. Display table cell is not well supported in older versions of IE, but it doesn’t matter because zoom does the trick. None of the rest of the code applies to IE.

.lastUnit:after {

We’re using the :after pseudo class so we can insert generated content (text) as the last node inside the lastUnit.

  clear: both;

Makes the generated content clear any non-generated sibling elements.

  display: block;

We want the element to expand to the full width.

  visibility: hidden;

Makes the generated content invisible and allows clicks and interaction with any content that might be below.

  overflow: hidden;

Makes sure height is respected by the browser, even in browsers that expand containers (an IE bug).

  height:0 !important;

We don’t want generated content changing the layout.

  line-height: 0;

Again, generated content shouldn’t change the layout. We’re covering all our bases.

  font-size: xx-large;

Large text means we’ll need less generated content.

  content:" x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x ";
}

The faux text does the heavy lifting by opening to full width the element which is in display table-cell.

Finally, An Opera Bug

Someone on the google group noticed that Opera was choking on this method. It seems that Opera cannot wrap a series of “. . .” as if it were normal text (a bug report was submitted, so this may have been corrected already). Simply changing all of the dots to “x” resolved the issue. Any text will work, Easter egg anyone?
We changed that line to:

content:" x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x ";

Drawbacks

Table-cells interact with each other in weird ways. Unlike other elements, which only interact with siblings and parent nodes when they change dimensions, table cells are weird and hard to calculate because the browser does a lot of fudging to make them line up and layout nicely. This fudging has proven to be expensive, so I do wonder about the performance impacts of this approach. Perhaps it is possible to set the display to fixed as Jenny Han Donnelly of YUI suggested — something to test another day.
Generally I avoid table cell whenever possible, but in this case I had tried all of the other methods for generating a new formatting context. Ultimately, browser vendors should allow a trigger that doesn’t have side effects.

Avoiding Pseudo-Bugs

It might be tempting to try to position our last column without creating a new formatting context, for instance, modern browsers are much better at calculating percentage widths. OTOH, zoom creates a new formatting context for IE and it is important to keep the flow as similar as possible across browsers to avoid unintended consequences.

It’s all about working with CSS rather than against it. That means that if you have a new formatting context in one browser you should have it in all of them. ]]> http://www.stubbornella.org/content/2010/12/09/the-hacktastic-zoom-fix/feed/ 47 http://www.stubbornella.org/content/2010/12/07/congratulations-justin-kelly/ http://www.stubbornella.org/content/2010/12/07/congratulations-justin-kelly/#comments Tue, 07 Dec 2010 17:49:58 +0000 Nicole Sullivan http://www.stubbornella.org/content/?p=713 They had a quote on their site which really struck me and made me feel lucky to have my friends.

Oh, the comfort - the inexpressible comfort of feeling safe with a person - having neither to weigh thoughts nor measure words, but pouring them all right out, just as they are, chaff and grain together; certain that a faithful hand will take and sift them, keep what is worth keeping, and then with the breath of kindness blow the rest away.

~Dinah Craik, A Life for a Life, 1859

Two of my dear friends just got married and their ceremony was as beautiful as it was fun. (of course you should replace the rehearsal dinner with a retro party!)

They had a quote on their site which really struck me and made me feel lucky to have my friends.

Oh, the comfort – the inexpressible comfort of feeling safe with a person – having neither to weigh thoughts nor measure words, but pouring them all right out, just as they are, chaff and grain together; certain that a faithful hand will take and sift them, keep what is worth keeping, and then with the breath of kindness blow the rest away.

~Dinah Craik, A Life for a Life, 1859

]]>

On the Big Web Show, I talked about being a women in a male dominated field (min 7:12). “I was a carpenter before I got into web stuff, so you guys can’t really compete with the carpenters, no matter how unruly you get.”

That is true, but a simplification. Zeldman threw me a chance to speak openly about being a woman in technology, and out of nervousness, I punted. Perhaps I was also afraid to sound strident? Anyway, I’m going to share some of the things that have happened to me, in hopes that it helps people realize that I was lucky to be successful and a woman. I mean, just take a look at the fastest growing careers for women. We are veterinary technicians not veterinarians, dental assistants not dentists, medical assistants not doctors. We like to believe we have evolved, but the data speaks to something else. Being a home heath aide is dirty work with bad hours and heavy lifting — but it is a career women can imagine, whereas, right now, they clearly can’t imagine themselves coding. I want to understand why not…

After conducting a thorough study on the status of female researchers at MIT. The Dean said:

The heart and soul of discrimination, the last refuge of the bigot, is to say that those who are discriminated against deserve it because they are less good.
Dean Robert J. Birgeneau, Dean of Science at MIT

He says it beautifully. Discrimination now rarely takes the form of some guy saying “hey little lady, shouldn’t you let a man handle that?” It is much more subtle, but just as ugly. These days, bright, thoughtful, enlightened people assume that the absence of women in certain fields results from women being unable to compete on merit. The assumption that, if someone creates a scholarship for women, it is because otherwise, women can’t hack it.

I would argue that there are female developers who are just as good as men, if not better, but despite that, they are less likely to stay in school, stick with engineering jobs, speak at or even attend conferences, and be recognized for their contributions. The problem compounds itself as women see no role-models for how to be a woman in this field, and only the very thick-skinned manage to stay in engineering and web development.

Why is computer science a sausage fest?

I believe CS and Web Development currently select for certain masculine qualities that are largely unrelated to someone’s prowess as a coder. I believe it is these tangential code-cowboy qualities women are unable or unwilling to emulate, and not their skill or capacity for abstraction, problem solving, creative thinking, or communication — All of which actually make them better developers. In fairness, I think a lot of men would rather not live like code-cowboys, but the unspoken judgement is adapt-or-you-must-not-be-smart-enough-for-CS. The vibe is a competitive rather than collaborative, and leaves many women feeling invisible.

Affirmative action

People mistakenly assume that affirmative action is about granting minorities undeserved privileges. In it’s purist form, affirmative action is about allowing minorities natural talents to flourish by removing artificial, unfair barriers and decoupling the true skills required to succeed in a profession from the cultural baggage that builds naturally within an insular community.

If we separate the criteria that makes someone a code-cowboy from the criteria that makes them a solid developer, I think we would find that women can and do compete despite significant discrimination. Scholarships like the one Google proposes aren’t meant to give women of lower merit something they don’t deserve, they are meant to circumvent the discrimination that extremely talented women still face. If you assume that a scholarship for women exists because women are inherently inferior, rather than because they are simply underrepresented, it might be time to soul-search and ask yourself if there is a bigot inside.

I (don’t) wanna be a cowboy, baby

The Twit-storm

Women may be less likely to be a code-cowboy, but they can be amazing developers. We are not trying to give anything to anyone that doesn’t deserve it, but instead, to counteract the subtle prejudices that leave women feeling invisible, excluded, and unrecognized for their accomplishments. Now, with that in mind, let’s look at the twit-storm I found after leaving a seven hour mediation session on Saturday. I’ll put my comments inline since I was unavailable to tweet that day.

The doofus that started it all:

RT @googlestudents Google grants for female computer scientists to attend JSConf 2010 // this is disgusting.. i hope there is one for guys.
fringley

This stinks of jealousy. Why not be happy for the female students? Why rain on someone else’s parade? Something good happening to someone else seems to disgust fringley. Frankly, it comes off as childish.

Moving on… this is when the storm began to brew.

Voodootikigod has the longest twitter name in the universe, and he makes a good point, we should remember that Google has good intentions and perhaps not be quite so disgusted. Fringley, I’m talking to you.

Special treatment for women with no merit?

Jdalton makes a good point. No one wants to feel like they got where they are because of what is in their pants. On the other hand, he assumes those women didn’t deserve to be sent to JSConf. Why should he assume that? In fact, the website says quite the opposite, the women must “have a strong academic background with demonstrated leadership ability.”

I resent the notion that women are inferior and that is why they are getting grants. Google is correcting for women being less likely to stand up and say “me, me, me!”, not for their technical skills or development prowess.

Thinking that I got where I am because I’m a woman and got special treatment (rather than on my own merit) is a painful and insidious form of discrimination. You have to be thick skinned to make it in a field where this kind of thing happens frequently. YES. It happens frequently.

What I’m trying to say is that women face a special challenge in tech because their male counterparts, when feeling jealous, will tend to pin female geek’s success on their gender. We face another problem, when we begin to wonder ourselves, and doubt our own abilities. This is the last refuge of the bigot indeed.

How can we attract more women to the field?

Yay! I like what voodootikigod says here. I saw Maria Klawe speak at Yahoo! about “Gender, Lies and Video Games: the Truth about Females and Computing”. She said that CS is the only science where the participation of women is getting worse not better. We have a problem. We’re geeks (supposed to be good at problem solving). So let’s figure it out!

I think we should look at:

• Video games are largely made by and for men. We need to be willing to rethink the genre completely, bust things wide open to make video games appeal more to girls.
• CS education works best for people who already know how to code before they begin. CS teaches the theory behind a practice in which they assume you already have some skill. Women are less likely to already know, because they don’t play video games as much. In addition, code-cowboys among their classmates are likely to judge them harshly for being a beginner. Are psychology majors expected to already know how to psychoanalyze patients before their first semester?
• CS education also focuses a lot of effort on puzzles and very abstract concepts when practical applications where you can see the why and how might work better for women (and a hell of a lot of men). I like yummy algorithms, but we could make CS education more accessible by putting them in context.
• Women are less likely to jump up and say “me! me! me!” They are far more likely to wait to be asked to participate. We don’t need women to be different than they are, we just need to invite them in a way that works. Hell, I spent 8 years coding CSS before I ever spoke about it to anyone. The first time I spoke at a conference, John Allsopp contacted me to ask if I would do it. I never would have submitted a proposal. You might say that I should have, but I would counter that I shouldn’t need to act like a dude to get respect.
• Women don’t have female role models. Now, I don’t mean that we need to have deep tear-filled conversations about the perils-of-being-women-in-technology. I would like to talk to geek women about geeky stuff, not about being a woman.
• At Velocity Conference this year, they had a girl-geek lunch. It was awesome! Just a note, they also had tons of women speakers and lots of female attendees. For a deep-geek conference, I was very impressed. Actively seeking female speakers does not mean accepting lower caliber. It means accepting that women might not submit proposals, but they might agree to speak if you ask them nicely. They might not be *famous*, but they may well be amazing innovators, skilled at what they do.
• Could we do something like MIT did? They commisioned a giant study, measured everything, and found that women were in fact being discriminated against. Their offices were smaller and had fewer windows, their pensions unpaid, they had unequal access to MIT resources. The study painted a grim picture, but then, with true MIT efficiency, they then set out to correct it. Well worth a read, especially if you think we are all just being sensitive. For the record, the ones that stay in the field are absolutely *not* being sensitive.
• Recognize the need for work-life balance. Most women still have primary responsibility for children and home. Women need to be equals at home first, but perhaps companies can make it easier for them to get access to awesome childcare and flex time.
• We need affirmative action to correct the problem. However, other developers need to recognize that the benefits of affirmative action go to women of merit. Not just people who happen to have a vagina.

Problem? What problem?

Um, dude, if your site was loading in 18 seconds but you couldn’t think of any reason for it, would you decide you didn’t have a performance problem?

My experiences with sexism

I don’t usually share this stuff, because I’m not thinking about it most of the time, but these things happened to me:

• I had a manager tell me I should stop writing code and focus on powerpoint and management, areas he found to be more in line with my talents. Was it because I’m a woman? I don’t know, but it does make me wonder how many women get pushed into management too soon, before they’ve had a chance to prove their technical chops.
• At one company, I had to change desks because people kept asking to schedule appointments with a VP who sat nearby. Even after changing, they would walk past two guys to ask me. Someone suggested hanging a sign, “I’m not a secretary.” I was in a new job and I just wanted to fit in and code cool stuff not hang signs announcing things. There were only three women out of hundreds of engineers on my floor.
• A guy whose opinions I usually trust said to me that he believes women’s brains are fundamentally different and that we aren’t wired to understand code. He then said I’m an exception because I’m smart, but I’m still doing something which is against my nature.
• I once had someone tell me:
  

  That guy only wants to work with you because he wants to sleep with you. None of your ideas are that interesting, I’m just saying, don’t get mad, it is the only possible explanation.

  Ow. I might never get over that one. It still stings a year later. I don’t want special privileges, but on the other hand, it is easy to see how I’m facing a special kind of discrimination that probably wouldn’t happen to a man. No one is going to assume that a man is on stage because he looks good in a skirt.

  Did the guy want to sleep with me? Maybe, we’re human and those sorts of things can come up. It isn’t a big deal. What bothers me is the notion that if he wants to sleep with me, he is completely incapable of evaluating the merit of my ideas. Thus, even if I am granted the privilege of working with him, it says nothing about my skill, intelligence, or capacity for original thought. It is all about my sexuality.

• All the ridiculous, but potent, self-doubt that goes along with being a woman-in-tech. I really am my own worst enemy. Maria Klawe calls it “impostor syndrome”.
• A client asked to have a male coworker on a call with me, though he was several years my junior.
• I was asked to speak at a conference. A guy whose talk was rejected said “you’re so famous, I wish I was a hot girl.”

Where have all the women gone?

I’m so sorry that rmurphey went through these things, and I’m very glad she stayed in the field because we are all better for it.

Maria Klawe also said that even the best women in a CS program are far more likely to drop out than the worst guys. When asked how they think they compare, these women consistently rank themselves far below their actual skill level. This means women aren’t good at judging their actual skill level or comparing themselves to others. They need mentors and a leg up, to help them do it. Women are also less likely to pester their boss until she finally relents to send them to a conference. Again, we need to actively invite talented women.

When Harvey Mudd changed their CS program admission criteria to accept a broader range of people, and stop selecting for the socially-challenged-uber-nerd, they found that everyone’s grades improved. It benefits everyone to have a diverse group of people in our field.

Jdalton, you had made some good points, but at this point I’m less impressed. Are you really claiming that gender discrimination doesn’t happen? What we have here is a complete failure to empathize.

And this is part of why it is great to meet Rebecca and other girl geeks. It is tiring to feel weird and stand out all the time. Ultimately, what we want is to stand out for the quality of our work. In order to do that, we need to eliminate some of the obvious gender inequities and find ways to rebalance the flow of new engineers. I believe this will make our products better, our work life better, and our conferences better. We have to be willing to really change things to make CS fit women better… it shouldn’t only be the women we are trying to change.

Getify, it sure helps, but it is only one small piece of a larger puzzle.