Object Oriented CSS

170 views
Skip to first unread message

capi etheriel

unread,
Dec 12, 2010, 2:27:35 PM12/12/10
to compas...@googlegroups.com
I was working on a theme and thought it could be skinnable. so i wrote:

.-block-skin { padding: 1em 0; }
.-block-skin-header { font-size: 1.3em; }
.-block-skin-content { color: #333; }

and then i had my beautiful markup classes extend .-block-skin

.block {
  @extend .-block-skin;
  .title { @extend .-block-skin-header; }
  .body { @extend .-block-skin-content; }
}

but then i thought: wouldn't this be more interesting if .-block-skin-header and .-block-skin-content were nested inside .block-skin?

.-block-skin { 
  padding: 1em 0;
  .header { font-size: 1.3em; }
  .content { color: #333; } }

since they are nested, there's no need to write long class names like .block-skin-header but the problem is now i can't write the @extend properties as i could before:

.block {
  @extend .-block-skin;
  .title { @extend .-block-skin .header; }
  .body { @extend .-block-skin .content; }
}

this problem exists solely because i don't want to change the markup. i am compiling stylesheets after all, it shouldn't matter whether the child element is .header, .title, .h, .widget-title, whatever. maybe sass/compass should have a way to map this extensibility. may be it already has. am i missing something?

Nathan Weizenbaum

unread,
Dec 13, 2010, 3:31:04 PM12/13/10
to compas...@googlegroups.com
The reason we don't allow extending nested selectors is that "@extend A" means "style this as though it matched A", and matching ".-block-skin .header" is almost the same as just matching ".header", while being a very confusing distinction.

I think what you actually want to do is something like this:

.block {
  @extend .-block-skin;
  .title { @extend .header; }
  .body { @extend .content; }
}

This will work as expected.

- Nathan

--
You received this message because you are subscribed to the Google Groups "Compass" group.
To post to this group, send email to compas...@googlegroups.com.
To unsubscribe from this group, send email to compass-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/compass-users?hl=en.

capi etheriel

unread,
Dec 13, 2010, 11:43:56 PM12/13/10
to compas...@googlegroups.com
-block-skin {

  padding: 1em 0;
  .header { font-size: 1.3em; }
  .content { color: #333; } }

.block {
  @extend .-block-skin;
  .title { @extend .header; }
  .body { @extend .content; }
}

this works, but gives me tons of useless selectors...
-capi

Nathan Weizenbaum

unread,
Dec 14, 2010, 12:53:28 AM12/14/10
to compas...@googlegroups.com
This is an unfortunate side-effect of having base classes that you aren't actually using in your markup. In Sass 3.1, we'll have a facility for marking selectors as being only for @extend, which should clear up the unwanted selectors.

capi etheriel

unread,
Dec 14, 2010, 7:48:53 AM12/14/10
to compas...@googlegroups.com
heaven is always on the next version.

capi etheriel

unread,
Apr 28, 2011, 1:13:51 PM4/28/11
to compas...@googlegroups.com
sass 3.1 is out! did feature make it?

scott davis

unread,
Apr 28, 2011, 1:29:43 PM4/28/11
to compas...@googlegroups.com
Object Oriented CSS is more of a practice then a feature im confused to what you were expecting

On Thu, Apr 28, 2011 at 1:13 PM, capi etheriel <barra...@gmail.com> wrote:
sass 3.1 is out! did feature make it?

--

capi etheriel

unread,
Apr 28, 2011, 2:34:01 PM4/28/11
to compas...@googlegroups.com
Let's say the client sends me a pic from patterntap and asks me to build such a menu. In a quick glance, I can see the navbar is a list so i write css as if I knew the markup:

.-nihongoup-navbar-menu {
  @include inline-block-list;
  background-color: black; padding-top: .5em; }

.-nihongoup-navbar-item:hover {
  @include border-radius: 5px 5px 0 0;
  background-color: white; }

And so on. But then the developer finally gives me access to the markup, generated by his framework. If it is semantic it might be an html5 <nav> element, if it is just good it will be a <ul> and <li> elements, but it might be a set of <div> elements. Of course, I'd rather rewrite the markup, but let's say I don't want or just can't. I can write a selector that works and then extend it:

ul.menu-class-the-framework-thinks-is-clever {
  @extend .-nihongoup-navbar-menu; }

ul.menu-class-the-framework-thinks-is-clever > li {
  @extend .-nihongoup-navbar-item; }

Now this second @extend rule will printout several classes. Now you might have noticed I named the extendable classes with a starting dot and hiphen. I did it to prevent clashing with any other class in the markup -- I really don't trust the framework nor the future mantainers of this code. But wouldn't it be wonderful if I could tell the extendable classes they shouldn't be printed in the css file?

This is something I hope gets implemented soon. I didn't find anything in SASS 3.1 Reference file.

Chris Eppstein

unread,
Apr 28, 2011, 2:43:55 PM4/28/11
to compas...@googlegroups.com
no we did not yet add this feature to Sass. But I want it too. I think we decided it will be called @silent:

@silent {
  .-nihongoup-navbar-menu {
    @include inline-block-list;
    background-color: black; padding-top: .5em;
  }

  .-nihongoup-navbar-item:hover {
    @include border-radius: 5px 5px 0 0;
    background-color: white;
  }
}

What do you think of that syntax?

--

capi etheriel

unread,
Apr 28, 2011, 2:59:01 PM4/28/11
to compas...@googlegroups.com
Filenames starting with an underscore prevents it from generating output, instead of being imported.

I believe if i import a file like that, its classes shouldn't be printed out. Thus I have this skin file _nihongoup-skin.scss and import it in my screen.scss, which maps the selectors to the skin classes. What do you think about it?

It's how I did it in Compass Drupal Plugin: skin files and base theme files (which makes a lot of sense in drupal). As a bonus, the skin files can be shared with several projects -- i can think of a Wordpress theme importing a skin file meant for Drupal and just mapping into it.

Eric Meyer

unread,
Apr 28, 2011, 3:00:30 PM4/28/11
to compas...@googlegroups.com
would

@silent .object {
  property: value;
}

also work? or would it have to objects nested inside @silent?

Chris Eppstein

unread,
Apr 28, 2011, 3:41:08 PM4/28/11
to compas...@googlegroups.com
The current thinking requires nesting under @silent. But it's not built yet ;)

Mathias Schopmans

unread,
Apr 28, 2011, 7:17:47 PM4/28/11
to Compass
I would prefer this syntax instead of nesting multiple classes under a
single @silent.

Would love to use it in the next release. :)

Mathias Schopmans

unread,
Apr 28, 2011, 7:23:59 PM4/28/11
to Compass
Output will be printed, where I place the @silent classes, right?

Nathan Weizenbaum

unread,
Apr 28, 2011, 7:48:36 PM4/28/11
to compas...@googlegroups.com
Putting @silent in front of individual selectors is contrary to how existing structures in CSS (e.g. @media) work.

Chris Eppstein

unread,
Apr 28, 2011, 8:18:04 PM4/28/11
to compas...@googlegroups.com
Yes. But that you (who understands the feature) had to ask worries me. Maybe @silent is misleading/not descriptive enough?

Hunt & pecked on my iPhone... Sorry if it's brief!

On Apr 28, 2011, at 4:23 PM, Mathias Schopmans <mat...@schopmans.me> wrote:

> Output will be printed, where I place the @silent classes, right?
>

Eric Meyer

unread,
Apr 28, 2011, 8:24:59 PM4/28/11
to compas...@googlegroups.com
I see. The strange thing about the proposed syntax is that I don't want all that code to be "silent". I only want the *selector* to be silent. So I don't see it as comparable to media queries. I see it more like mixins, and so a more mixin-like syntax. Hmmm.

Mario "Kuroir" Ricalde

unread,
Apr 28, 2011, 8:26:09 PM4/28/11
to compas...@googlegroups.com
This is meant to be used with @extend right?

I use the synatx .ext-something

-- 
Mario "Kuroir" Ricalde
+1 ‪(415) 800-415-4‬

On Thursday, April 28, 2011 at 7:24 PM, Eric Meyer wrote:

I see. The strange thing about the proposed syntax is that I don't want all that code to be "silent". I only want the *selector* to be silent. So I don't see it as comparable to media queries. I see it more like mixins, and so a more mixin-like syntax. Hmmm.

--

Chris Eppstein

unread,
Apr 28, 2011, 8:32:40 PM4/28/11
to compas...@googlegroups.com
Yes. You can extend it and the base class is not in the output. 


Hunt & pecked on my iPhone... Sorry if it's brief!

Yaohan Chen

unread,
Apr 28, 2011, 8:55:53 PM4/28/11
to compas...@googlegroups.com
I am probably missing something. What does using @silent and @extend
offer over a mixin? And in general, why should one @extend one
selector in another, instead of just defining a mixin and including it
in both selectors?

Mario "Kuroir" Ricalde

unread,
Apr 28, 2011, 8:58:01 PM4/28/11
to compas...@googlegroups.com
Why not just do a prefix based ignore?

For instance, I use .ext- prefix to anything that is meant to work as an extension; so I usually have:

.ext-sprite {} for instance

and then @extend .ext-sprite; 

This could solve the ordeal, and there's no need to have a @shady syntax

-- 
Mario "Kuroir" Ricalde
+1 ‪(415) 800-415-4‬

Mario "Kuroir" Ricalde

unread,
Apr 28, 2011, 9:00:20 PM4/28/11
to compas...@googlegroups.com
Simple: When you do mixin, you're adding the contents of that mixin to the given selector. So you're basically adding statements (repeating the code).

Extends on the other hand instead of "inserting" the contents; it just shares it's attributes (hence .selector1, .selector2)

-- 
Mario "Kuroir" Ricalde
+1 ‪(415) 800-415-4‬

Yaohan Chen

unread,
Apr 28, 2011, 9:13:41 PM4/28/11
to compas...@googlegroups.com
Ah, then for any use case of @silent, you could just use a mixin
instead of a "silent" selector? Maybe the intention is for a Sass
stylesheet using actual selectors to be reusable, but I think the
better approach is to write the reusable parts of the stylesheets as
mixins while defining default selectors which include them.

Also why don't mixins use the same behavior as @extend? For example it
could store the first selector which includes any mixin, and treat any
other selectors including the same mixin as@extending the first
selector. I've also thought it would be nice to have something to
automatically refactor Sass-output CSS files to minimize repetition of
styles.

On Thu, Apr 28, 2011 at 9:00 PM, Mario "Kuroir" Ricalde

Mario "Kuroir" Ricalde

unread,
Apr 28, 2011, 9:15:58 PM4/28/11
to compas...@googlegroups.com
@Yaochan: @mixin is good as it is; because sometimes is not a good solution to use @extend.

Back into the original topic please:

Why not just do a prefix based ignore?

For instance, I use .ext- prefix to anything that is meant to work as an extension; so I usually have:

.ext-sprite {} for instance

and then @extend .ext-sprite; 

This could solve the ordeal, and there's no need to have a @shady syntax
-- 
Mario "Kuroir" Ricalde
+1 ‪(415) 800-415-4‬

Nathan Weizenbaum

unread,
Apr 28, 2011, 9:36:36 PM4/28/11
to compas...@googlegroups.com
A prefix is very arbitrary. There's no way for something reading the code who's not familiar with the feature to look at ".ext-sprite" and understand that ".ext-" has a meaning for Sass, and isn't some sort of naming convention. Using @-rule syntax explicitly calls out the fact that something unusual is going on.

We've also thought about @private and @abstract rather than @silent, but we want to reserve the former for a potential module system, and the latter seems unlikely to mean anything to anyone who hasn't had experience with Java-style programming.

Mario "Kuroir" Ricalde

unread,
Apr 29, 2011, 1:12:56 AM4/29/11
to compas...@googlegroups.com
Nathan; I understand the problem with conventions. But think about this: we use them already on compiling files.

For instance we have "_file.scss" which won't get compiled but can be included. Anyone who's not familiar with the feature to look at "_file.scss" has no idea what it does.

That brings.. why don't we do it via. Which is basically a class (without the dot); meaning it's not usable in the DOM since you'll never have that generated ! 

_my-abstract {
color:red;
}

.something { @extend _my-abstract; }

-- 
Mario "Kuroir" Ricalde
+1 ‪(415) 800-415-4‬

Mario "Kuroir" Ricalde

unread,
Apr 29, 2011, 1:14:21 AM4/29/11
to compas...@googlegroups.com
My bad, I mean "why don't we do it via undescore prefixing".

-- 
Mario "Kuroir" Ricalde
+1 ‪(415) 800-415-4‬

Steve Schwarz

unread,
Apr 29, 2011, 8:49:14 AM4/29/11
to compas...@googlegroups.com
On Fri, Apr 29, 2011 at 12:12 AM, Mario "Kuroir" Ricalde <kur...@gmail.com> wrote:
Nathan; I understand the problem with conventions. But think about this: we use them already on compiling files.

For instance we have "_file.scss" which won't get compiled but can be included. Anyone who's not familiar with the feature to look at "_file.scss" has no idea what it does.

That brings.. why don't we do it via. Which is basically a class (without the dot); meaning it's not usable in the DOM since you'll never have that generated ! 

_my-abstract {
color:red;
}

.something { @extend _my-abstract; }

+1 I like the symmetry with the file naming convention.

Best Regards,
Steve
http://tech.agilitynerd.com/

Glenn McLelland

unread,
Apr 29, 2011, 9:01:27 AM4/29/11
to compas...@googlegroups.com
sounds good to me too
-gmclelland

Chris Eppstein

unread,
Apr 29, 2011, 9:34:44 AM4/29/11
to compas...@googlegroups.com
It's a clever idea, but it violates our "CSS Superset" rule: legal css syntax must produce itself as output. Since these are valid classnames in CSS, it's a non-starter. This feature will most certainly be built with an @-rule for symmetry with CSS semantics and @extend.

One idea we had was to eventually allow for retroactive silencing of base classes. This could be useful for importing existing CSS libraries and making them more "semantic" with @extend. The syntax for this would be more like:

    @silent .clearfix;

and it would make .clearfix silent everywhere. But we decided to hold off on this until we have a scoping/module system because, with @extend, we already see that it sometimes ends up extending classes that you didn't plan on it extending. But when this happens, it could allow for a glob syntax that supports declarative conventions:

    @silent ._*;

And that file is not a legal css file so it doesn't have the superset problem and it is explicit so it doesn't have as big of a learning curve (you know you have to figure out what it means when you see it).

chris

Tony Adams

unread,
Apr 29, 2011, 3:45:04 PM4/29/11
to Compass
What about something like @extend-only or @extendable.

Mario "Kuroir" Ricalde

unread,
Apr 29, 2011, 7:57:55 PM4/29/11
to compas...@googlegroups.com
It would be awesome if you allowed the user to define patterns to exclude selectors; so the person can define how they want to exclude:

@silent .ext-*;

.ext-sprite {}

scott davis

unread,
Apr 29, 2011, 10:54:48 PM4/29/11
to compas...@googlegroups.com
having a custom defined css pattern per projects is -100 from me you will end up with extensions that make your stylesheets an epic mess. what ever decided it needs to be forced from a language level

capi etheriel

unread,
Apr 30, 2011, 12:42:20 PM4/30/11
to compas...@googlegroups.com
chris, why don't we negate any output from underscored files?

If I write down a _styles.scss I don't expect a styles.css file being generated from it.
If I import a _styles.scss file, why should it output anything? it should only provide me the mixins and classes to extend, but not print out anything by itself.

Is my proposal clear? As an added bonus, it doesn't add anything to the syntax, yet uses a SASS/Compass feature we are already used to.

Mario "Kuroir" Ricalde

unread,
Apr 30, 2011, 1:07:34 PM4/30/11
to compas...@googlegroups.com
That idea completely kills the objective of sass. Having segmented and organized code in one compiled css file :( no good.

-- 
Mario "Kuroir" Ricalde
+1 ‪(415) 800-415-4‬
--

Ştefan Schipor

unread,
Apr 30, 2011, 2:16:25 PM4/30/11
to compas...@googlegroups.com
The syntax Chris suggested would be awesome enough for me ( @silent {  .object-from-my-library { ... }  }   .augmented-obj { @extend ... }  ) 

Hope you'll implement this kind of stuff soon :)


Cheers,

Stef

Mathias Schopmans

unread,
May 1, 2011, 5:18:24 PM5/1/11
to Compass
pro single silent per selector:

// base heading - silent
@silent .h {
font-size: 22px;
font-family: Arial;
text-transform: uppercase;
other …
}

h1 {
@extend .h
}

//H2 and silent "H2-Style"
h2, @silent .h2 {
@extend .h;
font-size: 16px;
line-height: 0.9em;
}

// now think of a span with this class
.stupid-plugin .my-unchangeable-markup {
@extend .h2;
}

a mixin would produce unnecessary duplicate code
Message has been deleted

Nathan Weizenbaum

unread,
May 2, 2011, 4:10:29 PM5/2/11
to compas...@googlegroups.com
This is doable right now by doing "@extend h2".

Mathias Schopmans

unread,
May 3, 2011, 9:33:44 AM5/3/11
to Compass
Oh great. I thougt only classes are extendable.

On 2 Mai, 22:10, Nathan Weizenbaum <nex...@gmail.com> wrote:
> This is doable right now by doing "@extend h2".
>
Reply all
Reply to author
Forward
0 new messages