Pitfall #1 and Middle Ground
18 views
Skip to first unread message
Bill Burcham
Apr 1, 2009, 8:17:14 PM4/1/09
to Object Oriented CSS
Pitfall #1: Location Dependent Styles
From this philosophy sprouts many interesting outcomes. I've seen
Compass/SASS (with mixins) mentioned here and it's interesting to note
(as has also been noted in other threads on this group) that the
Compass folks actually promote Location Dependent Styles. See for
instance 16:11 into this talk: http://pivotallabs.com/talks/45 Eeek!
Chris Eppstein actually suggests copy/pasting your HAML (HTML
template) code into your SASS (CSS) code and using it as a starting
point! 1-1 HTML-CSS. That just seems so wrong.
On the other hand the SASS mixin approach which supports "Unobtrusive
CSS" has a really good smell to it.
I wonder if there is a middle ground to be had between the two
extremes?
From this philosophy sprouts many interesting outcomes. I've seen
Compass/SASS (with mixins) mentioned here and it's interesting to note
(as has also been noted in other threads on this group) that the
Compass folks actually promote Location Dependent Styles. See for
instance 16:11 into this talk: http://pivotallabs.com/talks/45 Eeek!
Chris Eppstein actually suggests copy/pasting your HAML (HTML
template) code into your SASS (CSS) code and using it as a starting
point! 1-1 HTML-CSS. That just seems so wrong.
On the other hand the SASS mixin approach which supports "Unobtrusive
CSS" has a really good smell to it.
I wonder if there is a middle ground to be had between the two
extremes?
Vincent Veselosky
Apr 2, 2009, 7:46:47 AM4/2/09
to object-or...@googlegroups.com
I'm not sure you would want to travel the middle of the road between
these, any more than you would want to drive on the double yellow
lines. My impression is that these are both useful approaches, but to
two different problems.
The Compass approach described in the presentation seems to be
targeted at the case where you have first constructed a site using
semantic HTML, and now you want to apply a style specific to that
site. It's about rapidly applying custom styles to pre-built pages and
sites. If you're a freelance designer with lots of small clients and
you make your living creating custom designs, the Compass approach
would probably be very useful for you.
The OOCSS approach seems to aim more for the inverse case, where you
want to create a style framework, and then later create content that
uses your style framework consistently. It's about rapidly creating
pages and sites that use pre-built styles. If you work in a large
organization with distributed content creation and need to maintain a
consistent look and feel across your site (or network of sites), then
the OOCSS approach would make your life much easier.
That said, Sass and even Compass are just tools. They have been
optimized for a certain case, but I could certainly see them,
especially Sass, being useful even if your design approach is more
OOCSS. If they add automatic sprite generation, I'd use the tool just
for that! :)
Vince Veselosky
Web: http://www.Webquills.net
Twitter: @veselosky (http://twitter.com/veselosky)
these, any more than you would want to drive on the double yellow
lines. My impression is that these are both useful approaches, but to
two different problems.
The Compass approach described in the presentation seems to be
targeted at the case where you have first constructed a site using
semantic HTML, and now you want to apply a style specific to that
site. It's about rapidly applying custom styles to pre-built pages and
sites. If you're a freelance designer with lots of small clients and
you make your living creating custom designs, the Compass approach
would probably be very useful for you.
The OOCSS approach seems to aim more for the inverse case, where you
want to create a style framework, and then later create content that
uses your style framework consistently. It's about rapidly creating
pages and sites that use pre-built styles. If you work in a large
organization with distributed content creation and need to maintain a
consistent look and feel across your site (or network of sites), then
the OOCSS approach would make your life much easier.
That said, Sass and even Compass are just tools. They have been
optimized for a certain case, but I could certainly see them,
especially Sass, being useful even if your design approach is more
OOCSS. If they add automatic sprite generation, I'd use the tool just
for that! :)
Vince Veselosky
Web: http://www.Webquills.net
Twitter: @veselosky (http://twitter.com/veselosky)
Bill Burcham
Apr 2, 2009, 10:22:44 AM4/2/09
to Object Oriented CSS
While it's true that SASS may have been developed by a freelancer and
OOCSS by a performance engineer at a large corporation, and I'm sure
those environmental differences influenced the designers, it does not
follow that SASS is best suited for freelancers and OOCSS for large
organizations.
Vince said:
> (OOCSS is) about rapidly creating pages and sites that use pre-built styles.
Both frameworks support this. Compass does with SASS mixins at the
expense of server-side simplicity and minimal CSS code size since it
requires a CSS preprocessor (SASS). OOCSS does it with vanilla CSS at
the expense of semantic markup since it requires non-semantic classes
on HTML elements.
In case anyone needs a reminder of how OOCSS necessitates non-semantic
markup, here's the grid example:
<div class="line">
<div class="unit size1of2">
<h3>1/2</h3>
<p>Lorem ipsum dolor sit amet...</p>
</div>
<div class="unit size1of2 lastUnit">
<h3>1/2</h3>
<p>Lorem ipsum dolor sit amet...</p>
</div>
</div>
There is nothing semantic about unit, size1of2 or lastUnit. This is a
violation of (part of) Best Practice #2: "Use consistent semantic
styles". It's consistent but it's not semantic.
It seems to me that if we were willing to relax Pitfall #1: "Location
dependent styles" and its dual Best Practice #9 "Extend objects by
applying multiple classes to an element" then a hybrid of OOCSS and
Compass could actually meet the rest of the requirements better than
OOCSS in its current form. In particular we'd have a better solution
to Best Practice #2: "Use consistent semantic styles". And it seems to
me everything else in OOCSS could be maintained as well.
The crux of my original question about middle ground stems from Chris
Eppsteins stated philosophy (apparent) of having an almost 1-1
correspondence between HTML elements and CSS rules. I don't think that
philosophy is inherent in SASS/Compass, it's just one (extreme) way of
applying SASS/Compass.
Similarly I don't think that OOCSS Pitfall #1/Best Practice #9 are
inherently necessary in OOCSS. I think those two can be removed and
what is left is a bunch of good stuff.
Imagine a hybrid: OOCSS implemented as SASS mixins in Compass. This
would effectively eliminate Pitfall #1/Best Practice #9. The benefit
would be stronger support for Best Practice #2.
At the same time I'd like to imagine that hybrid NOT promoting
proliferation of selectors beyond what is necessary to make up for the
loss of the non-semantic CSS classes. So we maintain Best Practice #6
"Minimize selectors" but we do so in such a way that we sustain Best
Practice #2. In short there are more selectors than we currently have
w/ OOCSS but we still strive to minimize them. The "two main
principles" of OOCSS remain intact (#1 separate structure and skin, #2
separate container and content).
And in the end you still have a library of reusable parts. It's just
that those parts are implemented as SASS mixins instead of CSS
classes. So a large organization or large community still benefits
from reuse. That's key.
Now at this point, the discussion is largely academic since most of
the actual CSS code for OOCSS on Github right now is resets and grid,
both of which are provided in roughly similar form by Compass right
now. But these issues will become germane once implementations for
blocks and content blocks and skins and such actually start to show up.
OOCSS by a performance engineer at a large corporation, and I'm sure
those environmental differences influenced the designers, it does not
follow that SASS is best suited for freelancers and OOCSS for large
organizations.
Vince said:
> (OOCSS is) about rapidly creating pages and sites that use pre-built styles.
Both frameworks support this. Compass does with SASS mixins at the
expense of server-side simplicity and minimal CSS code size since it
requires a CSS preprocessor (SASS). OOCSS does it with vanilla CSS at
the expense of semantic markup since it requires non-semantic classes
on HTML elements.
In case anyone needs a reminder of how OOCSS necessitates non-semantic
markup, here's the grid example:
<div class="line">
<div class="unit size1of2">
<h3>1/2</h3>
<p>Lorem ipsum dolor sit amet...</p>
</div>
<div class="unit size1of2 lastUnit">
<h3>1/2</h3>
<p>Lorem ipsum dolor sit amet...</p>
</div>
</div>
There is nothing semantic about unit, size1of2 or lastUnit. This is a
violation of (part of) Best Practice #2: "Use consistent semantic
styles". It's consistent but it's not semantic.
It seems to me that if we were willing to relax Pitfall #1: "Location
dependent styles" and its dual Best Practice #9 "Extend objects by
applying multiple classes to an element" then a hybrid of OOCSS and
Compass could actually meet the rest of the requirements better than
OOCSS in its current form. In particular we'd have a better solution
to Best Practice #2: "Use consistent semantic styles". And it seems to
me everything else in OOCSS could be maintained as well.
The crux of my original question about middle ground stems from Chris
Eppsteins stated philosophy (apparent) of having an almost 1-1
correspondence between HTML elements and CSS rules. I don't think that
philosophy is inherent in SASS/Compass, it's just one (extreme) way of
applying SASS/Compass.
Similarly I don't think that OOCSS Pitfall #1/Best Practice #9 are
inherently necessary in OOCSS. I think those two can be removed and
what is left is a bunch of good stuff.
Imagine a hybrid: OOCSS implemented as SASS mixins in Compass. This
would effectively eliminate Pitfall #1/Best Practice #9. The benefit
would be stronger support for Best Practice #2.
At the same time I'd like to imagine that hybrid NOT promoting
proliferation of selectors beyond what is necessary to make up for the
loss of the non-semantic CSS classes. So we maintain Best Practice #6
"Minimize selectors" but we do so in such a way that we sustain Best
Practice #2. In short there are more selectors than we currently have
w/ OOCSS but we still strive to minimize them. The "two main
principles" of OOCSS remain intact (#1 separate structure and skin, #2
separate container and content).
And in the end you still have a library of reusable parts. It's just
that those parts are implemented as SASS mixins instead of CSS
classes. So a large organization or large community still benefits
from reuse. That's key.
Now at this point, the discussion is largely academic since most of
the actual CSS code for OOCSS on Github right now is resets and grid,
both of which are provided in roughly similar form by Compass right
now. But these issues will become germane once implementations for
blocks and content blocks and skins and such actually start to show up.
Andrew Vit
Apr 2, 2009, 11:38:16 AM4/2/09
to Object Oriented CSS
Good points, Bill. I've been thinking about these different approaches
myself.
> Both frameworks support this. Compass does with SASS mixins at the
> expense of server-side simplicity and minimal CSS code size since it
> requires a CSS preprocessor (SASS). OOCSS does it with vanilla CSS at
> the expense of semantic markup since it requires non-semantic classes
> on HTML elements.
That's the key. It's about where it makes more sense to make these
compromises. OOCSS leaves you with a lot more markup, period, not just
unsemantic markup. The philosophy avoids modules which means you gain
predictability for what <li> looks like, but you need to set its class
everywhere you need to style <li> differently, even though it might be
in its own module that you'd otherwise target as a descendant
selector.
It's not quite as bad as font tags, but it still means there's a
proliferation of style-dependent classes on every element. On the
other hand, this is how all desktop page layout software (for print)
operates: if you want to style an element, you select that element and
apply a style. It's very direct and concrete.
> There is nothing semantic about unit, size1of2 or lastUnit. This is a
> violation of (part of) Best Practice #2: "Use consistent semantic
> styles". It's consistent but it's not semantic.
the video where Chris takes a chunk of markup, removes the content,
and then adds styles to the same structure, that's just a
demonstration of the syntactical similarity between Haml and Sass
which allows you to easily do that. It's a great starting point for
figuring out "what hooks do I have to style" but it's still up to you
the designer to realize that you'd end up over-specifying your
selectors and you still need to generalize & optimize from there...
> Imagine a hybrid: OOCSS implemented as SASS mixins in Compass. This
> would effectively eliminate Pitfall #1/Best Practice #9. The benefit
> would be stronger support for Best Practice #2.
Where are these numbers you're referring to? It seems I haven't read
the rulebook...
> At the same time I'd like to imagine that hybrid NOT promoting
> proliferation of selectors beyond what is necessary to make up for the
> loss of the non-semantic CSS classes. So we maintain Best Practice #6
> "Minimize selectors" but we do so in such a way that we sustain Best
> Practice #2. In short there are more selectors than we currently have
> w/ OOCSS but we still strive to minimize them. The "two main
> principles" of OOCSS remain intact (#1 separate structure and skin, #2
> separate container and content).
The key difference as I see it is OOCSS' rejection of modular
structure. While I like some of the ideas that OOCSS presents, I still
think there's a place for modules and reusing of elements for
different styles, if the modules are clearly defined.
The trouble with modules is nested content, (imagine sub-sub-modules)
where you'd need to override to cancel out the parent styles. This is
what Nicole's "lady who swallowed a fly" analogy is about, which I
think is a great one. The reality is that we're limiting ourselves to
a crippled CSS selector set due to IE6 and other older browsers when
we could be using direct child selectors to avoid these problems.
But, philosophically that means that you're connecting the structure
to the content, whether you intend to or not. (Maybe CSS needs to have
"private" attributes if we're seriously talking OO.)
> And in the end you still have a library of reusable parts. It's just
> that those parts are implemented as SASS mixins instead of CSS
> classes. So a large organization or large community still benefits
> from reuse. That's key.
I think the features of Sass/Compass are orthogonal and a superset of
OOCSS. You can still write your Sass with a flat structure, and use
mixins to avoid repeating common utility rulesets.
In the end it's (mostly) about how easy it is to maintain the content
and pages that your stylesheets apply to. I think I would find it
easier to apply a module class and leave the content to style itself
than to go around applying style classes to individual elements.
Also, it seems that OOCSS was born from performance optimization. If
the question were purely about CSS performance, then it makes sense
that the approach would not be optimal from other aspects. It makes
sense that you would need to add HTML selectors and flatten the CSS if
you have a super-complicated page that you need to speed up. But is
that how we want to have our HTML?
Andrew Vit
myself.
> Both frameworks support this. Compass does with SASS mixins at the
> expense of server-side simplicity and minimal CSS code size since it
> requires a CSS preprocessor (SASS). OOCSS does it with vanilla CSS at
> the expense of semantic markup since it requires non-semantic classes
> on HTML elements.
compromises. OOCSS leaves you with a lot more markup, period, not just
unsemantic markup. The philosophy avoids modules which means you gain
predictability for what <li> looks like, but you need to set its class
everywhere you need to style <li> differently, even though it might be
in its own module that you'd otherwise target as a descendant
selector.
It's not quite as bad as font tags, but it still means there's a
proliferation of style-dependent classes on every element. On the
other hand, this is how all desktop page layout software (for print)
operates: if you want to style an element, you select that element and
apply a style. It's very direct and concrete.
> There is nothing semantic about unit, size1of2 or lastUnit. This is a
> violation of (part of) Best Practice #2: "Use consistent semantic
> styles". It's consistent but it's not semantic.
> The crux of my original question about middle ground stems from Chris
> Eppsteins stated philosophy (apparent) of having an almost 1-1
> correspondence between HTML elements and CSS rules. I don't think that
> philosophy is inherent in SASS/Compass, it's just one (extreme) way of
> applying SASS/Compass.
I don't think that's necessarily a philosophy. If you're referring to
> Eppsteins stated philosophy (apparent) of having an almost 1-1
> correspondence between HTML elements and CSS rules. I don't think that
> philosophy is inherent in SASS/Compass, it's just one (extreme) way of
> applying SASS/Compass.
the video where Chris takes a chunk of markup, removes the content,
and then adds styles to the same structure, that's just a
demonstration of the syntactical similarity between Haml and Sass
which allows you to easily do that. It's a great starting point for
figuring out "what hooks do I have to style" but it's still up to you
the designer to realize that you'd end up over-specifying your
selectors and you still need to generalize & optimize from there...
> Imagine a hybrid: OOCSS implemented as SASS mixins in Compass. This
> would effectively eliminate Pitfall #1/Best Practice #9. The benefit
> would be stronger support for Best Practice #2.
the rulebook...
> At the same time I'd like to imagine that hybrid NOT promoting
> proliferation of selectors beyond what is necessary to make up for the
> loss of the non-semantic CSS classes. So we maintain Best Practice #6
> "Minimize selectors" but we do so in such a way that we sustain Best
> Practice #2. In short there are more selectors than we currently have
> w/ OOCSS but we still strive to minimize them. The "two main
> principles" of OOCSS remain intact (#1 separate structure and skin, #2
> separate container and content).
structure. While I like some of the ideas that OOCSS presents, I still
think there's a place for modules and reusing of elements for
different styles, if the modules are clearly defined.
The trouble with modules is nested content, (imagine sub-sub-modules)
where you'd need to override to cancel out the parent styles. This is
what Nicole's "lady who swallowed a fly" analogy is about, which I
think is a great one. The reality is that we're limiting ourselves to
a crippled CSS selector set due to IE6 and other older browsers when
we could be using direct child selectors to avoid these problems.
But, philosophically that means that you're connecting the structure
to the content, whether you intend to or not. (Maybe CSS needs to have
"private" attributes if we're seriously talking OO.)
> And in the end you still have a library of reusable parts. It's just
> that those parts are implemented as SASS mixins instead of CSS
> classes. So a large organization or large community still benefits
> from reuse. That's key.
OOCSS. You can still write your Sass with a flat structure, and use
mixins to avoid repeating common utility rulesets.
In the end it's (mostly) about how easy it is to maintain the content
and pages that your stylesheets apply to. I think I would find it
easier to apply a module class and leave the content to style itself
than to go around applying style classes to individual elements.
Also, it seems that OOCSS was born from performance optimization. If
the question were purely about CSS performance, then it makes sense
that the approach would not be optimal from other aspects. It makes
sense that you would need to add HTML selectors and flatten the CSS if
you have a super-complicated page that you need to speed up. But is
that how we want to have our HTML?
Andrew Vit
Jared Hirsch
Apr 2, 2009, 11:53:41 AM4/2/09
to object-or...@googlegroups.com
My (limited) understanding is that semantic markup
refers to marking up text so that the meaning of
html elements like 'p' and 'h1' coincides with their
use in the document. So, it's good semantic whatever
to enclose paragraphs in 'p' tags, and denote section
or chapter headings using 'h*' tags. But 'div' and
'span' are not semantic elements: they're structural
elements.
But I definitely see what you're saying; it's like
the problem of coming up with declarative names for
functions. A function should tell you, by its name,
what it does. Using function names like foo() isn't
super helpful to anyone, when you want names more
like isOpen() (for a database connection), or
alphabetize() (inside a sorting routine). It's funny
how such apparently minor stuff has such an effect.
--- On Thu, 4/2/09, Bill Burcham <bill.b...@gmail.com> wrote:
>
> In case anyone needs a reminder of how OOCSS necessitates
> non-semantic
> markup, here's the grid example:
>
> <div class="line">
> <div class="unit size1of2">
>
> <h3>1/2</h3>
> <p>Lorem ipsum
> dolor sit amet...</p>
> </div>
> <div class="unit size1of2
> lastUnit">
>
> <h3>1/2</h3>
> <p>Lorem ipsum
> dolor sit amet...</p>
> </div>
> </div>
>
> There is nothing semantic about unit, size1of2 or lastUnit.
> This is a
> violation of (part of) Best Practice #2: "Use consistent
> semantic
> styles". It's consistent but it's not semantic.
>
> This is a
> violation of (part of) Best Practice #2: "Use consistent
> semantic
> styles". It's consistent but it's not semantic.
>
> It seems to me that if we were willing to relax Pitfall #1:
> "Location
> dependent styles" and its dual Best Practice #9 "Extend
> objects by
> applying multiple classes to an element" then a hybrid of
> OOCSS and
> Compass could actually meet the rest of the requirements
> better than
> OOCSS in its current form. In particular we'd have a better
> solution
> to Best Practice #2: "Use consistent semantic styles". And
> it seems to
> me everything else in OOCSS could be maintained as well.
>
> "Location
> dependent styles" and its dual Best Practice #9 "Extend
> objects by
> applying multiple classes to an element" then a hybrid of
> OOCSS and
> Compass could actually meet the rest of the requirements
> better than
> OOCSS in its current form. In particular we'd have a better
> solution
> to Best Practice #2: "Use consistent semantic styles". And
> it seems to
> me everything else in OOCSS could be maintained as well.
>
> The crux of my original question about middle ground stems
> from Chris
> Eppsteins stated philosophy (apparent) of having an almost
> 1-1
> correspondence between HTML elements and CSS rules. I don't
> think that
> philosophy is inherent in SASS/Compass, it's just one
> (extreme) way of
> applying SASS/Compass.
>
> from Chris
> Eppsteins stated philosophy (apparent) of having an almost
> 1-1
> correspondence between HTML elements and CSS rules. I don't
> think that
> philosophy is inherent in SASS/Compass, it's just one
> (extreme) way of
> applying SASS/Compass.
>
> Similarly I don't think that OOCSS Pitfall #1/Best Practice
> #9 are
> inherently necessary in OOCSS. I think those two can be
> removed and
> what is left is a bunch of good stuff.
>
> #9 are
> inherently necessary in OOCSS. I think those two can be
> removed and
> what is left is a bunch of good stuff.
>
> Imagine a hybrid: OOCSS implemented as SASS mixins in
> Compass. This
> would effectively eliminate Pitfall #1/Best Practice #9.
> The benefit
> would be stronger support for Best Practice #2.
>
> Compass. This
> would effectively eliminate Pitfall #1/Best Practice #9.
> The benefit
> would be stronger support for Best Practice #2.
>
> At the same time I'd like to imagine that hybrid NOT
> promoting
> proliferation of selectors beyond what is necessary to make
> up for the
> loss of the non-semantic CSS classes. So we maintain Best
> Practice #6
> "Minimize selectors" but we do so in such a way that we
> sustain Best
> Practice #2. In short there are more selectors than we
> currently have
> w/ OOCSS but we still strive to minimize them. The "two
> main
> principles" of OOCSS remain intact (#1 separate structure
> and skin, #2
> separate container and content).
>
> promoting
> proliferation of selectors beyond what is necessary to make
> up for the
> loss of the non-semantic CSS classes. So we maintain Best
> Practice #6
> "Minimize selectors" but we do so in such a way that we
> sustain Best
> Practice #2. In short there are more selectors than we
> currently have
> w/ OOCSS but we still strive to minimize them. The "two
> main
> principles" of OOCSS remain intact (#1 separate structure
> and skin, #2
> separate container and content).
>
> And in the end you still have a library of reusable parts.
> It's just
> that those parts are implemented as SASS mixins instead of
> CSS
> classes. So a large organization or large community still
> benefits
> from reuse. That's key.
>
> It's just
> that those parts are implemented as SASS mixins instead of
> CSS
> classes. So a large organization or large community still
> benefits
> from reuse. That's key.
>
Andrew Vit
Apr 2, 2009, 12:12:55 PM4/2/09
to Object Oriented CSS
It's not just about names... it's about inheritance too.
Where OOCSS seems more like a procedural language with a flat
namespace, the modular approach lets us call something 'h3' and it
would know what to do by inheritance from its place in the markup. In
that regard, maybe OOCSS isn't such a descriptive name.
Andrew Vit
On Apr 2, 8:53 am, Jared Hirsch <jaredhir...@yahoo.com> wrote:
> My (limited) understanding is that semantic markup
> refers to marking up text so that the meaning of
> html elements like 'p' and 'h1' coincides with their
> use in the document. So, it's good semantic whatever
> to enclose paragraphs in 'p' tags, and denote section
> or chapter headings using 'h*' tags. But 'div' and
> 'span' are not semantic elements: they're structural
> elements.
>
> But I definitely see what you're saying; it's like
> the problem of coming up with declarative names for
> functions. A function should tell you, by its name,
> what it does. Using function names like foo() isn't
> super helpful to anyone, when you want names more
> like isOpen() (for a database connection), or
> alphabetize() (inside a sorting routine). It's funny
> how such apparently minor stuff has such an effect.
>
Where OOCSS seems more like a procedural language with a flat
namespace, the modular approach lets us call something 'h3' and it
would know what to do by inheritance from its place in the markup. In
that regard, maybe OOCSS isn't such a descriptive name.
Andrew Vit
On Apr 2, 8:53 am, Jared Hirsch <jaredhir...@yahoo.com> wrote:
> My (limited) understanding is that semantic markup
> refers to marking up text so that the meaning of
> html elements like 'p' and 'h1' coincides with their
> use in the document. So, it's good semantic whatever
> to enclose paragraphs in 'p' tags, and denote section
> or chapter headings using 'h*' tags. But 'div' and
> 'span' are not semantic elements: they're structural
> elements.
>
> But I definitely see what you're saying; it's like
> the problem of coming up with declarative names for
> functions. A function should tell you, by its name,
> what it does. Using function names like foo() isn't
> super helpful to anyone, when you want names more
> like isOpen() (for a database connection), or
> alphabetize() (inside a sorting routine). It's funny
> how such apparently minor stuff has such an effect.
>
Nicole Sullivan
Apr 2, 2009, 12:22:04 PM4/2/09
to Object Oriented CSS
I know we spend a lot of time worrying about ending up with class-ML,
but frankly we should worry more about whether we are applying the
class to the correct object. To me, applying the class to the actual
<ul> rather than some upper wrapper is *advanced semantics*. A hybrid
approach will make you crazy (even on a small site), if you are
applying classes to everything than your defaults aren't very good.
Specific and semantic are not the same thing. I can call something:
engine
wheeledVehicle
modeOfTransport
motorcycle
italianMotorcycle
Ducati
DucatiMonster620darkOwnedByNicoleDrivenLastSaturday
All of the above are semantic. Granted the last one is much much more
specific, so specific that one would almost never find a use case that
fit it semantically. If you try to be overly specific with your names
people will use them in semantically incorrect ways. I don't think
that's better. We need to step back and make our classes more
abstract so that they fit a wider variety of cases.
Keep in mind, when choosing classes in the library/framework, I can't
make them semantic because they aren't being used for anything (it's a
framework!). If you want to take template.css and change .leftCol
to .navigation, please do. Just be aware that then you are limiting
yourself to putting only navigation in that column, or your semantics
are useless.
I've not spent a lot of time with SASS/Compass, but some of it it
seems like something thing I've been working on (last few slides of
the OOCSS slidedeck). I'm not keen on the bits that simply change the
CSS syntax to something else (one more thing to learn!). On the other
hand, the idea of proper support for extending objects sounds fab. You
_could_ do this on the server side, sure, but you'll end up sending
way more bytes over the wire. Multiple classes is clearly a
compromise, I want real inheritance. Browser vendors will do this one
day.
but frankly we should worry more about whether we are applying the
class to the correct object. To me, applying the class to the actual
<ul> rather than some upper wrapper is *advanced semantics*. A hybrid
approach will make you crazy (even on a small site), if you are
applying classes to everything than your defaults aren't very good.
Specific and semantic are not the same thing. I can call something:
engine
wheeledVehicle
modeOfTransport
motorcycle
italianMotorcycle
Ducati
DucatiMonster620darkOwnedByNicoleDrivenLastSaturday
All of the above are semantic. Granted the last one is much much more
specific, so specific that one would almost never find a use case that
fit it semantically. If you try to be overly specific with your names
people will use them in semantically incorrect ways. I don't think
that's better. We need to step back and make our classes more
abstract so that they fit a wider variety of cases.
Keep in mind, when choosing classes in the library/framework, I can't
make them semantic because they aren't being used for anything (it's a
framework!). If you want to take template.css and change .leftCol
to .navigation, please do. Just be aware that then you are limiting
yourself to putting only navigation in that column, or your semantics
are useless.
I've not spent a lot of time with SASS/Compass, but some of it it
seems like something thing I've been working on (last few slides of
the OOCSS slidedeck). I'm not keen on the bits that simply change the
CSS syntax to something else (one more thing to learn!). On the other
hand, the idea of proper support for extending objects sounds fab. You
_could_ do this on the server side, sure, but you'll end up sending
way more bytes over the wire. Multiple classes is clearly a
compromise, I want real inheritance. Browser vendors will do this one
day.
Bill Burcham
Apr 2, 2009, 1:02:07 PM4/2/09
to object-or...@googlegroups.com
On the bytes-on-the-wire issue I'll parrot what I've heard Eppstein say: that if you serve up your CSS gzipped then you would expect much of that bloat to go away (on the wire at least). Yes, when it lands on the browser, it'll still be bigger (perhaps).
OTOH it'd be interesting to compare apples-to-apples on the actual code size. Just as a quickie: I looked at caring.com (Eppstein's production site which uses Compass) with groups.yahoo.com (dunno if this site embodies any of The Principles, but it's a Yahoo! property at least) and linkedin.com (which is purportedly a YUI site, but not necessarily an OOCSS one).
Granted, LinkedIn is by necessity probably much more complex than caring.com since the former is an application and the latter is a more static site. groups.yahoo.com probably falls somewhere in-between.
A quick visual glance at the three sites CSS came up w/ something like this:
(site) (LoC)
caring.com 2.6K
groups.yahoo.com 1.1K
linkedin.com 2.4K
Would caring.com be 1/3 the size with class-based reuse instead of SASS mixins? I don't know. It is tempting to theorize though, that the (in the browser) size of the CSS might be reduced by a factor of 2 or so by using OOCSS and in turn that it might be important for performance in some cases.
On the other hand the CSS at caring.com may be a lot more compressible than the CSS at linkedin.com (due to the redundancy in caring.com's CSS). So on the wire it may not be an issue at all.
If you're running a big site or family of sites like Yahoo! the on the wire issue may be the most important and the in-the-browser issue may only become important when performance is inadequate (in the browser).
Chris Eppstein
Apr 8, 2009, 6:17:39 PM4/8/09
to Object Oriented CSS
I guess it's time that I weigh in on this wonderful thread.
First, let me say that Sass is an alternate syntax for writing CSS and
it has an embedded scripting language called SassScript that enables
us to do some pretty neat things. Sass does not have a philosophy
other than it does acknowledge that scoped selectors are not DRY in
normal CSS and it attempts to optimize for this very common case using
indentation. The discussion of the language design choices of Sass is
one I'd love to host over at the haml mailing list if anyone is
wanting to dig into that issue. Suffice it to say that I don't think
I've ever used a language where it 100% matches my desires for syntax
-- but sometimes they get pretty darn close and give me tools I never
have had before so I get over it. In other cases, the syntax has grown
on me and in time, I learn to prefer it.
Similarly, Compass has a philosophy that a designer/programmer knows
best what classes and ids should be used in their markup and is
focused on providing style reuse from frameworks without the loss of
that control through the power of sass mixins. My talk at pivotal labs
was trying to show how style bleed from one designed page on your site
could be avoided when building new pages by being specific in your
selectors and refactoring them for generality as a product matures.
This is the case of Compass supporting a best practice, not enforcing
it.
I'm still learning about OOCSS, but if there's some feature that's
required of compass to enable it to be a vehicle for people to use
OOCSS more effectively, then I'm willing to make those changes. One
could think of Compass and Sass as a way of implementing OOCSS and
using it to generate releases of standard CSS files, while
simultaneously allowing more advanced users to use the libraries
directly in their compass projects.
Last night, I put together a proof of concept for the OOCSS grid.
Here's the sass file:
http://github.com/chriseppstein/compass/blob/61891d538f6128f0dafe54ad07afc22a4be62f21/frameworks/oocss/stylesheets/oocss/_grids.sass
And here's the output by mixing in +grids into a sass file:
http://gist.github.com/91663
I'd rather not maintain another framework as part of compass, so in an
ideal world, I would help Nicole get her own compass plugin for OOCSS
up and running, if she wants to go down that path.
I will do more research and reading on OOCSS so that I can see
understand the philosophy of it and how it could best work as a
compass/sass plugin. Hopefully, it will expose any missing features of
compass as well -- I'm pushing for a 1.0 release in the coming months.
Lastly, while we're wishing for browser features, I'll throw mine into
the ring: <style type="text/sass">
Cheers,
Chris
First, let me say that Sass is an alternate syntax for writing CSS and
it has an embedded scripting language called SassScript that enables
us to do some pretty neat things. Sass does not have a philosophy
other than it does acknowledge that scoped selectors are not DRY in
normal CSS and it attempts to optimize for this very common case using
indentation. The discussion of the language design choices of Sass is
one I'd love to host over at the haml mailing list if anyone is
wanting to dig into that issue. Suffice it to say that I don't think
I've ever used a language where it 100% matches my desires for syntax
-- but sometimes they get pretty darn close and give me tools I never
have had before so I get over it. In other cases, the syntax has grown
on me and in time, I learn to prefer it.
Similarly, Compass has a philosophy that a designer/programmer knows
best what classes and ids should be used in their markup and is
focused on providing style reuse from frameworks without the loss of
that control through the power of sass mixins. My talk at pivotal labs
was trying to show how style bleed from one designed page on your site
could be avoided when building new pages by being specific in your
selectors and refactoring them for generality as a product matures.
This is the case of Compass supporting a best practice, not enforcing
it.
I'm still learning about OOCSS, but if there's some feature that's
required of compass to enable it to be a vehicle for people to use
OOCSS more effectively, then I'm willing to make those changes. One
could think of Compass and Sass as a way of implementing OOCSS and
using it to generate releases of standard CSS files, while
simultaneously allowing more advanced users to use the libraries
directly in their compass projects.
Last night, I put together a proof of concept for the OOCSS grid.
Here's the sass file:
http://github.com/chriseppstein/compass/blob/61891d538f6128f0dafe54ad07afc22a4be62f21/frameworks/oocss/stylesheets/oocss/_grids.sass
And here's the output by mixing in +grids into a sass file:
http://gist.github.com/91663
I'd rather not maintain another framework as part of compass, so in an
ideal world, I would help Nicole get her own compass plugin for OOCSS
up and running, if she wants to go down that path.
I will do more research and reading on OOCSS so that I can see
understand the philosophy of it and how it could best work as a
compass/sass plugin. Hopefully, it will expose any missing features of
compass as well -- I'm pushing for a 1.0 release in the coming months.
Lastly, while we're wishing for browser features, I'll throw mine into
the ring: <style type="text/sass">
Cheers,
Chris
Reply all
Reply to author
Forward
0 new messages