h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

Secondly, the wording in

'ID are unique, were as classes are for groups or more that one object.' was slightly confusing - I'd insert an arrogrant comment about giving you an English lesson, but I'm not like that..

Try re-wording 'ID are unique, were as classes are for groups or more that one object', please...

Ah sorry, I seemd to have pissed you off a bit, (getting grief off some people not good)

It just seems (in HTML terms) to be more obvouse then a FONT tag, a class i.e a set of things with something in common. and an id (identification) of an object string. I probly should brush up on my bedside manner

Sorry again.

-- DoctorMO --

wops, simupost,

I often mistype of as or.

-- DoctorMO --

All is forgiven

I was just slightly confused about why two things would be invented if their purpose was the same, that's all

Everyone gets confused about id and class (and div and span). Even the h2g2 edited entry on the subject has it backwards.

Ah, now we need another explanation
Confusing Div with Span? The CSS Tutorial I took said that DIV & SPAN are identical, but some browsers dont' support one of them, so use the other (as mentioned before)

I mostly use when I have a stylesheet .class for a certain tag, but I don't need or want another tag, for instance:

.thisClass { font-family: Tahoma; font-size:11pt; text-transform:uppercase }


this will all show in capital letters


But I'm sure they're much more useful - If they can replace tables, Hey! Why Not!

"when I have a stylesheet .class for no specific tag", is what I meant

Ah yes, now I know this one... erm, Ah thats it, DIV is like a divider, it covers a whole line (or lines) with the content and can be a good way to break up content in general, SPAN are not whole lines, they can apear anywere in aline (as well as inbeded) to provide a means of extra suport (instead of using Text like my friend did).

I've used both in the past, but use DIVs more because I can enbed them into themselves and in tables for great results in dynamic content.

-- DoctorMO --

Right. A span cannot contain a or other large elements. Think of it as a replacement for , but much more flexible.

This is the thing - if a browser doesn't support CSS (you can easily call a DOM object in a JavaScript to determine if CSS is supported - there's an example script on webstandards.org: http://www.webstandards.org/act/campaign/buc/), inform the user that your site doesn't look as good as it could but still serve them the content. It's unobtrusive and encourages people to upgrade to a browser that doesn't suck.

Oh, and be SURE that you use a browser detection script to trap Netscape 4. Do NOT serve CSS to Moz 4 because it could (and probably will) render it improperly (at best) or even die horribly and take the system down with it (at worst).

The other reason IDs are useful is because you can manipulate them directly from a JavaScript by name using the DOM. If you don't know about the Document Object Model it's worth learning but not strictly necessary. It lets you do some pretty cool stuff.

DoctorMO: That's how you used to have to use tables before CSS existed. It was horrible.

Strictly in terms of SGML (that's XML and HTML's parent markup language in case you don't know), is a block level element and is an inline element. Block level elements are things like or that are mostly containers for text and other markup. Inline elements are like or that define the properties of some segment of text and only allow a limited set of elements to occur inside them.

If you really want to understand the difference between inline and block elements, I would highly suggest you read the HTML 4.01 spec thoroughly - it's in one of the first few chapters.

*swat*

yes the DOM, allpower to the DOM...

Tables arn't dead! you oldist!

-- DoctorMO --

Tables are dead (don't use them for layout). Long live tables (use them as tables).

There's an article titled "Tables are dead. Long live tables!" that I've seen linked to on some of the W3C mailing lists, actually.

And I dislike CSS in that it's non-hierarchial, so I don't think it's perfect.

Someone please tell me what's wrong with allowing:

p {
font-face: sans-serif;
.copyright {
font-size: smaller;
}
}

instead of:

p {
font-face: sans-serif;
}

p.copyright {
font-size: smaller;
}

The first version, while nicely compact and reflective of your basic logical block statement, would nevertheless lead to hopelessly nested stylesheets that were incredibly difficult to decipher. Things would start depending on whether you put your new class before or after the 18th of your 42 consecutive brackets. Of course that is exactly how nested if-then-else statements and while loops work (as well as nested tables) and there is nothing *wrong* with it, but the point is that some people just don't have the mind for programming or following that specific kind of logical structure. A simple list is much easier for most people to follow. Remember, these are web designers who will be writing the css - and how many badly nested tables have you run across in the past 10 years? Or even just your basic blah blah blah? I know I can't count that high.

It's much easier to read with the spaces in.

I find the simple lists that grow to ridiculous proportions much harder to read - I have to put comments in every other line to make the file readable at all.

I find that the CSS is missing a multi hirachical class system. it would be nice to say and so that say you wanted a certain set of styles for headers but wanted more than one size. crux's for Version 3 me thinks.

-- DoctorMO --

There's a supported way to make CSS do that. But I don't remember what it is.

As an aside, you shouldn't be using to make headers. You should use , et al. because then your document is well structured. Using styled tags makes your document look flat to a screen reader and certain other tools (like summary engines and table of contents generators) which isn't very useful. Since you can style headers anyway, it's best to use them.

Well yes I know, I was thinking up an example. I had to do some tricky CSS with some tables... nuts.

-- DoctorMO --

Point taken?

No the CSS was nuts, but because of the table structure i.e ... I could stick the class (style) of the table in the table tag, instead of indervidual classes for each cell. I did have CTFill, CTLeft CTFillLeft ect, but now I just have TABLE.CT TR TD { a normal cell } and TABLE.CT TR TH { for headers } and even better was the table borders, I managed to get them down to TLeft TRight, using the difrent TH and TD function, and because of this I could implerment a printable version of the page. nice.

I know you could have done this with enbeded DIVs, but this worked from what I had.

-- DoctorMO --