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...