Classes with the same name?

Is there anything wrong with having several classes with the same name
in the same style sheet? Something like...

div.pagedown {
margin: 20px 0px 20px 0px;
border-top: 1px solid #caa;
border-left: 1px solid #caa;
width: 450px;
}

img.pagedown {
margin: 0px 8px 0px 8px;
border-width: 0;
}

a.pagedown {
color: #903;
}

thx,

--williamc

williamc wrote:

Is there anything wrong with having several classes with the same name
in the same style sheet?

div.pagedown {
img.pagedown {
a.pagedown {

You can't have multiple classes with the same name. You _can_ have multiple
styles with selectors that match the same class (which is what you have
above).

--
David Dorward http://dorward.me.uk/

Thx. I stand corrected. And as a matter of style, since these are all
used together, it makes sense to me to have them all called "pagedown".
Just wondered what other people do...

--williamc


David Dorward wrote:

williamc wrote:

Is there anything wrong with having several classes with the same name
in the same style sheet?

div.pagedown {
img.pagedown {
a.pagedown {

You can't have multiple classes with the same name. You _can_ have multiple
styles with selectors that match the same class (which is what you have
above).

--
David Dorward http://dorward.me.uk/

On Sat, 20 Sep 2003 15:05:44 +0100, David Dorward wrote:

williamc wrote:

Is there anything wrong with having several classes with the same name
in the same style sheet?

div.pagedown {
img.pagedown {
a.pagedown {

You can't have multiple classes with the same name. You _can_ have multiple
styles with selectors that match the same class (which is what you have
above).

Hmm.. I thought that classes and selectors were the same thing. A class
such as:

..classname {};

is a selector on the root element, is it not?

Further, I thought you could break up a class/selector into multiple
definitions, such as:

img.classname {position:absolute};
img.somethingelse {...);
img.classname {background-color:000};

Brian wrote:

Erik Funkenbusch wrote:
.classname {};
is a selector on the root element, is it not?

No. It is a selector for *any* element whose class is .classname

In contrast, a selector that matches the root element, at least in
HTML/XHTML would be:

html {}

(although the { and } are not actually part of the selector AFAIK)


--
David Dorward http://dorward.me.uk/

Erik Funkenbusch wrote:

I don't follow. if img.myclass isn't a class, what is? Is it a
theoretical construct? Is it the identity assigned to a selector?

"myclass" is a class.

..myclass is a selector that matches elements with the class "myclass"

img.myclass is a selector that matches img elements with the class "myclass"

So how are img.classname and td.classname not the same class then?

Becuase they aren't classes at all. In both cases though, ".classname"
matches the same class.

So if those are the same class then the following would mean that the td
position style would supercede the img classname, right?

img.classname {position:absolute;}
td.classname {position:static;}

No, becuase the selector has more rules in it then just the class name.

--
David Dorward http://dorward.me.uk/

On Sat, 20 Sep 2003 19:11:59 +0100, Jim Dabell wrote:

If this is still confusing, I suggest you throw away classes for the time
being and concentrate on using CSS by selecting elements in other ways.

I understand how it works, I just didn't understand the semantics.

You've cleared up a few things for me here by pointing out the relationship
between HTML and CSS and these terms. Thanks.

Erik Funkenbusch wrote:

On Sat, 20 Sep 2003 19:11:59 +0100, Jim Dabell wrote:

If this is still confusing, I suggest you throw away classes for the time
being and concentrate on using CSS by selecting elements in other ways.

I understand how it works, I just didn't understand the semantics.

You've cleared up a few things for me here by pointing out the relationship
between HTML and CSS and these terms. Thanks.

Erik,

You mentioned C programming - did you do any object oriented programming?

If so, I think this may be the source of some of your confusion - a lot
of programmers expect classes in HTML/CSS to be similar to the use of
the term classes in other programming languages and that can cause a lot
of confusion - as they are really very different beasts.

If this is at all your case just ignore anything you have ever heard
about classes from OOP languages when dealing with CSS classes and it
will save you a lot of headaches.

HTH.

--Nikolaos

On Mon, 22 Sep 2003 23:24:13 -0400, Nikolaos Giannopoulos wrote:

Erik Funkenbusch wrote:
On Sat, 20 Sep 2003 19:11:59 +0100, Jim Dabell wrote:

If this is still confusing, I suggest you throw away classes for the time
being and concentrate on using CSS by selecting elements in other ways.

I understand how it works, I just didn't understand the semantics.

You've cleared up a few things for me here by pointing out the relationship
between HTML and CSS and these terms. Thanks.

Erik,

You mentioned C programming - did you do any object oriented programming?

If so, I think this may be the source of some of your confusion - a lot
of programmers expect classes in HTML/CSS to be similar to the use of
the term classes in other programming languages and that can cause a lot
of confusion - as they are really very different beasts.

Yes, I'd already come to that conclusion

If this is at all your case just ignore anything you have ever heard
about classes from OOP languages when dealing with CSS classes and it
will save you a lot of headaches.

Actually, it's not as different as you might think. It just takes a little
bending of your understanding to see it

Erik Funkenbusch wrote:

On Mon, 22 Sep 2003 23:24:13 -0400, Nikolaos Giannopoulos wrote:
[snip]
If this is at all your case just ignore anything you have ever heard
about classes from OOP languages when dealing with CSS classes and it
will save you a lot of headaches.

Actually, it's not as different as you might think. It just takes a
little bending of your understanding to see it

It is all very well to say what CSS classes are not. The hard bit as far as I
am concerned is to replace that with what they are. (I have the misfortune to
understand a fair amount about OOA & OOD as well as OOP. Aaaaaaarrrggghh!)

My current mental model is to forget about classes as anything resembling
anything else with the same name. They might as well be called "trogs". (So
far, so good). But I worry that I have got things fundamentally wrong, and
need a "paradigm shift". I've summarised my mental model below - I hope that
no-one will tell me that I need a "paradigm shift".

I now think of it instead from the point of view of a rendering engine working
serially (?) through a document such as an HTML document. What does it do at
each stage?

Initially, within the <head> </head> block, it (conceptually at least) builds
up a composite style sheet, according to the cascading rules of linked CSSs &
any styles declared there. Then it starts on the <body> </body> block, and at
each new element (tag), it has to decide "how do I render this element?"

Some elements themselves have styles, and these are, in effect, combined with
the composite style sheet for the duration of the element. (But I'll ignore
this, because I don't use them!)

Then the task of the rendering agent (or user agent) is to determine, for this
next element, what set of values from the composite style-sheet to apply for
each of the relevant properties. And the first question is "what rules are
SELECTED?" I see it as primarily about SELECTION. My assumption is that if you
can understand which rules are selected, and then understand the inheritance
and priority principles that apply where there are contradictions and
incompleteness within the selected rules, you end up with an understanding of
what the rendering agent will do.

Perhaps the biggest challenge for me is that this model prevent me from
knowing what the effect of a particular rule is in isolation. It isn't like
being able to discuss what the class of an object specifies. Even later
declarations within the same rule may overide what has just been learned.
Later rules may also do so. And then, at "browse time", all that may be
blown-away by new declarations that only become apparent when the rendering
agent reads the document!

I worry about this model because of its lack of predictability. But what is
really important is: "is this mental model useful?"

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/