OOCSS Performance Stats

[Rachael L Moore]

I'm going through the list archives, stubbornella's SlideShares,
oocss.org, and stubbornella's blog.

One thing I can't find much of is before and after stats regarding CSS
& HTML filesize, page render time, etc. And real life case-studies.

I'm convinced that any trade-off is generally worthwhile, based on non-
OOCSS specific information about performance and my own prior
experiences with maintainability nightmares. Unfortunately, I often
find myself talking in circles when I discuss it with others.

There are 3 major objections I encounter:

(1) You increase the weight of your HTML with OOCSS, which is a more
important performance metric than selectors. You add demonstrable,
repeated bytes to HTML in the form of classes for a possible 100ms
improvement in rendering time.

I'm having a hard time responding to this. It seems true enough on
the surface. It also seems to be ignoring a lot of other pertinent
benefits, but the conversation keeps coming back to it.

I've seen stubbornella's presentation about Facebook cutting their
response time in half and about the overwhelming amount of
repetition. Was OOCSS alone the cause of this improvement?

I've seen http://screwlewse.com/2010/08/different-css-techniques-and-their-performance/
which shows OOCSS is clearly better than repetitive CSS. But that
comes back to the idea that improved CSS performance is negligible
compared to page weight.

Is there any information out there that shows the respective sizes of
CSS and HTML before/after using OOCSS and demonstrates there is still
an overall performance gain?

I'd like to get others' perspectives, opinions, experiences, and links
if possible. I've gathered up about 20 so far, but OOCSS-specific and
friendly content is pretty bare.

(PS: The other objections are (2) the class names are presentational,
which violates separation of concerns and (3) you have to change your
HTML to change (some of) your styles, which violates separation of
concerns. These go around in circles just as much, but currently I'm
more concerned with what can be objectively measured.)

[xckpd7]

To your other objections, there is no such thing as complete
separation of HTML & CSS. Yes with the coming of CSS, we were promised
that you'd never have to change your html, and you could mark up a
page semantically and target it reliably with CSS. Anyone who has ever
developed a site knows this clearly isn't the case... even with
CSSZengarden (which clearly had an influence on the popularity of CSS)
they had to add classes and extra containers on their entire markup
for it to be skinned by other people. If you think about it, the ID's
and classes you are putting at the parent level are already
unsemantic, which is why people have moved to frameworks and grid
systems to do what we already know we have to do, but in a clean and
modular fashion. You still want to be as semantic as possible with
markup that makes sense without classes, and you still don't want to
put a class on everything, but as far as the other points they are
outdated IMO.

To performance I think everyone's numbers will be different... clearly
the bigger the project and the longer it has proceeded without modular
css / OOCSS, the more lines of code, the more the duplication, and so
on. It's very easy to repeat code, but with OOCSS you really are
forced to look at your current code and start cutting down... I think
in general working on big projects will net you performance gains
almost undoubtedly, but I think what is really of concern here is more
maintainable code, with the side benefit of performance.

On Sep 30, 1:34 pm, Rachael L Moore <more...@gmail.com> wrote:
> I'm going through the list archives, stubbornella's SlideShares,
> oocss.org, and stubbornella's blog.
>
> One thing I can't find much of is before and after stats regarding CSS
> & HTML filesize, page render time, etc. And real life case-studies.
>
> I'm convinced that any trade-off is generally worthwhile, based on non-
> OOCSS specific information about performance and my own prior
> experiences with maintainability nightmares.  Unfortunately, I often
> find myself talking in circles when I discuss it with others.
>
> There are 3 major objections I encounter:
>
> (1) You increase the weight of your HTML with OOCSS, which is a more
> important performance metric than selectors.  You add demonstrable,
> repeated bytes to HTML in the form of classes for a possible 100ms
> improvement in rendering time.
>
> I'm having a hard time responding to this.  It seems true enough on
> the surface.  It also seems to be ignoring a lot of other pertinent
> benefits, but the conversation keeps coming back to it.
>
> I've seen stubbornella's presentation about Facebook cutting their
> response time in half and about the overwhelming amount of
> repetition.  Was OOCSS alone the cause of this improvement?
>

> I've seenhttp://screwlewse.com/2010/08/different-css-techniques-and-their-perf...

[Jos Hirth]

1. In my experience a structured approach (even if it looks somewhat
verbose) will actually yield markup and CSS which is more compact -
even with really tiny sites. It's kinda counter intuitive. I think the
reason is a) that all of your markup serves a very specific purpose
(nothing is there just in case) and thus can be easier reused, b) gzip
can take care of repetition easily, and c) there will be less cruft,
because it's easier to identify it as such.

2. Presentational classes don't necessarily conflict with separation
of concerns. There is a big difference between markup from templates
and your actual content. Your templates are only there for
presentational reasons. Furthermore, you can always change them
easily. If you do a complete redesign, you typically will change them
anyways. Using presentational classes is perfectly fine there.

