Side by Side DIVs

[Screwball]

Hi,

I'm having problems getting 2 divs to display side-by-side correctly.
I've done the google bit, but cannot find anything which is similar
enough to what I want. Most of the descriptions I've found seem to use
individual ID= (versus class=) - I don't understand how "cascading"
works in those circumstances. :(

Anyway, I have two specific questions.

1) Why are the 2 lower DIV's being rendered OUTSIDE their containing DIV?

2) The "Div text" in those 2 DIVs is being rendered Black - it should be
Blue and Red (left/right respectively). The CSS validates, but if I
remove the "color: inherit;" from div.mine then the coloured text is
correct, but I get a css validation warning (not an error).

Would someone mind helping me out a little please.

The page can be found at http://www.screwy-ut.myby.co.uk/ - it is a
*very* simple test page to help me understand what is going on.

TIA

--
Steve.
Reply-to is valid, but temporary.

[Stephen Poley]

This is a CSS question rather than HTML, but anyway ...

On Wed, 12 Oct 2005 14:41:06 GMT, Screwball <mu*******@sneakemail.com>
wrote:

Anyway, I have two specific questions.

1) Why are the 2 lower DIV's being rendered OUTSIDE their containing DIV?
Because they are floated, and you don't have a clear in the containing
DIV.

2) The "Div text" in those 2 DIVs is being rendered Black - it should be
Blue and Red (left/right respectively).
You've specified the colour two ways: as 'inherit' in 'mine' and as a
specific colour in 'blue' and 'red', so the browser has to choose one of
them. I think you're then being bitten by precedence rules - 'mine' is
specified as being applied to DIVs only and so is more specific (but I
have to recheck the rules on this every time myself). You could fix the
precedence, but it would be better to just specify the colour only once.
The page can be found at http://www.screwy-ut.myby.co.uk/ - it is a
*very* simple test page to help me understand what is going on.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

[Screwball]

Stephen Poley wrote:

This is a CSS question rather than HTML, but anyway ...

On Wed, 12 Oct 2005 14:41:06 GMT, Screwball <mu*******@sneakemail.com>
wrote:

Anyway, I have two specific questions.

1) Why are the 2 lower DIV's being rendered OUTSIDE their containing DIV?

Because they are floated, and you don't have a clear in the containing
DIV.

I just added "clear: both" to div.mine - result is that the right-hand
div has now dropped down so although it is still to the right, it's top
is below the bottom of the left one :(

2) The "Div text" in those 2 DIVs is being rendered Black - it should be
Blue and Red (left/right respectively).

You've specified the colour two ways: as 'inherit' in 'mine' and as a
specific colour in 'blue' and 'red', so the browser has to choose one of
them. I think you're then being bitten by precedence rules - 'mine' is
specified as being applied to DIVs only and so is more specific (but I
have to recheck the rules on this every time myself). You could fix the
precedence, but it would be better to just specify the colour only once.

Am I losing the plot here? I thought that the whole idea of "cascading"
rules was that each "level" down inherited (most) of it's parent's
attributes, but that they could be overridden if required? Similar to
classes in many OO programming languages.

Bear in mind that this is a learning exercise - I am rather new to all
this stuff ;)

--
Steve.
Reply-to is valid, but temporary.

[Stephen Poley]

On Wed, 12 Oct 2005 18:53:15 GMT, Screwball <mu*******@sneakemail.com>
wrote:

Stephen Poley wrote:

This is a CSS question rather than HTML, but anyway ...

On Wed, 12 Oct 2005 14:41:06 GMT, Screwball <mu*******@sneakemail.com>
wrote:

Anyway, I have two specific questions.

1) Why are the 2 lower DIV's being rendered OUTSIDE their containing DIV?

Because they are floated, and you don't have a clear in the containing
DIV.

I just added "clear: both" to div.mine - result is that the right-hand
div has now dropped down so although it is still to the right, it's top
is below the bottom of the left one :(

OK, I guess my answer was a bit too brief. I suggest you play a bit with
floats and clears in a simpler layout to get a feel for what is going
on. You need a clear *in* the DIV. In other words you need an HTML
element within div.mine, after the floats, with the clear property on
it. (<BR> is commonly used, and apparently always works, though the spec
actually says IIRC you need a block-level element).

2) The "Div text" in those 2 DIVs is being rendered Black - it should be
Blue and Red (left/right respectively).

