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.

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.

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.

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

I recently went to New York to hang with some people who are interested in HTML5 and figure out what I thought about the future of this web standard. I’m a skeptic by nature, so I went into our little quest expecting to be unimpressed by HTML5, but in fact, it isn’t so bad, and even has a few additions I’m excited about.

Down with Pseudocode!

On the other hand the spec itself drives me crazy because I feel like pseudocode is a poor substitute for properly and clearly stating what you are trying to achieve. It is easy to mask your agenda in pseudocode and harder for people to sort out later what was intentional versus incidental.

#html5 .pseudo-code { display: none;} Thought experiments don’t belong in a spec & pseudocode can’t replace properly specifying requirements.

@stubbornella

Yahoo! Developer Network has released a video of my Object Oriented CSS talk at Web Directions North just in time for Ada Lovelace day. I’ve also been included in a feature on Women in Technology. I’m absolutely flattered to be included among these fantastic technical women. Wow.

Object Oriented CSS: for high performance websites and web applications.

Find out more about object oriented css

1. Open source project on github (GIT is having some DNS issues, be patient)
2. Follow along with the slides on slideshare
3. Join the OOCSS google group

My Object Oriented CSS grids and templates are open sourced on github. They have all the functionality of YUI grids plus some important features.

• Only 4kb, half the size of YUI grids. (I was totally happy when I checked the final size!)
• They allow infinite nesting and stacking.
• The only change required to use any of the objects is to place it in the HTML, there are no changes to other places in the DOM and no location dependent styling. Eases back-end development and makes it a lot easier to manage for newbies.
• Solution for sub-pixel rounding errors.

http://wiki.github.com/stubbornella/oocss

template.css and grids.css

…My prediction is that you’ll be writing complex layouts in less than 24 hours without adding a line to the CSS file.

I visited Yahoo! last week to record a talk I had given at the Front End Summit in October. If you are a designer or an F2E it is essential that you understand the ways in which design choices impact overall site performance. This talk establishes guidelines for High Performance Design including 9 Best Practices.

9 Best Practices

1. Create a component library of smart objects.
2. Use consistent semantic styles.
3. Design modules to be transparent on the inside.
4. Optimize images and sprites.
5. Avoid non-standard browser fonts.
6. Use columns rather than rows.
7. Choose your bling carefully.
8. Be flexible.
9. Learn to love grids.

Web Directions North, Denver, February 2-7

I’ll be speaking more about Design and also CSS best practices at Web Directions North in February where I’ve been invited to give both a Performance Bootcamp Workshop and a CSS Performance for Websites and Web Apps Presentation. I look forward to seeing you there!

80% des problèmes de performance Web se situe au niveau des échanges avec le navigateur et sur le navigateur lui-même : échanges réseau, rendu dans le navigateur, organisation des composants dans une page etc.

Nous aborderons les principales problématiques et les solutions à mettre en œuvre. Forts de l’expérience de l’équipe performance de Yahoo!, à la fin de cette session vous saurez aborder la question des performances Web du point de vue du visiteur et mettre en œuvre les actions correctrices sur vos sites Web.

Je vais parler (en francais! eek!) avec Eric Daspet de la performance des images pour le web a ParisWeb. Les inscriptions pour Paris Web 2008 sont officiellement ouvertes. Jusqu’au 15 octobre au soir, vous bénéficierez de tarifs réduits. Le conference sera lieu a Paris le 13-15 Novembre. J’attend vous voir bientot alors.

Voila le proposition

Voulez-vous améliorer la vitesse de vos pages web et réduire l’impact écologique et monétaire de votre hébergement ? Voulez-vous faire ceci avec peu de changement de code et en gardant une belle interface graphique ? Cette session va vous apprendre les 7 étapes pour mettre votre site web au régime. Comment perdre des poids que votre site a pris en rajoutant les dernières nouveautés. Et, encore plus important, comment ne pas reprendre ce poids !

The Web Standards Curriculum published by Opera is a great place to start. It will give you the basics of Front-end Engineering from the ground up. The second wave of articles was recently published including a background image and sprites how-to by yours truly.

Time to board a plane, so I can’t tell you more just now, but check it out. It is a great place to get started or brush up on your understanding of web standards.

My Treo stopped syncing in January and I immediately started missing all my meetings. I need the device to ring every few seconds to remind me to blink and breathe, so life without a properly synced agenda was awful — just ask my colleagues. Guppy brain.

A Palm user for the past eight years, I made the switch to an iPhone 3G a few weeks ago. I’ve had one palm or another since I was gifted an S300 and became (shockingly) a productive member of society. I vaguely want to give the iPhone a fair shot, aware that my bias toward familiarity is inevitable, however there are a few things about the iPhone that totally and completely suck.

The YUI team released YUI3 for a sneak peek preview. The goals make me happy… especially goal 2.

1. lighter (less K-weight on the wire and on the page for most uses)
2. faster (fewer http requests, less code to write and compile, more efficient code)
3. more consistent (common naming, event signatures, and widget APIs throughout the library)
4. more powerful (do more with less implementation code)
5. more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)