However, it shouldn't get too fine grained. You don't want to attach
dozens of classes to one element. That would be like using inline
styles, just less convenient. You also might want to keep your class
names somewhat generic to make minor changes less irritating.

The markup of the content should of course be always completely
semantic and as pure as possible. Once there are hundreds of pages in
dozens of languages, you simply will not be able to change it. (Of
course this is only true if the markup of your content isn't the
result of some transformation, in which case you could actually change
it easily whenever you want.)

Always think about what you're trying to separate and why you're doing
it in first place. There should be reasons and not just some "golden
rules" you blindly follow.

3. Yes, if you want to optimize reuse, you'll need a usable template
engine. But that's more of technical detail of the underlying
architecture which drives the site. Again, this is a place where trade-
offs can be made. You don't necessarily need precise control down to
every leaf.

On Sep 30, 7:34 pm, Rachael L Moore <more...@gmail.com> wrote:
> I'm going through the list archives, stubbornella's SlideShares,
> oocss.org, and stubbornella's blog.
>
> One thing I can't find much of is before and after stats regarding CSS
> & HTML filesize, page render time, etc. And real life case-studies.
>
> I'm convinced that any trade-off is generally worthwhile, based on non-
> OOCSS specific information about performance and my own prior
> experiences with maintainability nightmares.  Unfortunately, I often
> find myself talking in circles when I discuss it with others.
>
> There are 3 major objections I encounter:
>
> (1) You increase the weight of your HTML with OOCSS, which is a more
> important performance metric than selectors.  You add demonstrable,
> repeated bytes to HTML in the form of classes for a possible 100ms
> improvement in rendering time.
>
> I'm having a hard time responding to this.  It seems true enough on
> the surface.  It also seems to be ignoring a lot of other pertinent
> benefits, but the conversation keeps coming back to it.
>
> I've seen stubbornella's presentation about Facebook cutting their
> response time in half and about the overwhelming amount of
> repetition.  Was OOCSS alone the cause of this improvement?
>

> I've seenhttp://screwlewse.com/2010/08/different-css-techniques-and-their-perf...

[Aeron Glemann]

> but as far as the other points they are outdated IMO.

If anything I think the reverse is happening. The SMF (https://github.com/stubbornella/oocss/wiki/Standard-Module-Format) is outdated:

<b class="top"><b class="tl"></b><b class="tr"></b></b>

etc... If you are willing to sacrifice ie6 and add some javascript to polyfill the newer ie browsers, you can do so much more with css3 than you ever could with css2. IMO the trends show with each browser iteration it is becoming less necessary to break the separation of concerns.

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To post to this group, send email to object-or...@googlegroups.com.
To unsubscribe from this group, send email to object-oriented...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.

[Aeron Glemann]

> Presentational classes don't necessarily conflict with separation of concerns. 

> There is a big difference between markup from templates and your actual content.

So the way I've interpreted this (in my OOCSS implementation) is the "presentational" classes I use are really an extension of the existing HTML tags. A <P> will always be a <P> regardless of how it looks. The same holds true for the other tags. Once you give it a semantic class name ".legal-text" suddenly you've lost the ability to re-use the presentation - unless you happen to have some more "legal-text" somewhere.

So what I try to do is extend the existing HTML/UI tags with both more granular and additional classes. So when choosing a name, instead of asking "what is the content here" (the semantic approach) I ask "what is the UI function here" (my OOCSS way).

In the majority of cases a lot just comes down to importance. You have strong/em to indicate text that is more important (but strangely no "understated" to indicate text that is de-emphasized) and different levels of importance for the headings. But you can also have more important buttons, menus, etc.. Importance can be determined from the wireframe by how close an element is to the top of the page and it's size, or from a mockup by it's color/contrast. People use names like "primary" button or "sub" menu to denote importance, but I like the simplicity of the h1, h2, h3 approach. 

Then you can have additional UI elements that do not currently exist in HTML like "ratings" or "badges" or "pagination" etc..

Anyway, the result if a taxonomy that is not presentational, but also not semantic in the traditional sense of semantic CSS.

I'd be curious to hear what other approaches people have come up with.

[Rachael L Moore]

Thanks to all the responses so far -- but I already agree with you.

I've made the same arguments. Unfortunately, they are not effectual
where I need them most. That is why I am looking for objective
evidence in the form of stats, case studies, and example sites.

@Jos
Thank you also for mentioning repetition & gzip. It's not a number,
but it's still a good point.

@Aeron
It's my opinion that the separation of concerns is...somewhat
illusory, or somewhat backwards, when it comes to "updating the design
with CSS alone without changing the HTML." Sure, there's stuff like
the Zen Garden, no HTML is changing there. But it's a proof of
concept, not anything like any site I've ever worked on. I remember
an interview where Dave Shea mentioned that in order to maintain the
Garden, it became impossible to change the HTML. Which is precisely
my point--that's not the real world. In the real world it's both
necessary and unavoidable to add to or change the HTML sometimes.
This causes (a) more CSS to be written and (b) existing CSS to be
rewritten. It creates a demonstrably inefficient, unintended
dependency between the markup and the style. I mean, come on, why is
it any *more* desirable to rewrite 9,000 lines of stuff like:
"#homepage > section:last-child .module.module-specific div >
article:last-child"?

Furthermore, I've never been a part of a major redesign that didn't
rewrite most/all of the HTML [usually accompanied by same
protestations Nicole addressed at the beginning of "Our Best Practices
are Killing Us" -- "...THIS time..."]. As the saying goes, the
definition of insanity is doing the same thing over and over and
expecting different results. Maybe that's less true with technology,
which moves so fast! :-) But that's what comes to mind for me in
respect to maintainability and OOCSS.

- Rachael

[Rachael L Moore]

@Aeron
I'm investigating it for a template system where the bulk of the HTML
cannot be changed by front end devs, designers, or content authors.

So my approach is a little bit of both. I try to identify visual
patterns that would benefit from abstraction into classes and then use
those alongside more 'semantic' class names. This can mean more
classes, actually, than the OOCSS framework would call for by itself.

I also use more classes than I did prior to exposure to OOCSS. I have
nothing but good things to say about adding predictability and clarity
to my selectors.

The h1-h6 approach for headings doesn't really work for me, however,
so for most cases I classes and treat them as part of the objects. It
matches my mental model better.

Currently I'm trying to architect the CSS as OOCSS, but apply it using
SASS's @extend rather than directly in the HTML. I'm curious as to
how it will perform and maintain when it hits critical mass.

I'm still trying to work out the balance. Another reason I need more
information about others' implementations :-D

- Rachael

[Chris Eppstein]

My experience with @extend using OOCSS-style construction is that it
works great with simple classes, but if you have complex selectors the
output bloat can get pretty bad; you have to be sure to watch your
file size like a hawk. I discuss this in further detail at the bottom
of my most recent blog post: http://chriseppstein.github.com/blog/2011/08/21/responsive-layouts-with-sass/

- Chris Eppstein

[Aeron Glemann]

> The h1-h6 approach for headings doesn't really work for me, however,
> so for most cases I classes and treat them as part of the objects.  It
> matches my mental model better.

I'd love some examples. If you don't stay very abstract it's really easy to slip into presentational-ish names. In my case the issue is not that the HTML cannot be changed, just that it needs to be shared by 4+ sites with very distinct brands. So the HTML really cannot describe presentation at all, beyond the very high-level UI function of a particular piece of HTML.

[Aeron Glemann]

In our case as well... @extend was our original approach. Really seemed to combine the best of both worlds.. the two biggest problems were 

1) In order to use @extend all your CSS has to be in "scope" so that pretty much excludes being able to have multiple stylesheets.. 

