A question about locational dependant styles & questions about OOCSS

[xckpd7]

I love the idea of OOCSS but a couple of things have really been getting to me.

1. Let's assume you have 2 areas of your page that are controlled by CMS. Both have different overarching styles. But you want the html that goes in to look a certain way. How do you accomplish this without being locational dependent? So basically I don't want to put my p styling on the p element, but I don't want to have to put a class on every single paragraph element (it's ridiculous honestly): how do you accomplish that and remain true to OOCSS?

My concern is, that (with presumably is the idea of OOCSSO) putting classes on EVERYTHING isn't the most ideal thing. Also, it really, really hurts people's understanding of what OOCSS can really do, when every example is a very convenient use case: what if a site is not Facebook and everything doesn't look the same? Or on many of these simple pages elements have silly defaults that clearly wouldn't exist if the page had more unique content.

[Martin Petrov]

Don't put the same class on every <p> element. Put it on the container element.

[Nicole Sullivan]

I'd love to see the site, can you share the URL?

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/2ck0vey1dzAJ.
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.

[xckpd7]

I don't have a URL... this is actually in production, and this will be
the very first use of OOCSS on the site. I can explain it more clearly
though. If you want to think about it like this: 3 different paragraph
styles, on 3 different areas of the site. Paragraphs are user editable
(fair enough expectation that I don't have direct control over html in
these fields). Without being locational dependent, how am I expected
to target these areas?

The only thing I can think of at the moment to get around this is to
use wrapper divs with managed classes, and use child selectors so
nothing other than the first level will bleed through to other nested
modules. Then maybe a 'little" extra specificity for only the user
editable areas?

On a side note, looking at the example documentation / html there are
modules skins which are using star selector to style.... I don't know
if this is a fault in the documentation, or maybe an exception to the
rule? I figure my answer in how that is implemented might provide an
answer to what I"m doing? Maybe not?

My biggest fear right now without these questions answered is that by
using OOCSS, you're building yourself into a box... looking at the
documentation for the framework there are tons of "assumptions" it
makes: The grid system "assumes" that at no point in development will
someone ever design a module that is negatively margined outside of
the building blocks of the grid system. All the documentation (and the
sites posed as examples of OOCSS) are super simple examples, all
sanboxed in their own html document, so it's very convenient to just
target elements and call it "default styling". Maybe I'm wrong but I'm
looking for answers.

On Sep 26, 10:27 am, Nicole Sullivan <nic...@stubbornella.org> wrote:
> I'd love to see the site, can you share the URL?
>
> Sent from my iPhone
>

