<a>, <p>, <span> tags inside modules.

[Hopper Jules]

Say you have a module and it has a couple of <p> tags within it and
you like to change the padding on those <p> tags. Should you put a
class, like .pam, ( padding all medium ) on each of <p> tags within
the module? Or should you do something like this:

.mod p{
padding: 10px;
}

Same thing goes for changing default float or borders for a <p> tag
within a module. What is the best practice to do that as well.

Thanks so much,
Ryan

[Aeron Glemann]

Maybe this is helpful:

https://github.com/stubbornella/oocss/wiki/FAQ

The bit under "The OOCSS approach says avoid location-dependent styles..."

HTH -Aeron

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

[Hopper Jules]

Thanks Aeron,

I have already went over that a couple of times before posting here.
I'm just looking at the correct way to do what I described above. If
someone could spell it out for me, that would be awesome.

I think the documentation could be much more clear in this aspect and
others.

Ryan

[erik.f...@googlemail.com]

Hi Hopper,

this one is pretty common. It would simply be impractical to add a
class to EVERY <p> tag inside your module. In an ideal world, we would
not have to change the behaviour of an element when it's placed in a
different context, we would rather extend it to stay flexible. But as
I said, we have to deal with what we got. I would make the decision
based on the amount of <p>, <a> and <span> tags inside your module. If
you have one (or maybe two), add classes. However, if you have a
theoretically unlimited number of tags (if the field has dynamic
content, i.e. the editor can write a lot of paragraphs and make a lot
of different links), it's best to couple the selectors like
.myMod p {color: green;}

Just be aware that this adds a bit of complexity to your object since
it will now change EVERY p to that color. This isn't necessarily bad,
just be aware. What I do when I encounter this is to introduce
formatting classes, like so

.formatAside p {color: red};
.formatAside a {color: blue;}

This way I can still (de-)couple the format very easily by either
adding or removing it as a whole, as say <div class="mod myMod
formatAside">. Removing it puts everything back to normal, and I stay
flexible with the granularity (i.e. I can apply it to the .ft if I
only need that format for the footer, not the whole module).

Hope that helps,
Erik

P.S. Please, don't name your class pam (padding all medium)! This is a
presentational class name. Avoid that, since your class name does
reflect on how the element should look. If you would later decide to
also change the color of every o.pam and instead of the padding add
margin, your class name would add a lot of confusion. Use non-
presentational class names instead ;)

[Aeron Glemann]

Uh... the ".pam" (padding all medium) is right out of the framework's own space.css:

https://github.com/stubbornella/oocss/blob/master/core/spacing/space.css

That whole stylesheet was such a mistake...

[Hopper Jules]

Wow this is exactly what I was looking for. Thank you!

You mentioned that you should not use something like .pan. I'm a
little confused. That is in @stubornella's OCCSS spaces.css github
repo, so I assume using it is correct??

Any help is greatly appreciated,
Hopper

On May 12, 12:13 pm, "erik.fris...@googlemail.com"

[Aeron Glemann]

I think the other important issue is the separation of content from presentation. Classing *every* object - as the FAQ suggests - couples the presentation way too closely with the content. In most websites the people doing the content are not the same people doing the presentation. They shouldn't need to know at all about how the content will be displayed, just that it is formatted semantically. The website definitely needs the flexibility to put that content into different containers and for the content to look differently depending on where it is (summaries, sidebars, intros, lists, articles, sections, etc).