You've specified the colour two ways: as 'inherit' in 'mine' and as a
specific colour in 'blue' and 'red', so the browser has to choose one of
them. I think you're then being bitten by precedence rules - 'mine' is
specified as being applied to DIVs only and so is more specific (but I
have to recheck the rules on this every time myself). You could fix the
precedence, but it would be better to just specify the colour only once.

Am I losing the plot here? I thought that the whole idea of "cascading"
rules was that each "level" down inherited (most) of it's parent's
attributes, but that they could be overridden if required? Similar to
classes in many OO programming languages.

Bear in mind that this is a learning exercise - I am rather new to all
this stuff ;)

OK, let's try to explain this simply. You have <div class="mine left">
This applies both the class mine (with color: inherit) and class left
(with color: blue;). Clearly the browser can't apply both these rules
simultaneously. It is actually applying color: inherit. The reasons for
this are quite logical but a little complicated. It is caused by the
fact that in your CSS you say "div.mine" but only "left", not "div.left"
(see section 6.4 of the CSS spec for the details).

I suggest that rather than try to understand the details at this stage,
you try to avoid applying both rules at the same time. Perhaps what you
really want to do is apply "mine" to the outer class and "blue" (only)
to the inner class. But then you'll need another class to apply the
padding.

I hope this is enough to point you in the right direction. If you play a
bit further it should become obvious.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

[Andy Dingley]

On Wed, 12 Oct 2005 18:53:15 GMT, Screwball <mu*******@sneakemail.com>
wrote:

Similar to classes in many OO programming languages.

Nope. Almost entirely the opposite in fact.

[Screwball]

Stephen Poley wrote:

On Wed, 12 Oct 2005 18:53:15 GMT, Screwball <mu*******@sneakemail.com>
wrote:

Stephen Poley wrote:

This is a CSS question rather than HTML, but anyway ...

On Wed, 12 Oct 2005 14:41:06 GMT, Screwball <mu*******@sneakemail.com>
wrote:
Anyway, I have two specific questions.

1) Why are the 2 lower DIV's being rendered OUTSIDE their containing DIV?
Because they are floated, and you don't have a clear in the containing
DIV.
I just added "clear: both" to div.mine - result is that the right-hand
div has now dropped down so although it is still to the right, it's top
is below the bottom of the left one :(

OK, I guess my answer was a bit too brief. I suggest you play a bit with
floats and clears in a simpler layout to get a feel for what is going
on. You need a clear *in* the DIV. In other words you need an HTML
element within div.mine, after the floats, with the clear property on
it. (<BR> is commonly used, and apparently always works, though the spec
actually says IIRC you need a block-level element).

I thought that *was* a simple layout to play with :o

So you're saying that I have to clear AFTER the floated divs in order to
get them to work correctly? Most curious - I shall try that in the morning.

2) The "Div text" in those 2 DIVs is being rendered Black - it should be
Blue and Red (left/right respectively).
You've specified the colour two ways: as 'inherit' in 'mine' and as a
specific colour in 'blue' and 'red', so the browser has to choose one of
them. I think you're then being bitten by precedence rules - 'mine' is
specified as being applied to DIVs only and so is more specific (but I
have to recheck the rules on this every time myself). You could fix the
precedence, but it would be better to just specify the colour only once.

I spent AGES playing with "div.mine left" "div.mine.left" etc adnauseam
- most of which combinations screwed up the layout completely.
What you saw was the closest I could get.
Am I losing the plot here? I thought that the whole idea of "cascading"
rules was that each "level" down inherited (most) of it's parent's
attributes, but that they could be overridden if required? Similar to
classes in many OO programming languages.

Bear in mind that this is a learning exercise - I am rather new to all
this stuff ;)

