Using id vs. Inline style="..."

[DavidSalahi]

From the books I've been reading (Jeffrey Zeldman's Designing with Web Standards; Eric Meyer's CSS book) it seems that the accepted practice is to always use the id tag for assigning unique styling. I've been wondering why this is favored over simply including the style inline with the affected tag.

I can see an advantage in that it separates the styling information from the content. But the downside is that it separates the styling information from the content. I.e., if I'm trying to debug a layout, it may be more convenient to have the style info with the element I'm looking at rather than in another pane or window.

These considerations relate only to the web designer's convenience and I don't see any difference from the web site visitor's standpoint nor from the web hosting standpoint.

What technique do you prefer? Do you see a strong reason to favor the id approach?

Dave S.

[The New Guy]

1. Its easier to organize CSS layouts using multple external css files. Example: You could sperate a site into nav.css, links.css, form.css etc. Which is much easier to read, and debug.
2. Inline styles get long quick, and get harder to read even quicker.
3. Text-highlighting programs, such as dreamweaver and editplus etc., wont highlight the css when using inline styles since the style will be a string.
4. external CSS files get cached.

[sonjay]

When I'm mucking about with a tricky style issue, I'll often use inline styling during the "mucking" process, until I get it working right - for exactly the reason you noted. Then I'll pull the style out into my external stylesheet.

It's more than just webmaster's convenience: External stylesheets are cached, so you save bytes by keeping all your styles in your external sheet. It can really add up, too. Suppose you have a 30k stylesheet -- it gets called by the browser once, and then cached. Suppose you put that same 30k worth of styles into every page as inline styles -- that's an extra 30k to download for every single page. For your visitors on dial-up, that will make a real difference. If you're close to your bandwidth limit with your host, you could have extra costs there.

And when you want to make design changes -- you save time (and for most of us, time= money) when your styles are in your external sheet.

[DavidSalahi]

It's more than just webmaster's convenience: External stylesheets are cached, so you save bytes by keeping all your styles in your external sheet.

Well, the caching effect is certainly useful for class and other non-unique selectors, but I was asking specifically about id selectors--which are unique. At least, they're unique to a given page. After I made my original post, it did occur to me that someone might want to use a given id on multiple pages. In that case, it makes sense to put the style info into an external style sheet. But if the style is truly unique to one element, then I'm not sure I see an advantage.
Dave

[DavidSalahi]

1. Its easier to organize CSS layouts using multple external css files. Example: You could sperate a site into nav.css, links.css, form.css etc. Which is much easier to read, and debug.
2. Inline styles get long quick, and get harder to read even quicker.
3. Text-highlighting programs, such as dreamweaver and editplus etc., wont highlight the css when using inline styles since the style will be a string.
4. external CSS files get cached.

My question was specifically about id selectors--which are unique to a given element. In that case, it seems to me that it's easier to read the style right where it applies than to have to look someplace else. In that case, #1, 2, & 4 don't apply.

I hadn't noticed the effect you mention in point #3. That's a good point.

Dave

[The New Guy]

Well the thing about unique is. Your menu usually starts with a:

#menu{

}
#menu li{

}
#menu a{

}
#menu a:hover{

}

etc.

Now if you had #menu inline, wouldn't it be harder to debug?

[DavidSalahi]

Well the thing about unique is. Your menu usually starts with a:

#menu{
}
#menu li{
}
#menu a{
}
#menu a:hover{
}
etc.

Now if you had #menu inline, wouldn't it be harder to debug?

Yeah, I can see that in some cases it would be harder to read inline. But in the general case of just setting a color or font size, etc. it still seems easier to read inline.

Dave

[The New Guy]

Mabye for very simple things.

[Paul O'B]

But if the style is truly unique to one element, then I'm not sure I see an advantage.

Inline styles are evil and should be avoided like the plague They are as bad as tables for layout and belong to the tag soup days of yesteryear

I find it almost impossible to debug a page with inline styles because it makes it so awkward to work with. Once you know your way around a stylesheet it becomes second nature and the html is usually so clean its also much easier to manage.

Once you have an inline style in your page then you are stuck with it for good and should you want to change the look of you page you won't be able to simply do it from the stylesheet. Even if its the only red heading on your page then is should still go in the stylesheet.

You may want to have a styleswitcher at a later date and you may have a nice pastel page but you are still stuck with your red heading.

Also think about accessibility users who may be color blind and want to use their own stylesheets only to have your inline styles override their preferences.

CSS is about separating presentation from content so it makes sense to do exactly that. I can see no benefit from having even one inline style in the html but can see loads of disadavantages.

Of course thats just my view and it doesn't mean I'm right though

Paul

[DavidSalahi]

Inline styles are evil and should be avoided like the plague They are as bad as tables for layout and belong to the tag soup days of yesteryear

Please don't answer with vague generalities and absolutisms; it's not helpful.

I find it almost impossible to debug a page with inline styles because it makes it so awkward to work with. Once you know your way around a stylesheet it becomes second nature and the html is usually so clean its also much easier to manage.

I know my way around style sheets quite well, thank you.

Once you have an inline style in your page then you are stuck with it for good and should you want to change the look of you page you won't be able to simply do it from the stylesheet. Even if its the only red heading on your page then is should still go in the stylesheet.

My question was about id tags — which, I repeat — are unique. If I want to change it later, it's more work to go to a style sheet because I have to open a second document.

Also think about accessibility users who may be color blind and want to use their own stylesheets only to have your inline styles override their preferences.

This sounds like it could be a good argument.

I can see no benefit from having even one inline style in the html but can see loads of disadavantages.

I explained the benefit in my original post.

[DavidSalahi]

A disadvantage of putting id styles in an external style sheet just occurred to me. (Remember, id selectors are unique and are intended to be applied to only a single element.) Imagine you have a site with dozens or hundreds of styled ids and you put them all in an external style sheet. How are you going to know which id is in which HTML page? And what happens if you delete the content to which that id applies? Now, you've got an orphaned id.

You can avoid this (or at least minimize it) by putting the id style in the head section. This still causes you to look in two different places for the style and the content that it refers to. But it's less onerous than having it in a separate style sheet.

Dave S.

[megamanXplosion]

My question was specifically about id selectors--which are unique to a given element.

ID selectors, class selectors, who cares? They both accomplish the same task and behave practically the same. What applies true for an ID selector will always be true for a class selector. Can a class selector be unique? Of course it can be. Therefore, any answers regarding class selectors can be used for ID selectors. Just because it's an ID selector that doesn't make it any harder or easier to manage, it doesn't counter the caching arguments, etc.

If I want to change it later, it's more work to go to a style sheet because I have to open a second document.

If that unique element was on several pages of your site then you would have to edit all of the HTML documents instead of just one CSS file. Besides, even with one document you still wouldn't even need to open it with the external CSS method because you should be able to find your spot in the CSS rather easily. If you name classes/IDs with cryptic names then it will be hard to find your spot on the page, but normally you should name things like id='left_navigation' or class='left_navigation' which can be found easily (press F3, type in the class/id name, find). Not to mention the caching and accessibility benefits of using external CSS.

Forget the thought of working with the HTML documents themselves for presentational purposes, that is the logic that's being phased out with the arrival of CSS and the work being done on HTML (now XHTML) to turn it back into a structural language. The only time HTML documents should be opened is when the content in them changes, the styling should be controlled from an external file. HTML was never designed to be a presentational language, and it's even less of a presentational language now than it was a few years ago. Use HTML for document structure and content, use external CSS for styling purposes, and use external JavaScript for behavioural purposes.

[DavidSalahi]

ID selectors, class selectors, who cares? They both accomplish the same task and behave practically the same. What applies true for an ID selector will always be true for a class selector.

Yes, they behave similarly, but the application and the intent is different. I originally raised the question because it seemed easier to put the style info directly with the content that it applies to. I know that's CSS heresy, but I want to know why. I've received a couple of good reasons which I will summarize in a follow-up message after this discussion has run its course.

If that unique element was on several pages of your site then you would have to edit all of the HTML documents instead of just one CSS file.

If it's on several pages, it not unique. In that case, I would create a class and put it into an external style sheet. But my question was about oddbal cases where I want to apply some modification to just one element.

Not to mention the caching and accessibility benefits of using external CSS.

As I previously mentioned, caching doesn't apply when the style is unique. Since the style will only apply to one element on one single page, there will never be a need to use it again. And if the user returns to the HTML page after leaving, then that page will be cached.

Forget the thought of working with the HTML documents themselves for presentational purposes, that is the logic that's being phased out with the arrival of CSS and the work being done on HTML (now XHTML) to turn it back into a structural language.

Yes, I know this is the current thinking. But please explain the problem that using inline styles would cause.

Dave

[maxor]

Dave,

It seems like you're adverse to putting unique styles into a style sheet. Sounds like you're REALLY trying to find a good reason to keep putting them into inline styles. If you want to type...

<p id="customer-2921BKQP-9381-XHAU" style="color: #000; 
margin: 1em; padding: 1em; font-family: Arial; font-size: 90%; 
text-align: center; line-height: 110%; border: 1px solid #ddd; 
background-color: #eee;">

...be my guest. However I would ask you how often these unique elements are really that different. Aren't id's only unqiue to the document on which they are displayed? So you could have id="Unique_item" on more than one page and it wouldn't conflict with any other items on the page since it's the only one. In which case I don't see why you would want to style totally different things for each item.

I think you just don't want to put your unique styles into a stylesheet, put them inline and get on with it.

[DavidSalahi]

There’s been a lot of activity on this thread today, so it might be helpful to summarize some of the key points.

IMO, the best reason for using ids (over inline styles) that I’ve seen in this discussion was given by Paul O’B who said:

… think about accessibility users who may be color blind and want to use their own stylesheets only to have your inline styles override their preferences.

He’s right--if you define styles inline, because of CSS inheritance, the inline styles will supersede a web site visitor’s style sheet.

The New Guy suggested:

Text-highlighting programs, such as dreamweaver and editplus etc., wont highlight the css when using inline styles since the style will be a string.

Actually, Dreamweaver MX2004 does highlight the style parameters when inline just as it does in a style sheet. FrontPage 2002 doesn’t highlight anything regardless of whether it’s in a style sheet or inline. GoLive CS does highlight parameters when viewing source in a CSS file but not inline. Can’t speak for editplus.

The New Guy finds CSS easier to read in a style sheet than inline. I’d say that’s a personal preference. For long parameter lists, I’d agree. But for styles with only a few attributes I don’t think it matters much.

The issue of browsers caching style sheets is irrelevant since my question was about unique styles—which is what ids are intended for.

Some people, e.g., megamanXplosion, like the aesthetic purity of completely separating presentation from structure. I agree that there’s an aesthetic appeal to that. But I also feel there’s an aesthetic appeal to simplicity and inline styles are undeniably simpler than styling with an id.

Furthermore, there’s a practical advantage to simplicity: any time you make a thing more complex, you increase the chances of it failing. In the case of ids, the most likely problem is mistyping the id name. Then, of course, the primary advantage of this simpler way, as mentioned in my original post, is that the style is right there next to the content that it modifies—right where it’s most conveniently accessed. And it avoids questions like, “has this id been orphaned by having its content deleted?”

So, for example, if I have content referring to a red apple and I want to make the paragraph appear in red, I can just tack on a style=“color:red”. But if I use an id and a style that’s somewhere else it might not be obvious what that style does. Sure, I can do as megamanXplosion suggests and give a descriptive id; e.g., id=”colorRed". But what if I then decide to add “background-color: green” and “font-size-large”? My id name no longer reflects the applied style. And I’m not about to change the name every time I try a different style tweak.

Finally, maxor suggests:

I think you just don't want to put your unique styles into a stylesheet, put them inline and get on with it.

Well, I’m willing to listen to the arguments and I’m willing to have my mind changed. But I’m not willing to go along with the fads and fashions just because that’s what the web design pundits say. Show me the practical advantages of doing it that way and I’ll listen. So far, except for the usability/accessibility argument advanced by TNG, it seems to be mostly a matter of personal preference.

Dave

[megamanXplosion]

If it's on several pages, it not unique.

Yes it is. The ID is only relevant to the page that's being viewed. A logo-bar on a site is a unique element even though it appears on every page of the site. If there are two logo-bars on one specific page, then it wouldn't be unique anymore.

As I previously mentioned, caching doesn't apply when the style is unique. Since the style will only apply to one element on one single page, there will never be a need to use it again. And if the user returns to the HTML page after leaving, then that page will be cached.

Caching still applies, even if it's one element. Some browsers only cache documents for a few hours and then toss the document away to accomodate for newer cache items, so the document itself will likely not be available to the browser without downloading it again. My browser caches HTML documents for about 2 hours and then throws them away, while it keeps CSS/JavaScript/Images for 24 hours and then tosses them away. If you throw the styling in the CSS file then that information will be held by my computer for an extra 22 hours which helps ensure neither me, or you, use any unneeded bandwidth to get what we both want.

Yes, I know this is the current thinking. But please explain the problem that using inline styles would cause.

The same exact problems presentational-HTML causes. Bad cache reliability, bad accessibility, and increased maintenance work.

Some people, e.g., megamanXplosion, like the aesthetic purity of completely separating presentation from structure. I agree that there’s an aesthetic appeal to that. But I also feel there’s an aesthetic appeal to simplicity and inline styles are undeniably simpler than styling with an id.

Undeniably? I'll deny it

It's easier for me to work with an external CSS file than it is to hunt through HTML documents looking for relevant peices of the puzzle. In an external CSS file, you could have "#silkpad_download_button {}" and it would be blatantly obvious what that controls, but the HTML method requires you to hunt through tons of unnecessary code just to find what you are looking for down at the bottom of the document, nasty! The external CSS method doesn't contain all of the HTML to hunt through, so it is undeniably easier, for me. When I'm constructing a webpage I will typically use a <style> tag and include the CSS in there and when I'm finished move it to an external file, it allows me to easily construct pages and when "redesign time" rolls around, I'll be well prepared for it. I grin everytime I do a redesign of my existing work, it's so damn simple

Sure, I can do as megamanXplosion suggests and give a descriptive id; e.g., id=”colorRed". But what if I then decide to add “background-color: green” and “font-size-large”?

You call "colorRed" descriptive? That's not even close to what I suggested. You should name your IDs according to the semantics of the element, if it's the logo bar then you might name it "logo_bar", or if it's a specialized block to encapsulate a download link for a featured product then you could name it "silkpad_download_button", etc. Even if I change the presentation of those elements, the names will still make perfect sense.