> On Sep 25, 2011, at 2:24 PM, xckpd7 <wright....@gmail.com> wrote:
>
> I love the idea of OOCSS but a couple of things have really been getting to
> me.
>
> 1. Let's assume you have 2 areas of your page that are controlled by CMS.
> Both have different overarching styles. But you want the html that goes in
> to look a certain way. How do you accomplish this without being
> locational dependent? So basically I don't want to put my p styling on the p
> element, but I don't want to have to put a class on every single paragraph
> element (it's ridiculous honestly): how do you accomplish that and remain
> true to OOCSS?
>
> My concern is, that (with presumably is the idea of OOCSSO) putting classes
> on EVERYTHING isn't the most ideal thing. Also, it really, really hurts
> people's understanding of what OOCSS can really do, when every example is a
> very convenient use case: what if a site is not Facebook and everything
> doesn't look the same? Or on many of these simple pages elements have silly
> defaults that clearly wouldn't exist if the page had more unique content.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Object Oriented CSS" group.

> To view this discussion on the web visithttps://groups.google.com/d/msg/object-oriented-css/-/2ck0vey1dzAJ.

[Evan Winslow]

Child selectors is the right way to go here.

Evan Winslow

http://twitter.com/evanwinslow

[xckpd7]

Right but what happens when I want to add an element with a generic class? It will get out specified by the child selector....

[aglemann]

FWIW I had this exact same question right before you:

https://groups.google.com/forum/#!topic/object-oriented-css/wHHQ9ul12v0

[xckpd7]

So what you're basically saying is that OOCSS wouldn't work for that specific implementation.... so trying to materialize this into a rule:

"There are use cases where you need to code up something custom... for user created html which needs different styling than the default, or when a section of the design doesn't really follow the rest of the site design wise.... for these use cases (as long as you're absolutely sure), feel free to code up something custom. Nothing from OOCSS should exist inside of a custom section however, as the results are unpredictable (other than spacing as all the declarations have !important)"

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

Hi xckpd7,

I think Nicole's post can be misunderstood, and you are about to draw the wrong conclusions from the cross-referenced link by aglemann.

Keep in mind that OOCSS aims at making CSS as high-performant as it can be while keeping it maintainable. This approach works very well for big portal websites, but it also works for small websites. You have to grant, though, that these two usecases are very different.

On big portal websites (think yahoo, facebook), you are working in an environment where the whole team (design -> development) works together with (theoretically) unlimited resources and iterations to make the website as fast and chic as possible. Your designers are very likely to accept a certain push-back from the Frontend Engineers to unify the styling of various elements in order to avoid having to recode elements. The goal is to be super performant and avoid code creep (your CSS file size growing possibly exponentially over time). For this to work, you do work with a basic set of assumptions. Slightly varying elements in style will be unified, exceptions to the rule need to be kept to the minimum. In that way, OOCSS starts at the design. Obviously, the less presentationally different objects you have, the less code you need.

On the other hand, if you work for a web design agency or as a freelancer, you do NOT have endless resources and iterations. You have to work with limited resources and achieve the best possible result at a set deadline with a very small number of iterations. You may or may not be able to give that push-back to the designers; you might have 20 objects which look very similar, but have different paddings or slightly different colors. Again, for portal websites, you would unify those; this time though, that might not be an option and you will have to code these different individual objects. In effect, you will have redundant code and increase the number of objects.

To understand Nicole's post, keep in mind that she is working almost exclusively on (huge) portal websites. Most of the objects on the page will be unified to allow for the best possible performance - that's what she is there for. New objects will need to pass a certain set of criteria in order to be allowed, and it NEEDS to be that way BECAUSE it's a portal and she needs to avoid code creep. The only exceptions to unification will be the header and the footer. The argument that makes her code these the old way is to not add objects to the code base that will never be reused. It's still a portal, so there are still going to be lots and lots of objects for content producers to use. To not add objects that are limited to the header/footer, Nicole's choice is to code these two (and in most cases for her, the only two) use cases the old way. It's a trade-off, as every decision for Frontend Engineers is. That doesn't mean, however, that it's also the best choice for you.

If you are NOT working on a portal website, the total number of objects you will code will be vastly less than on a portal website. Code creep will still happen, but the effect won't be as devastating for the whole project as it would be for a portal. So in these cases, I would still recommend to use objects for the header and footer, because introducing inconsistency on a small website will be a lot more confusing to the developer(s) than keeping it clean and consistent. The need to keep the number of new objects down isn't nearly as pressing as it is for portal websites. Also, the header and footer will be sections on the page where you have the most influence (CMS wise) on the HTML output. Much more so than on sections where the editor can basically add and remove text as he wants (e.g. with a rich text editor).

And this is where I come back to your original question (sorry for taking so long, but I want to absolutely avoid misunderstanding). Your use case is very common and get's asked regulary. It's the basic problem concerning mostly the HTML elements p,ul,ol,li, and h1-h6. These elements will a lot of times be edited with a rich text editor, and not every CMS allows custom transformations for the rich text fields (TYPO3 is one I know that allows this, so you could theorically make sure that every p in a given field receives a class).

You only have a limited number of options to deal with the problem:

- configure your CMS to transform the HTML and add the classes you need. In theory, that would be the correct way to go. Not having the ability to influence the HTML output is honestly not of concern for the CSS domain. It is a case of the Backend/CMS domain not offering sufficient functionality, and the frontend domain having to compensate the shortcoming of another domain. It's like saying to the HTML architect that he cannot use the h1 tag because you have not styled the h1 in your CSS. It's not his problem, it's your problem, you should make it happen.
- use location dependent styles. A solution introduced in an earlier topic (can't find it right now) was to introduce formatting classes which do nothing else but format child elements (e.g. a class ".formatDark" which does ".formatDark p {color: #000}"). This way you have some control where to add the class, while not touching the structure of the element the formatting class gets assigned to. Be aware that you might run into specificity issues. It's a trade off.

It's on you to decide which solution is the best given the circumstance you are working with. You cannot make the "perfect" decision, you are working with goals that directly oppose each other. OOCSS does work for this case, in most cases it's your CMS that will be the limitation. If you need to work with formatting classes, be aware of the downsides. It might still be (and for me a lot of times has been the) best way to go - given your project's limitations.

Hope that clears up things for you a little bit.

Cheers,
Erik

[Aeron Glemann]

> use location dependent styles. A solution introduced in an earlier topic (can't find it right now) 

> was to introduce formatting classes which do nothing else but format child elements

I think the post you're talking about is this one:

https://groups.google.com/d/msg/object-oriented-css/tOOQ-crWk68/1ds3x7lsEHUJ

But note that it is somewhat at odds with "the only exceptions to unification will be the header and the footer."

To me, it's not the differentiation between big portal and small websites where OOCSS really starts to fall apart... it's when you stop making the assumption that the same content is always going to look the same. For example, responsive design or e-commerce engines where the same HTML page could have dramatically different presentations depending on device or brand. OOCSS's tight binding of presentation and content does not give much flexibility in those cases.

--

You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.

To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/fdNaf3y8ExwJ.

[xckpd7]

So basically locational styles are frowned upon unless there is
ABSOLUTELY no sensible alternative, at which point you use a managed
wrapper class in a small scope (or like was said before, things that
don't match the site entirely that are pixel perfect can be coded
custom).

On Sep 27, 2:18 pm, Aeron Glemann <aeron.glem...@gmail.com> wrote:
> > use location dependent styles. A solution introduced in an earlier topic
>
> (can't find it right now)> was to introduce formatting classes which do nothing else but format child
>
> elements
>
> I think the post you're talking about is this one:
>

> https://groups.google.com/d/msg/object-oriented-css/tOOQ-crWk68/1ds3x...

>
> But note that it is somewhat at odds with "the only exceptions to
> unification will be the header and the footer."
>
> To me, it's not the differentiation between big portal and small websites
> where OOCSS really starts to fall apart... it's when you stop making the
> assumption that the same content is always going to look the same. For
> example, responsive design or e-commerce engines where the same HTML page
> could have dramatically different presentations depending on device or
> brand. OOCSS's tight binding of presentation and content does not give much
> flexibility in those cases.
>

> On Tue, Sep 27, 2011 at 9:23 AM, erik.fris...@googlemail.com <

[Murray Nuttall]

The way I think of it is, if it's a branded area, restrict use of
OOCSS in case a global tweak down the road (to headings, lists,
paragraphs, etc) screws up an area that is super important to your
clients online identity.

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

Hi Aeron,

I don't think OOCSS falls apart; I think the current code from the
OOCSS Framework falls apart. The principles work perfectly in any
context. At least that's what I perceive. Can you give a concrete
example where OOCSS falls apart for you? I'd love to get your view on
it, since you've been at this for a long time as well.

Cheers,
Erik

On Sep 27, 8:18 pm, Aeron Glemann <aeron.glem...@gmail.com> wrote:
> > use location dependent styles. A solution introduced in an earlier topic
>
> (can't find it right now)> was to introduce formatting classes which do nothing else but format child
>
> elements
>
> I think the post you're talking about is this one:
>

> https://groups.google.com/d/msg/object-oriented-css/tOOQ-crWk68/1ds3x...

>
> But note that it is somewhat at odds with "the only exceptions to
> unification will be the header and the footer."
>
> To me, it's not the differentiation between big portal and small websites
> where OOCSS really starts to fall apart... it's when you stop making the
> assumption that the same content is always going to look the same. For
> example, responsive design or e-commerce engines where the same HTML page
> could have dramatically different presentations depending on device or
> brand. OOCSS's tight binding of presentation and content does not give much
> flexibility in those cases.
>

> On Tue, Sep 27, 2011 at 9:23 AM, erik.fris...@googlemail.com <

[Ethan Resnick]

I agree with Erik; from my experience, OOCSS principles are robust and apply on projects big and small.

I wonder if the original asker could provide a bit more context on why there are three paragraph styles (i.e. what's the function of each) and which containers hold which styles. Then we might be able to find an elegant, OOCSS-aligned solution.

-Ethan

[Aeron Glemann]

Sure. And as a disclaimer this is my interpretation of OOCSS principles based on my time with the framework.

So, to expand a bit more on both examples I gave...

1. Responsive web approach, where you want a high level of flexibility over the layout. The more presentational classes you have in your CSS the less this is possible. For example, having all those grid classes in your HTML assumes parts of the page are columns 1of3 etc.. but for tablets you might want that to be 1of2 and for mobiles 1of1... 

2. Different brands using the same HTML. Just look at the box.net app Nicole worked on. Great example of OOCSS principles in action, but imagine if you had to re-brand that completely. From clean web 2.0 to "grunge" look. Or a re-styling where horizontal menus were vertical, etc. The HTML just makes way too many assumption on how the UI should look. Take all those spacing classes there as an example. Now I have to space my grunge elements the same way.

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

@xckpd7:

Not quite. Don't try to go dogma. It's not that locational styles are
*per se* frowned upon. There is in most cases a very good reason for
this. The more you code location-dependent, the less you can reuse *in
general*; and the more you have to recode *in general*. "In general"
meaning that it happens and has happend SO many times with location-
dependent styles that you can start so see a pattern, a reason as for
why the suckiness of code increases over time. And location dependence
plays a role in it.
For beginners, I would definitely recommend to go with a dogma of "no
location dependence" for a while to get a sense of what it means to
code OOCSS-style. But in the end, you have competing goals, and you
have to compromise. Applying a set of rules without thinking about it
will not always provide the best result. You are asking for a "best
practice", but be aware that the best practice is the best practice
*in general*. Yes, your code will be a lot better if you code OOCSS,
but once you have a firm grip on the principles and a few OOCSS-style
websites under your belt, you won't need a brains-off-dogma anymore,
because it was and is only there so that you don't have to do the
thinking *from the very start*; it's not there to allow you to shut
off your brain from now on forward.
Above all, OOCSS shows you that a) CSS doesn't suck, and b) a
practical way out of the general code problems you run into when you
code traditionally. When you code it for a while, you will run into
cases where it's not obvious which choice is best and the call is on
you. These types of questions somehow always seem to end up on this
board, and they are framed in a way that makes OOCSS responsible for
solving the problem in a super amazing way, and if it doesn't, it's
broken. OOCSS won't allow you to stop thinking, it will help you to
think better! It shows you general weaknesses in your code and how to
solve them. But you will always find situations where coding in a very
strict way will not be the best choice, because that's the reality we
live in as frontend architects. Opposing goals. I cannot stress this
enough. If you found a use case where coding in a very strict way is
not practical for you, it doesn't mean OOCSS sucks, it means that you
have to choose which way to go in a situation where both roads bring
advantages and disadvantages, and there is no clear "yes" or "no".
After coding OOCSS you will be more EXPERIENCED and hopefully see both
paths clearly, and you can take all factors into consideration when
making the call.
So, xckpd7, don't take it as dogma. Coding OOCSS will improve your
code. It won't necessarily be the FINAL stop on the road to the most
perfect and elegant code ever, but it's a very important stop on
making you a better frontend architect.

As Nathan said, we are moving sort of off-topic and into a theoretical
area. That might not actually be useful to the original question. As
Ethan said, I would also appreciate more context to constructively
solve the issue at hand.

Cheers,
Erik

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

Ethan, not Nathan, sorry. Don't know where that came from ;)

On Sep 27, 11:44 pm, "erik.fris...@googlemail.com"

> ...
>
> read more »

[Aeron Glemann]

I'll add as a postscript... OOCSS principles are an extension of grid systems and clearfloats.. if you are cool having those presentational classes in your markup than OOCSS will work for your project. But if you need zen garden-type flexibility with your layout then better off sticking to good old semantic classes and pushing the UI abstractions into your stylesheets with the help of CSS preprocessors.

[Ethan Resnick]

Aeron: I completely agree with the specific OOCSS problems you mentioned, and I've been working on a new approach that aims to address them while preserving the fundamental code reuse principles that I think make OOCSS valuable. I'll try to send you a personal message about that soon.

Anyway, I do agree with Erik that we're off topic at this point and should try to get back to the original question.

-Ethan

[Aeron Glemann]

Please do! Maybe we can combine forces since we've been tackling this on our end for a while too (and I know others into solving this problem as well).

[xckpd7]

We all know the concept of setting smart defaults throughout our
site... the only real exception where we can target elements directly
in general. There is a legitimate point to declaring defaults but I
feel like all the sites / documentation that I've seen use it in
practice are too simple of examples so much so that the default
styling is "absused" to fit whatever the example is.

Isn't it a fair to think that I might want multiple defaults for
different sections of the site (maybe on different pages, maybe not),
without having to go through and class everything? Nicole Sullivan
commented on how defining good defaults is important so that classes
don't end up on EVERYTHING... on sites where everything isn't super
normalized and where you have different permutations of modules,
wouldn't it be nice if you could define different defaults? This is
somewhat done in the colors plugin for OOCSS: there is a wrapper div
called .skinA randomly wrapped about classes elements and that works
ok.... but you can't do that with unclassed elements because they'll
bleed through, and you can't target with a child selector because then
you add extra specificity (if not it would be the perfect fix).

An example: For instance, I have default styling for all anchors on a
site. Then I have a media block skins, in which I have anchor text
which is smaller than the default anchor styling. Am I expected to
class every single anchor (imagine there are 20 of these media blocks
with this skin)? If I do any sort of star selector (*) or child
selector (>) to smartly target it, it would override any anchors
themselves that just have a class on them.

All I'm trying to get at, is coping with classes on EVERYTHING (and my
apprehension with doing it in cases like this), and more than 1 smart
default for an entire site.

On Sep 27, 5:44 pm, "erik.fris...@googlemail.com"

> ...
>
> read more »

[Rachael L Moore]

I work with a lot of templates and template systems where there is
user-entered content. The conclusion I came to may be sophistry, but:

- OOCSS says you can use descendant selectors for things that are part
of an object (example is corners, I believe).
- Location dependence refers more to selectors like "this module in
this column and on this page" than to any descendant selector.
- User content inserted by a WYSIWYG can be considered a kind of
object, of which generic elements are a part.

I call it the "rich text object" and leave it at that.

Strictly speaking, this does violate certain principles of OOCSS.
It's arguably location dependent. When p is in the rich text object,
it has different styles. Depending on the design, it violates the
rule that a given h* must look the same anywhere. Its selectors have
more specificity. Et cetera.

However, I'm attempting to adopt the principles of OOCSS to make CSS
coding easier and more maintainable. Those are the end goals, not
absolute compliance with a set of rules. In some cases bending those
rules makes more sense than adhering to them.

The "rich text object" works for me everywhere I've used it because of
its limited scope and applicability. The class is added in isolated,
specific areas and no other object is allowed inside of it. If that
weren't the case, I doubt it would work. If there were more than one
kind, I doubt it would work--the overall architecture would become
equivalent to locational sandboxing (rather than a confined
exception).

It may be my implementations would dismay stubbornella, though. These
are only my own opinions.

- Rachael

> ...
>
> read more »

[xckpd7]

Sounds reasonable, thanks Rachael!

> ...
>
> read more »

[Jos Hirth]

Location specific = bricks which look differently depending on their
location

Now, the question is are those different types of paragraphs things
which could exist on their own or are they part of a bigger structure/
brick?

E.g. would it make sense to put them into the same container? If not,
they can be treated as a piece of a bigger structure.

How much of a pain would it be if you change your mind at a later
point?

Would it perhaps make sense to split this into 3 files (e.g. general,
area1, and area2)?