For example, the best approach to balancing requests vs size/caching is to have 3 stylesheets: one that encapsulates framework-level stuff - your normalization rules, grids, etc - that can be re-used across sites and rarely ever changes; one that encapsulates site-level stuff - all your default rules, and stuff like header/footer that also will rarely change and applies to most or all pages of the site; and one for rules specific to a certain page. In order to use @extend that would all have to be a single stylesheet/request since the page-level stuff probably extends the site-level stuff and framework-level stuff. That wasn't desired in our particular case.

2) File-size as Chris mentions. 

And things got out of control really fast. Every level of inheritance can have an exponential effect on the size of your CSS. You definitely need to approach it differently than traditional OO-style programming where inheritance is a freebie and the more abstraction the better. 

@extend was a brilliant implementation - a perfect hack - but seems very limited in actual use-cases so far in our experience. Definitely need to keep campaigning for a "native" browser @extend: Tweet

Our second approach was to use traditional OOCSS but we quickly realized that wouldn't allow us the flexibility over the presentation that we required - I've mentioned that before, both in regard to the branding issues and responsive mobile/tablet layouts.

The approach we settled on was the traditional SASS approach - extensive use of Mixins/Functions/Variables - allows us to abstract our re-usable code while maintaining the highest degree of flexibility with the smallest file-size. We still use some OOCSS style classes, but at a very high-level. For example a ".button" or ".rating" or ".badge" will not change what it is across brands/devices whereas as ".button2.button-condensed.icon-left.icon16-cart" just makes too many assumptions about how a UI bit must look.

[John Slegers]

My experience with OOCSS, SMACSS or however you want to call modular CSS is this :

* You may need two to three classes extra in your HTML to define the layout of a certain UI element, but it can significantly reduce your overall CSS across your page if you organise your code well and design your UI elements well. 

* If you need more than three classes for a single UI element, consider using an ID or semantic class instead. You shouldn't use presentational helper classes for everything. For optimal design, compare the amount of CSS you need when using generic presentational classes with the amount of CSS you need when using an ID or semantic class. Pick the one with the least CSS when the difference is significant and the one with the least HTML if the difference is small.

* Often, the optimal result is a hybrid of presentational classes for commonly shared generic behavior (eg. navigation) and ID based or semantic class based styles for UI element specific behavior (eg. styles specific for a single navigation element).