I think the FAQ is wrong in saying "A good rule of thumb is that anything within the body of a container is clearly a separate object." (uh, that's everything). A container should have defaults for the content objects inside of it. Then those objects can be extended with different presentation as needed. But clearly *every* <p> inside of a container should not need a class for presentation.

On Thu, May 12, 2011 at 10:13 AM, erik.f...@googlemail.com <erik.f...@googlemail.com> wrote:

[erik.f...@googlemail.com]

Hi Hopper,

.pam is indeed from the space.css (sorry for that). But as it says in
the comments, use *judiciously*! These styles are really just for
people with a pixel-perfection disorder. Most of the time setting good
defaults will spare you of having to use these styles (I never use
them, but then again, I was lucky to be able to educate my clients out
of pixel-perfectness).

Everything in CSS is a compromise. We don't want to use non-semantic
classes (like .pam, as it refers to presentation), but if we want
pixel perfection that breaks the defaults, the best way to go is to
write a set of default classes which affect margins and paddings. I
think this was the intention behind the styles. They are an exception
to the rule with a sniper-like use case, so don't wander around
thinking it's ok to write a .bigRedHeading. There is a special kind of
hell for this (a hell where you have to do pixel-perfect designs in
EVERY browser, including IE6 ;)

@Aeron:
I hear you. The stylesheet is confusing. It's hard to teach how to
compromise, that's a skill best obtained by experience. But the
stylesheet nonetheless demonstrates that there are use cases out there
that directly contradict the best practices. Being required to push a
certain block "just 3 more pixels down" despite the rythm and the
defaults is one of those use cases.
But I agree, the FAQ should be more clear on this issue. The rule of
thumb is pretty general. What would you suggest as a better way to
phrase it?

Cheers,
Erik

[Evan Winslow]

FWIW, we went with a similar approach.  You don't class each <p>, but instead use a "sandbox" class (or several classes) for styling content in various ways.  Erik calls them "format" classes.  Same difference.  Legalized location-dependent styling, I guess :).

[Nicole Sullivan]

Point well taken that the documentation could be better.

Container objects are like donuts and the body is like the donut hole, what I mean is that they have a beginning and an end node. You never want styles to spill from the container to the content through the body (this is far more important than how semantic your class names may be). 

If you only need to change padding, use spacing classes. If you find yourself using them on *every* p, then the defaults are probably set wrong.

If you want to change other things, like link color, make a specialized type of link. Yes, that means adding a class to the link, but that is the only way to make it reusable. The beauty is that you make one, and you can reuse it forever. If you tied it to your container, you could never make use of it anywhere else. For the most part, if you change the way something looks/behaves it should be by adding a class to the element itself. 

Container objects make that a little confusing because they have multiple nodes that all belong to the same object. So it is perfectly fine to style inner from mod like this because inner and mod are nodes of the same object:

.myMod .inner{border:1px solid red;}

On the other hand you would never want to do this:

.myMod p{border: 1px solid red;}

because p is not a node of the module object. You don't want to let any styles bleed through the body.

Of course this means you end up with extra (admittedly annoying) classes in your HTML, but it is a worthwhile trade-off for the flexibility/reusability/predictability you get.

Content objects are a different story because they do not have a body, so you don't need to worry about style pass-through. 

Nicole

--

Nicole Sullivan

Object Oriented CSS  http://wiki.github.com/stubbornella/oocss

Smush it  http://smush.it

Website  http://stubbornella.org

Tweet!  http://twitter.com/stubbornella

Book  Even Faster Websites with O'Reilly

[Nicole Sullivan]

I did something similar on a site that had some parts of the page in black on white and other parts in white on black. I could have made a separate library of objects for each area, but I realized that the objects really had no overlap because of contrast issues, so instead I created a class .invert which caused the objects to display in the inverted color scheme. The only things I allowed myself to change within the invert class is colors. Otherwise, I wanted the objects to behave consistently across the entire site.

Nicole

On May 12, 2011, at 11:39 AM, Evan Winslow wrote:

FWIW, we went with a similar approach.  You don't class each <p>, but instead use a "sandbox" class (or several classes) for styling content in various ways.  Erik calls them "format" classes.  Same difference.  Legalized location-dependent styling, I guess :).

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

[erik.f...@googlemail.com]

Hi Nicole,

I think this comes down to how practical this approach is. Adding a
class to every <p> to make it reusable is not always an option,
especially if the content can be edited by an editor by means of an
RTE. You would either have to teach the editor to always select the
correct class for each paragraph, or parse the HTML he creates and add
the classes programmatically. Both are not very practical, and the
latter is time consuming. Bleeding the styles through from container
to content is.
And sometimes location-dependent styles are just that: location
dependent. If all <p> tags within a side column have an 11px margin,
not 12px as per default, I *could* write a separate class for that.
But that would in effect be the same as using something like .pam on
every <p>. And my chances of explaining to someone else when to use
that 11px class I wrote are pretty low, because this is simply
location dependent. A "sandbox" or format class seems like the more
reasonable way to go in these situations - you get the best of both
worlds by introducing a new type of skin element.

In the end the importance lies on decoupling content from container as
much as possible. If you want maximum flexibility, you add a class to
every element. Whether or not that is always practical is a different
issue IMHO.

Cheers,
Erik

On May 12, 8:40 pm, Nicole Sullivan <nic...@stubbornella.org> wrote:
>
> because p is not a node of the module object. You don't want to let any styles bleed through the body.
>
> Of course this means you end up with extra (admittedly annoying) classes in your HTML, but it is a worthwhile trade-off for the flexibility/reusability/predictability you get.
>
>
>
>
>
>
>
>
>

> > For more options, visit this group athttp://groups.google.com/group/object-oriented-css?hl=en.

[David Snopek]

Hi Everyone!

I just want to add another example for "location-dependent" styles.

What if the data is entered by users, ie: forum posts. In the main
content area of the page, you show teasers of the most recent posts.
But in the right sidebar, you show teasers of "hot" posts. Some of
the ones in the body and the sidebar could be exactly the same (if a
post is both recent and "hot"). But in the sidebar you want the
font-size to smaller.

In this case, having different HTML for body and sidebar is extra
impractical. You don't want to parse and modify the HTML or require
the users to enter their posts multiple times.

In my opinion, basic document formatting tags (which users will be
entering into the system, either by hand or with a WYSIWYG editor)
should sometimes be exceptions to passing style from module to body.

I liked the "format classes" discussed above. That way you can keep
the specificity of all your location dependent styling the same. Ie.
Rather than saying "#right-sidebar p" you would always add a module
class that does it (ex. ".smallerMod p"). It's a half-way compromise
solution.

Regards,
David.

2011/5/12 erik.f...@googlemail.com <erik.f...@googlemail.com>:

--
Blog: http://www.linguatrek.com
Product: http://www.bibliobird.com

[Aeron Glemann]

Hi Nicole!

On Thu, May 12, 2011 at 12:40 PM, Nicole Sullivan <nic...@stubbornella.org> wrote:

On the other hand you would never want to do this:

.myMod p{border: 1px solid red;}

because p is not a node of the module object. You don't want to let any styles bleed through the body.

Of course this means you end up with extra (admittedly annoying) classes in your HTML, but it is a worthwhile trade-off for the flexibility/reusability/predictability you get.

Content objects are a different story because they do not have a body, so you don't need to worry about style pass-through. 

The only time content objects can be styled as you describe is when they're not part of the content, but part of the template. Or you're writing your content by hand, in your markup.

[Aeron Glemann]

On Thu, May 12, 2011 at 1:17 PM, David Snopek <dsn...@gmail.com> wrote:

 

I liked the "format classes" discussed above.  That way you can keep
the specificity of all your location dependent styling the same.  Ie.
Rather than saying "#right-sidebar p" you would always add a module
class that does it (ex. ".smallerMod p").  

Hm, "format classes" really sounds like presentational classes, and that's exactly what they look like.

[David Snopek]

2011/5/12 Aeron Glemann <aeron....@gmail.com>:

Maybe this makes me a bad developer, but I don't really care about
introducing a small number of presentational classes. :-)

Especially, if doing so makes the project more maintainable. Using
"#right-sidebar p" is more semantically correct but also brings a lot
of negatives along with it (ie. not reusable, increasing specificity).
Just like putting a class on every "p" which is created by site users
brings some negatives. In my opinion, pragmatic use of exceptions can
be a good thing.

Regards,
David.

[Aeron Glemann]

Oh I agree... but I don't think template-level elements (the things in template.css that you use to layout the structure of a page) are _really_ container objects on the same level as modules and the "donuts" Nicole describes. I would definitely define defaults for content objects on a .mod level - this is in disagreement with what Nicole suggests above - but not on a template level - which is in agreement with what you say below.

--