OK, let's try to explain this simply. You have <div class="mine left">
This applies both the class mine (with color: inherit) and class left
(with color: blue;). Clearly the browser can't apply both these rules
simultaneously. It is actually applying color: inherit. The reasons for
this are quite logical but a little complicated. It is caused by the
fact that in your CSS you say "div.mine" but only "left", not "div.left"
(see section 6.4 of the CSS spec for the details).

Ahh - so I'm applying 2 distinct and unrelated rules to the same item
(the div)? that might explain my confusion. What I was attempting to do
(probably wrongly) was to take a div (in this case "mine") and
effectively "subclass" it - ie. derive a class from it with some
attributes being overridden. This is clearly not the way to go - back to
the books (and the drawing board).

I suggest that rather than try to understand the details at this stage,
you try to avoid applying both rules at the same time. Perhaps what you
really want to do is apply "mine" to the outer class and "blue" (only)
to the inner class. But then you'll need another class to apply the
padding.
As above, i think you can probably see what I was trying to achieve and
how. It seems to need more "classes" than I had, at first, thought were
necessary.
I hope this is enough to point you in the right direction. If you play a
bit further it should become obvious.

Yes, it should be. I'll play a bit further and try to make sense of it all.

Thank you for your explanation - appreciated.

--
Steve.
Reply-to is valid, but temporary.

[Screwball]

Andy Dingley wrote:

On Wed, 12 Oct 2005 18:53:15 GMT, Screwball <mu*******@sneakemail.com>
wrote:

Similar to classes in many OO programming languages.

Nope. Almost entirely the opposite in fact.

Then I must be totally misunderstanding the concept of a "cascading
style". Would you mind elaborating on your reply a little?

--
Steve.
Reply-to is valid, but temporary.

[Andy Dingley]

Screwball wrote:

Then I must be totally misunderstanding the concept of a "cascading
style".
You and every other experienced OO coder I've seen dive into CSS
(myself included).
Would you mind elaborating on your reply a little?

If I had a snappy explanation of it, I'd write a CSS book.

The difference is the use of weightings (the cascade) in the scope of
CSS selectors, compared to the simple over-ruling that we know from OO.
The cascade is not a simple matter!

There's also the question of CSS rule granularity. Cascades are
evaluated at the level of the individual rules, not the "method" (the
{} block).

Lie & Bos's book is the only vaguely readable and accurate explanation
of this that I've seen. I found the spec and Meyer's book much less
useful (although both are worth reading for other issues).

[Screwball]

Andy Dingley wrote:

Screwball wrote:

Then I must be totally misunderstanding the concept of a "cascading
style".

You and every other experienced OO coder I've seen dive into CSS
(myself included).

I'm SO glad it's not just me..

Would you mind elaborating on your reply a little?

If I had a snappy explanation of it, I'd write a CSS book.

:)
The difference is the use of weightings (the cascade) in the scope of
CSS selectors, compared to the simple over-ruling that we know from OO.
The cascade is not a simple matter!
That much is becoming clear!
There's also the question of CSS rule granularity. Cascades are
evaluated at the level of the individual rules, not the "method" (the
{} block).

Lie & Bos's book is the only vaguely readable and accurate explanation
of this that I've seen. I found the spec and Meyer's book much less
useful (although both are worth reading for other issues).

I have the Meyer book - I have found it to be very useful (in general
terms). The specifics though (as it this case) are maybe not as clear as
they could be.

I need to re-read that section carefully in light if the above.
Thanks for the reply - appreciated.

--
Steve.
Reply-to is valid, but temporary.

[Matt Silberstein]

On 13 Oct 2005 07:36:08 -0700, in comp.infosystems.www.authoring.html
, "Andy Dingley" <di*****@codesmiths.com> in
<11**********************@g47g2000cwa.googlegroups .com> wrote:

Screwball wrote:

Then I must be totally misunderstanding the concept of a "cascading
style".

You and every other experienced OO coder I've seen dive into CSS
(myself included).

CSS confuses me in the context of any of my previous computer
experience. Kind of impressive for something with no loops or calls or
anything procedural.

[snip]

--
Matt Silberstein

Do something today about the Darfur Genocide

Genocide is news | Be A Witness
http://www.beawitness.org

"Darfur: A Genocide We can Stop"
www.darfurgenocide.org

Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/