Stubbornella - Nicole Sullivan

Styling headings is either a deceptively complex problem, or maybe the design of CSS made it appear complex when it need not have done.

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 in the HTML. It also changes the way browsers and assistive technologies are meant to interpret those headings. For that reason, we’ve got to revisit how we style headings. The old way simply won’t work anymore!

It is a subtle difference, but 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}

Learn how this can go awry and a better way of styling headings.

Nicholas Zakas and I spoke at Velocity a few minutes ago. First we talked about CSS 3 and it’s impact on performance, then we demoed and open sourced CSS Lint! I really couldn’t be more excited (or relieved, I was super duper nervous before this presentation).

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.

I am so very pleased to announce that Nicholas Zakas and I are joining forces to form a consulting duo. Nicholas has spent the last five years defining what it meant to to be a client-side engineer at Yahoo!. He consistently raised the client-side glass ceiling with his commitment to good code and practical solutions. He also literally wrote the book on JavaScript Performance. Like me, Nicholas cares deeply about performance and scalability. And, most importantly, we share a love of finding elegant solutions to hard problems, which we feel makes us a good match.

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

Here is the video of my talk at Webstock 2011.

CSS 3 is full of ways to reduce our dependence on background images, one of which is pure CSS gradients. They have several features, which I’m sure designers are salivating over, like multiple color stops, and angled, radial, and linear gradients. Many people had built cool designer-focused tools to make interacting with a somewhat confusing gradient syntax a little easier. The issue for me has been that I’m not a designer. I generally work off of photoshop comps or (when doing big re-architecture projects) the site itself, as if the old version were a design. This means that, for the most part, I was trying desperately to match CSS gradients to an image with zero information about how that image would have been created. Because of my focus on fixing old and broken CSS, the original designer may not even still work at the company.

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.

Interested in Performance and scaling sites to a large number of visitors or pages? I just realized both Steve Souders and I will be giving talks at Webstock next week! This is a pretty amazing opportunity to massively increase your Performance mojo in one go.

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!

CSS grids can improve performance? How so?

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.

Everyone keeps asking me what is with all the “x” in the OOCSS grids… so I finally wrote an article. The short answer is that it isn’t just a clearfix (it does that too), but it also causes the element to stretch wide, even when it has very little content. It is a bit of magic that allows us to use display table-cell to create a new formatting context in all browsers. It also allows us to solve sub-pixel rounding errors without resorting to fixed widths. (This has all kinds of great perf benefits because the grids are nestable and stackable).

  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 ";
}

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

Usually I avoid topics like women in technology because (1) it is a can of worms, and (2) I can really only speak for myself. For the most part, I’d rather be seen as a person in technology than a woman, but this weekend the twitterverse erupted with opinions about Google sponsoring female students to attend JSConf. As a woman who is often the only-woman-in-the-room, I want people to know it isn’t always easy. I was a bit shocked by the blatant failure to empathize.

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.

Multitasking has been stressing me, robbing me of my focus, my productivity, and my appreciation of the beauty of the exact moment I’m experiencing right now, and dammit, I want my brain back!

Once upon a time, I was assigned 21 projects in my first month on a job. Distinct projects, working with different groups of people on completely different tasks. I went from writing code 95% of the time to running from meeting to meeting.

At the same time, I installed IM at work and didn’t create a separate work account (I can see this clearly now, but at the time, I was just filling out my HR profile, I didn’t see the significance). The lines became blurry and I started to get pings around the clock from both work and friends. This is in part due to “crazy-round-world-syndrome”. My life is international, that’s okay, but it does make boundaries harder.

Perhaps it really began as early as 2000, when I got my first cell phone and lived with it glued to my ear? Getting an iphone in January of 2007 certainly made it worse because as a device my precious is meant to be petted, not simply used to accomplish other tasks more efficiently.

So what does a good geek do? Gather data.

I gathered data from scientific american, psychology today, read research papers, took a mindfullness course, and read links that friends posted to twitter.

Last week, Stoyan Stefanov and I spoke at Velocity Conference about optimizing massive CSS. We talked about our experiences optimizing large-scale sites like Facebook and Yahoo!, and we discussed our findings regarding the CSS efficiency of the Alexa Top 1000 websites.

Velocity was kind enough to share videos of the session.

What is the state of the internet regarding CSS performance? Kind of sad. We aren’t getting a lot of the basics right, and when we look at the more advanced techniques, there are some spectacular examples of what-not-to-do. Why do we care about CSS performance? As Stoyan talks about in the beginning of the video, it blocks progressive rendering and it is very difficult to auto-minify.

What is the internet made of? At least the UI layer is mainly composed of media blocks. I talked about the Facebook stream story before, and all the tiny objects of which it is composed. For the most part, the stream story is made up of the media object repeated over and over.

The media object is an image to the left, with descriptive content to the right, like this Facebook story:

It is a very simple object, but it is very powerful. We can eliminate many lines of code abstracting this repeating pattern. The code for the media block and many other “web Lego” are available on the Object Oriented CSS open source project.

In my previous post, I said:

Shoehorning CSS and HTML into PHP abstractions prevents the code from being DRY and ultimately leads to code bloat, because, the CSS and HTML require a far more granular object structure than the PHP.

And then I didn’t expand on it, or give proper context. Ooops, sorry!

In the PHP layer, the following stream story (from facebook) might be a single object. All of the logic of determining which bits of HTML to show or hide are contained within one object structure.

Frequently, developers try to make the CSS match this middle-end logic. We expect all the CSS code for the stream story to be sand-boxed within a wrapper id, for example #story. This ends up with bloated code that isn’t DRY. Why? because the proper architecture for the CSS layer is much more granular. Trying to base the CSS architecture on the PHP layer is something akin to trying to use the DB schema to configure apache. It just doesn’t work.

Each layer in the web stack has its own architecture. You wouldn’t expect the DB schema to be used to architect the PHP middleware, and yet people expect that of the HTML and CSS. HTML needs to be written with a sense of the meaning of the data or content, something I call code semantics. Code semantics are incredibly important in the HTML for both portability and accessibility. On the other hand, CSS really is a separate layer in the stack, and it needs its own architecture that reflects the visual semantics of the page.

Visual semantics describe all the repeating patterns in the design of the page. They represent the fundamental building blocks of your website. In fact, they are often portable across sites with only minor modifications. Visual semantics shouldn’t necessarily be tied to HTML semantics, because you want an architecture that fits the unique requirements of each layer of the stack…

Don’t get me wrong, I think CSS is awesome. It is a great way of defining the UI, but it could be even better. I’m excited about the special effects, transitions, and graphic elements currently being added to the CSS specification. They will help us write faster pages by eliminating the need for UI graphics for things like rounded corners. On the other hand, we also need to add structure to the language to make it easier for designers and developers to author new pages and applications. I hope the CSS Working Group will consider my suggestions.

Suggestions for the CSS Working Group

The community has been talking about some form of constants or variables in different incarnations for almost a decade, it is time to make this a reality. While it is possible to duplicate this functionality with a preprocessor (an excellent stop gap until browser support catches up), ultimately this is a tool which should live within the CSS itself. It is a powerful way of expressing more about the objects we are building.

The mixins and prototypes (and associated includes and extends properties) are designed to allow document authors to abstract reusable bits of code and better manage and maintain their style sheets. The goal is to mimic the effect of using multiple class names in the HTML without the drawbacks associated with current implementations. Authors need extends and include in order to write faster, smaller, more efficient style sheets.

CSS is a powerful expressive language. It needs certain modifications so that it will be robust, maintainable, and easy to implement.

From JSConf.eu