Basing one class on another class

Can I define a class so that it inherits most of its content from
another class?

So I have a class .basic that does what I normally want, but I also want
a .basic_red class, which is exactly the same as .basic with color:red
added.

This way, when I change the .basic class then the .basic_red class
follows suit.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

On 2009-10-05, Swifty <steve.j.swift (AT) gmail (DOT) com> wrote:

Can I define a class so that it inherits most of its content from
another class?

So I have a class .basic that does what I normally want, but I also want
a .basic_red class, which is exactly the same as .basic with color:red
added.

This way, when I change the .basic class then the .basic_red class
follows suit.

No, but you can do it like this:

.basic { ... }
.red { ... }
.blue { ... }

<div class="basic red">...
<div class="basic blue">...

Ben C wrote:

This way, when I change the .basic class then the .basic_red class
follows suit.

No, but you can do it like this:

.basic { ... }
.red { ... }
.blue { ... }

div class="basic red">...
div class="basic blue">...

Well, in many ways that is better. Thank you!

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

Ben C wrote:

div class="basic red">...
div class="basic blue">...

BTW: See http://www.swiftys.org.uk/blog

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

On 10/05/09 12:22 am, Ben C wrote:

So I have a class .basic that does what I normally want, but I also want
a .basic_red class, which is exactly the same as .basic with color:red
added.

No, but you can do it like this:

.basic { ... }
.red { ... }
.blue { ... }

Another way more in keeping with the specialization concept:

..basic,
..basic .red,
..basic .blu {
... all the stuff just for .basic ...
};
..basic .red { ... just for .red ... }
..basic .blu { ... just for .blu ... }

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

Jim Moe wrote:

Another way more in keeping with the specialization concept:
.basic,
.basic .red,
.basic .blu {
... all the stuff just for .basic ...
};
.basic .red { ... just for .red ... }
.basic .blu { ... just for .blu ... }

I'll see if I can work out what that means, but at the moment that's
more complex than I've even managed to understand, and when dealing with
my understanding, we're dealing with a fast dwindling resource.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

On Mon, 05 Oct 2009 11:16:27 -0700, Jim Moe wrote:

On 10/05/09 12:22 am, Ben C wrote:

So I have a class .basic that does what I normally want, but I also want
a .basic_red class, which is exactly the same as .basic with color:red
added.

No, but you can do it like this:

.basic { ... }
.red { ... }
.blue { ... }

Another way more in keeping with the specialization concept:
.basic,
.basic .red,
.basic .blu {
... all the stuff just for .basic ...
};

If it's just for .basic, you don't need to include the .basic .red and
..basic .blu selectors in the ruleset. Just use

.basic {
... all the stuff just for .basic ...
}

(and no semicolon outside of the ruleset)

.basic .red { ... just for .red ... }
.basic .blu { ... just for .blu ... }

With these selectors, the rules will apply not "just for .red"[1] but
specifically for .red[1] when it's a descendant of .basic).

[1] (or .blu, respectively)

--
John

On 2009-10-05, Jim Moe <jmm-list.AXSPAMGN (AT) sohnen-moe (DOT) com> wrote:

On 10/05/09 12:22 am, Ben C wrote:

So I have a class .basic that does what I normally want, but I also want
a .basic_red class, which is exactly the same as .basic with color:red
added.

No, but you can do it like this:

.basic { ... }
.red { ... }
.blue { ... }

Another way more in keeping with the specialization concept:
.basic,
.basic .red,
.basic .blu {

That means elements with class red that are descendents of elements that
are class basic (descendents in the DOM tree, not in some putative class
hierarchy we might be trying to simulate here). Not sure that's what
Swifty wants.

But yes you could do it like that, but it would mean extra divs in the
markup. Every time you needed a red, you'd have to write:

<div class="basic"><div class="red">

rather than <div class="basic red">

Then you'd just define properties for ".basic" (common stuff) and extra
properties for ".basic .red" (anything red inside a basic).

But I don't think there's anything to be gained by that, and having the
extra divs is definitely a downside.

... all the stuff just for .basic ...
};
.basic .red { ... just for .red ... }
.basic .blu { ... just for .blu ... }

On 10/05/09 02:06 pm, Ben C wrote:

So I have a class .basic that does what I normally want, but I also want
a .basic_red class, which is exactly the same as .basic with color:red
added.

Another way more in keeping with the specialization concept:
.basic,
.basic .red,
.basic .blu {

That means elements with class red that are descendents of elements that
are class basic (descendents in the DOM tree, not in some putative class
hierarchy we might be trying to simulate here). Not sure that's what
Swifty wants.

That is what he asked about. It's even in the Subject line.

But yes you could do it like that, but it would mean extra divs in the
markup. Every time you needed a red, you'd have to write:

div class="basic"><div class="red"> rather than <div class="basic red"

Then you'd just define properties for ".basic" (common stuff) and extra
properties for ".basic .red" (anything red inside a basic).

But I don't think there's anything to be gained by that, and having the
extra divs is definitely a downside.

The extra markup is definitely a bummer. But it also prevents a growth

of least-specific rule sets with generic names, easing maintenance and
re-use (at least of the generic names). Here I am using the specificity
aspect of CSS to simulate sub-classing where a subclass adds or modifies
the attributes of the parent.
The other method you and Ben C outline emulates multiple inheritance
which combines (possibly conflicting) rules from independent rule sets.
I guess without more details about the actual application, there is no
way to really decide which would be better.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

Ben C wrote:

That means elements with class red that are descendents of elements that
are class basic (descendents in the DOM tree, not in some putative class
hierarchy we might be trying to simulate here). Not sure that's what
Swifty wants.

You can see what I want at http://www.swiftys.org.uk/calendar which is
part-way through a conversion to CSS from <FONT> and the likes. I don't
use the class ".basic" there, that was just the example I used in this
thread.

On that page, the basic class defines how the individual day cells
appear. Then I use other classes (such as .today) to highlight the cells
of special interest. Hence the need to apply two classes in some cases.

I'll confess that I use it mostly myself, so I've tested it mainly in
the Opera browser that I normally use. I've glimpsed at it in the rest
of the bunch though, excepting IE7/IE8 (because I'm obliged to test my
work pages with IE6)

The design objective was simple - to come as close as possible to an old
wall calendar that I received around 1998. I still have some work to do
on the table borders, especially at the bottom right.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk