Topic: Inline style vs. style sheet

I find myself typing a lot more inline style (css) these days. I guess because ..thinks of example.. sometimes the width of a div area should adjust a little ..decides he couldn't come up with a good example, but presses on with the topic regardless.. well its just that for every little style adjustment it seems tedious to me to pop out to the stylesheet each time to make the change. Maybe what I am thinking is that the stylesheet should be reserved for the global settings and anything that might be adjusted *styled* in one place on a website would be better styled inline.

Maybe I should ask the question:
Is there anyone out there that avoids inline style like they would avoid someone with the bird-flu?

Karl..

Aaaaar!
CSS are for presentation, markup is for content.

If you want to tweak the presentation on a specific page, give an id or a class to the BODY or HTML nodes and use it to filter where the tweak applies.

not quite as the bird flu... but avoiding inline styles, heck yes!

Why? Well to me it's just as bad as font tags... they are right there smack dab in the middle of the html making it pure h*ll to redesign using edits in the stylesheet only!
Plus, linked in stylesheets are cached, inline just bloats the code.

What I recommend is to use a mix of styledefinitions for selected html-elements, some basic classes for different positioning, some basic classes for color and some for fontstyling, something for decorations etc or something like that which suits your way of thinking.

Name them smart, not "14pxRed", a better choice would be "mediumLargeColored" remember that you should be able to identify the presentation in the HTML even if the colors have changed since last redesign.

Then you can use several classes on the elements, one for positioning, one for color and one for font:
<p class="floatLeft accentBgColor mediumSize thinBorders">My para-text</p> that way you can quite easily keep your stylesheet in a reasonable size and retain the flexibility.
/Dan

{cell 260} {Blog}
-{"Theories without facts are just religions...?}-

(Edited by DmS on 01-02-2006 18:50)

So in DmS example above, if you now (for whatever reason) need that paragraph scooted over 6px (to a distance you have previously defined) what does the approach become? Do you give this particular paragraph an ID, then style it there for a margin-left of 6px? This most likely supports Pois recommendation.

Why on earth would you have to change the presentation of a single paragraph on a whole website ?
[edit] I mean if you face this situation, there's all the chances that your markup or the paragraph in question [edit2] ,or worst : your client, [/edit2] is completely fucked up. [/edit]

Anyway, in case there is a valid reason I'd stick to the method I suggested above.



(Edited by poi on 01-02-2006 19:18)

(Edited by poi on 01-02-2006 21:17)

A client can ususally come up with a reason, now whether the reason is *reasonable* or not isn't the point.

Ok, so I get it, don't Inline style! Thats two big DONT'S coming out of this site,
1) don't design with tables and
2) (which we just learned).

Karl..

TO

quote:

---

Karl said:

So in DmS example above, if you now (for whatever reason) need that paragraph scooted over 6px (to a distance you have previously defined) what does the approach become? Do you give this particular paragraph an ID, then style it there for a margin-left of 6px? This most likely supports Pois recommendation.

---

To answer this question more directly: Yes.

If the paragraph is important enough to need special treatment, it is important enough to qualify for either an Id or a Class.

If it's *not* actually that important, then your job as deisgner does involve pushing the client in the wise direction, rather than simply accepting everything they think they want.

Inline styles become a complete nightmare when updates and design changes are needed, and essentially negate the whole point behind CSS.

I would be interested in some common practices / naming conventions / css organization / etc... any such article online?

Karl: this article is one person's approach/opinion, not "common practice" so far as I know, but it is one of the few REALLY well presented descriptions of a carefully thought out methodology I have ever run across:

http://businesslogs.com/design_and_usability/lean_xhtml_and_precise_css.php

Read the comments too - some useful tidbits.

If you follow links to the numerous stylesheets mentioned in the article you can get a sense of just how extensive some of them are. Kind of overwhelming actually. But css this targeted permits very lean html.

quote:

---

I would be interested in some common practices / naming conventions / css organization / etc... any such article online?

---

I've seen many methods, but I prefer to give an id to each main element on a page and then define each tag that will be used inside them. I do this because I always had a problem with a style from one section conflicting and screwing with styles in another section and it hurts my brain to think too hard. Keeps it simple. I also try to order my css to conform to the order of my markup, so when I go back in there a year later my short term memory isn't such a hinderance.

Here's an example from the last site I built out, pretty basic.

Ram

(Edited by Ramasax on 01-06-2006 05:42)

A couple of questions - but first, thanks Ramasax for the exmple!

1) You have things like
#head #wmasearch #keywords {position:absolute;top:5px;left:6px;width:165px;border:1px solid #69562B;}
Wich I interpret as, "the element #keywords within the element #wmasearch within the element #head is styled as... "

Do you do this for clarity only; a means to self-describe the location of the #keywords element? This doesn't allow for additional elements named #keywords within another set of elements does it?

2) You have things like
input#Keywords
Is this another self-describing trick? Just having styling #Keywords would be sufficient, no? Which leads to the question.. you have the lower case and propercase ID of keywords, is CSS case-senstive?

This is an excellent example. Thanks so much, this helps a lot!

Karl..

(Edited by Karl on 01-08-2006 17:49)

Yeah, both of the #keyword (or #Keyword, as the case doesn't matter even though it's neater to stick with one) styles would work just as well if they weren't specifically described to sit inside the #wmasearch element within the #head element, or to only apply for <input>s, but there also is an advantage to doing it this way - it allows you to have more than one #keyword ID, seperate ones for different elements. Does that make sense? ...an example:

input#keyword { somestyles; }
fieldset#keyword { someotherstyles; }
div#keyword { yetmorestyles; }

That way, you can assign the 'keyword' ID to an <input> as well as to a <fieldset> and to a <div>.

Then with the first of your examples, the idea is very similar - you could, in one style sheet, have one '#head #wmasearch #keyword' element as well as a '#head #mp3search #keyword' element and apply whichever styles you need to both of them.

Huh? IDs should be unique - you never assign them to more than one element!. (Or the validator caughs at you - and it's right.)

If you want something that can be assigned multiple times, use a class.

Oh. In that case disregard everything I suggested above...

I think I tricked myself into thinking I was talking about classes all the time, or something. Oh well.

Seems at least part of my brain noticed when it asked if things still made sense

Hopefully this will help clarify (rather than adding more confusion ) -

You wouldn't generally nest CSS selectors with ID's -

#thisid #thatid #theotherid {
...
}

Each ID can only appear once on each page, so the style attributes you give it won't usually need to be specified in regard to its parent element.

However, there may be cases in dynamically generated pages, where something of the same ID will appear within different elements depending on which page it is loaded in, and for some reason may require different styling.

The main reason you use such nesting would appear more like this -

#nav ul li {
...
}

in which you would specify a different style for list items when they appear inside the #nav element. This is generally preferable (IMO) to setting a class for the li, as it retains more flexibility and interferes less with your mark-up.

So you are more or less correct, Karl, but it's all in how you set it up. The idea is to keep your mark-up as clear as possible, which means using less class names on child elements - using the class or id of the parent element to define the styles of the elements within them.

Ok. I do have one concern with CSS and thought the solution was an inevitable use of styling at the child element level in your mark up. Let me explain further:

The problem (an example):
You can not define a color at the top of a css stylesheet then reference this color in your css. So you might want to create a color called "Site_Background_Colors_Dark". Then you might have a div element which you'd like to fill with this color so, background-color: #$$Site_Background_Colors_Dark$$

Supposed Solution:
Create a generic class called Site_Background_Colors_Dark with adequate css to color the backround accordingly. In your mark up do something like this:

<div id="news_today" class="Site_Background_Colors_Dark"> ... </div>

Going a little further, we would like to specifiy the font color for this particular background color so our markup becomes...

<div id="news_today" class="Site_Background_Colors_Dark font_color_on_dark_background"> ... </div>

Then lets say in our news_today section we have news which is considered important if the news occurs in your town so you'd add to this element more and would have....

<div id="news_today" class="Site_Background_Colors_Dark font_color_on_dark_background important_local_new"> ... </div>

Can you see where I am going with this? Anyhow, this is what I was starting to do in my HTML Markup, well that and I was starting to add a lot of style=" ... " definitions too.

Enough said. I am now trying to avoid these type of base class defs. Please verify that it is important to avoid such.

DL-44 Wrote:

quote:

---

So you are more or less correct, Karl, but it's all in how you set it up. The idea is to keep your mark-up as clear as possible, which means using less class names on child elements - using the class or id of the parent element to define the styles of the elements within them.

---

This is what I supposed, that an ID should be unique for the entire markup. I do see the use and value of arranging stylesheets and styles like this. I've already improved the current stylesheet I am working on.
Thanks DL-44.
Karl..

(Edited by Karl on 01-08-2006 20:23)

quote:

---

Karl: Do you do this for clarity only; a means to self-describe the location of the #keywords element? This doesn't allow for additional elements named #keywords within another set of elements does it?

---

I do it for clarity in some cases, yes. And no, one specific ID per page only, as stated above.

quote:

---

2) You have things like
input#Keywords
Is this another self-describing trick? Just having styling #Keywords would be sufficient, no? Which leads to the question.. you have the lower case and propercase ID of keywords, is CSS case-senstive?

---

CSS style sheets are case insensitive, except in the case of something outside it's boundaries, such as a path to an image or font names.

The input#Keywords element was capitalized because it was consistent with the element as described in the markup. Note also that these were two distinct elements, not the same. "#keywords" inside the header and the other declaration are actually two different form elements from different templates on the site, which never appear on the same page, the latter being something on the backend, beyond my control, which needed a quick fix. Generally, it is good practice to keep everything, aside from the things mentioned above, lowercase where possible.

Sorry for the confusion. Sometimes when you are working on a large team with a tight deadline and a constrained budget, a little "perfection" is lost along the way.

quote:

---

DL: The idea is to keep your mark-up as clear as possible, which means using less class names on child elements - using the class or id of the parent element to define the styles of the elements within them.

---

That's about it in a nutshell.

Ram