Classes with the same name?

**David Dorward** · Jul 20 '05, 08:19 PM

Re: Classes with the same name?

williamc wrote:
[color=blue]
> Is there anything wrong with having several classes with the same name
> in the same style sheet?[/color]
[color=blue]
> div.pagedown {
> img.pagedown {
> a.pagedown {[/color]

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/

**williamc** · Jul 20 '05, 08:19 PM

Re: Classes with the same name?

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:[color=blue]
>
> williamc wrote:
>[color=green]
> > Is there anything wrong with having several classes with the same name
> > in the same style sheet?[/color]
>[color=green]
> > div.pagedown {
> > img.pagedown {
> > a.pagedown {[/color]
>
> 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/[/color]

**Erik Funkenbusch** · Jul 20 '05, 08:19 PM

Re: Classes with the same name?

On Sat, 20 Sep 2003 15:05:44 +0100, David Dorward wrote:
[color=blue]
> williamc wrote:
>[color=green]
>> Is there anything wrong with having several classes with the same name
>> in the same style sheet?[/color]
>[color=green]
>> div.pagedown {
>> img.pagedown {
>> a.pagedown {[/color]
>
> 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).[/color]

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:absol ute};
img.somethingel se {...);
img.classname {background-color:000};

**Brian** · Jul 20 '05, 08:19 PM

Re: Classes with the same name?

Erik Funkenbusch wrote:[color=blue]
>
> Hmm.. I thought that classes and selectors were the same thing.[/color]

No. A class is an attribute of html which may be used to build a
selector.
[color=blue]
> A class such as:
>
> .classname {};[/color]

(the semicolon is illegal, afaik)
[color=blue]
> is a selector on the root element, is it not?[/color]

No. It is a selector for *any* element whose class is .classname, and
would thus work on any of the following:

<img class="classnam e" src="foo.png">
<div class="classnam e">
<body class="classnam e">


By contrast,

img.classname {}

is a selector only for image elements whose class is .classname.
[color=blue]
> Further, I thought you could break up a class/selector into multiple
> definitions, such as:
>
> img.classname {position:absol ute};
> img.somethingel se {...);
> img.classname {background-color:000};[/color]

These are 2 different selectors; the first and third specify img
element with class .classname, the second is img with class
..somethingelse .

--
Brian
follow the directions in my address to email me

**David Dorward** · Jul 20 '05, 08:19 PM

Re: Classes with the same name?

Brian wrote:[color=blue]
> Erik Funkenbusch wrote:[color=green]
>> .classname {};
>> is a selector on the root element, is it not?[/color][/color]
[color=blue]
> No. It is a selector for *any* element whose class is .classname[/color]

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/

**David Dorward** · Jul 20 '05, 08:19 PM

Re: Classes with the same name?

Erik Funkenbusch wrote:
[color=blue]
> 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?[/color]

"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"
[color=blue]
> So how are img.classname and td.classname not the same class then?[/color]

Becuase they aren't classes at all. In both cases though, ".classname "
matches the same class.
[color=blue]
> 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:absol ute;}
> td.classname {position:stati c;}[/color]

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

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

**Jim Dabell** · Jul 20 '05, 08:19 PM

Re: Classes with the same name?

Erik Funkenbusch wrote:
[color=blue]
> On Sat, 20 Sep 2003 16:15:21 GMT, Brian wrote:
>[color=green]
>> Erik Funkenbusch wrote:[color=darkred]
>>>
>>> Hmm.. I thought that classes and selectors were the same thing.[/color]
>>
>> No. A class is an attribute of html which may be used to build a
>> selector.[/color]
>
> I don't follow. if img.myclass isn't a class, what is?[/color]

img.myclass is a selector that selects elements of type 'img' that are of
class 'myclass'. Selectors are part of CSS. All a selector is is an easy
way of talking about some elements. You do not have to use classes to
select elements in CSS.

A class is a way of grouping a set of elements. Classes are part of HTML.
You do not have to use CSS to make use of classes.

[snip][color=blue][color=green][color=darkred]
>>> A class such as:
>>>
>>> .classname {};[/color][/color][/color]
[snip][color=blue][color=green][color=darkred]
>>> is a selector on the root element, is it not?[/color]
>>
>> No. It is a selector for *any* element whose class is .classname, and
>> would thus work on any of the following:[/color][/color]

More specifically, it's shorthand for:

*.classname { ... }

[snip][color=blue]
> So how are img.classname and td.classname not the same class then?[/color]

They aren't classes at all, they are selectors. <img> elements and <td>
elements that have the same class attribute *are* in the same class. That
does not mean that you have to select one when you select the other. The
two selectors img.classname and td.classname are two examples that select
some elements in a class but not others.

[color=blue][color=green][color=darkred]
>>> Further, I thought you could break up a class/selector into multiple
>>> definitions, such as:
>>>
>>> img.classname {position:absol ute};
>>> img.somethingel se {...);
>>> img.classname {background-color:000};[/color]
>>
>> These are 2 different selectors; the first and third specify img
>> element with class .classname, the second is img with class
>> .somethingelse.[/color][/color]
[snip][color=blue]
> 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:absol ute;}
> td.classname {position:stati c;}[/color]

No.

img.classname {position:absol ute;}

....takes all the <img> elements that are in the 'classname' class, and set
the 'position' property to 'absolute'.

td.classname {position:stati c;}

....take all the <td> ekements that are in the 'classname' class, and set the
'position' property to 'static'.

The two rulesets are talking about completely different elements, so there
won't be any conflict.

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.

--
Jim Dabell

**Erik Funkenbusch** · Jul 20 '05, 08:19 PM

Re: Classes with the same name?

On Sat, 20 Sep 2003 19:11:59 +0100, Jim Dabell wrote:
[color=blue]
> 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.[/color]

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.

**Nikolaos Giannopoulos** · Jul 20 '05, 08:20 PM

Re: Classes with the same name?

Erik Funkenbusch wrote:[color=blue]
> On Sat, 20 Sep 2003 19:11:59 +0100, Jim Dabell wrote:
>[color=green]
>>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.[/color]
>
> 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.[/color]

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

**Erik Funkenbusch** · Jul 20 '05, 08:20 PM

Re: Classes with the same name?

On Mon, 22 Sep 2003 23:24:13 -0400, Nikolaos Giannopoulos wrote:
[color=blue]
> Erik Funkenbusch wrote:[color=green]
>> On Sat, 20 Sep 2003 19:11:59 +0100, Jim Dabell wrote:
>>[color=darkred]
>>>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.[/color]
>>
>> 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.[/color]
>
> 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.[/color]

Yes, I'd already come to that conclusion :)
[color=blue]
> 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.[/color]

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

**Barry Pearson** · Jul 20 '05, 08:20 PM

Re: Classes with the same name?

Erik Funkenbusch wrote:[color=blue]
> On Mon, 22 Sep 2003 23:24:13 -0400, Nikolaos Giannopoulos wrote:[/color]
[snip][color=blue][color=green]
>> 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.[/color]
>
> Actually, it's not as different as you might think. It just takes a
> little bending of your understanding to see it :)[/color]

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/

Child Support Analysis

http://www.ChildSupportAnalysis.co.uk/

This site provides information & analysis of child support & the Child Support Agency in the UK, mainly for lobbyists, politicians, academics & media.

**Erik Funkenbusch** · Jul 20 '05, 08:20 PM

Re: Classes with the same name?

On Tue, 23 Sep 2003 18:14:29 +0100, Barry Pearson wrote:
[color=blue]
> Erik Funkenbusch wrote:[color=green]
>> On Mon, 22 Sep 2003 23:24:13 -0400, Nikolaos Giannopoulos wrote:[/color]
> [snip][color=green][color=darkred]
>>> 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.[/color]
>>
>> Actually, it's not as different as you might think. It just takes a
>> little bending of your understanding to see it :)[/color]
>
> 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 !)[/color]

The way I now look at it is this, and of course this may be wrong as well:

"classes" are "types". When one says that a particular element, say <p>
has a class="content" then you are saying that this <p> is a "content". It
might also be class="content left tuesday 2001" in which case it also "is
a" all those other types as well, much like multiple inheritance.

This is fairly straight forward, and these rules are also straight forward,
though I must admit to not knowing which "class" takes precedence (earlier
or later in the list) when there is a conflict.

One can look at ID's as object names that also infer a type (class). For
style purposes they are the same as classes, other than only allowing a
single instance of that type (DHTML offers other ways to use ID's, but
we'll not get into that here).

Now, it's all well and good to say that a <p> is-a "content", but how are
types defined? HTML doesn't care, it just assigns them the type and allows
the browser to figure out it's definition and apply it.

CSS is the mechanism in which the browser looks up type (class)
definitions. It's something like IDL or other meta-languages in which you
define the objects in a different language/format than it is interpreted.

In fact, it might be best to think of a browser as not an HTML renderer,
but a CSS renderer, that uses HTML as its transport format. It's not
difficult to imagine using CSS with other kinds of languages, such as SGML,
XML, or even non-SGML based languages like TeX or RTF.

Since "cascade" could be another word for "inherit", one could think of CSS
"selectors" as "class overloading".

Classes with the same name?

Classes with the same name?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment