By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,624 Members | 2,229 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,624 IT Pros & Developers. It's quick & easy.

Manipulating divs

P: n/a
http://firasd.org/

The divs of the 'box' class seem to have the effect I want in IE
(namely: consistent height and horizontal alignment along the set of
divs), but it totally falls apart in Firebird, like the p's inside teh
divs are independent of the div's properties... (looked okay until I
applied "display: inline;")

What would be the proper way (I'm assuming that Firebird is displaying
the proper behaviour)?

Jul 20 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a
Firas D. wrote:
http://firasd.org/

The divs of the 'box' class seem to have the effect I want in IE
(namely: consistent height and horizontal alignment along the set of
divs), but it totally falls apart in Firebird, like the p's inside teh
divs are independent of the div's properties... (looked okay until I
applied "display: inline;")

What would be the proper way (I'm assuming that Firebird is displaying
the proper behaviour)?

The page is now at http://firasd.org/tmp-indexbroken.html

Jul 20 '05 #2

P: n/a
Firas D. wrote:
Firas D. wrote:
http://firasd.org/

The divs of the 'box' class seem to have the effect I want in IE
(namely: consistent height and horizontal alignment along the set of
divs), but it totally falls apart in Firebird, like the p's inside teh
divs are independent of the div's properties... (looked okay until I
applied "display: inline;")

What would be the proper way (I'm assuming that Firebird is displaying
the proper behaviour)?

The page is now at http://firasd.org/tmp-indexbroken.html


Just found out Opera does that same thing as Mozilla :(

Off to read what the docs say about layout (the spec is suprisingly
readable), but any insights would be appreciated.

Jul 20 '05 #3

P: n/a
In article Firas D. wrote:
Firas D. wrote:
Firas D. wrote:
http://firasd.org/

The divs of the 'box' class seem to have the effect I want in IE
(namely: consistent height and horizontal alignment along the set of
divs), but it totally falls apart in Firebird, like the p's inside teh
divs are independent of the div's properties... (looked okay until I
applied "display: inline;")
Could it be that width don't apply ro inline elements?
You could use display:inline-table instead, but it only works in Opera,
even if it is correct way to handle this.

CSS21 has this inline-block for this, but it is not supprted by any
browser (including Opera 7 even if somepeople may say otherwise, in fact,
Opera 7 has worst support for inline-block.)
What would be the proper way (I'm assuming that Firebird is displaying
the proper behaviour)?
The page is now at http://firasd.org/tmp-indexbroken.html


Just found out Opera does that same thing as Mozilla :(

Off to read what the docs say about layout (the spec is suprisingly
readable), but any insights would be appreciated.


You propably must use float, but that breaks your footer some reason I
didn't bother look, you propably know that already.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #4

P: n/a
On Sun, 18 Jan 2004 06:38:02 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:
Could it be that width don't apply ro inline elements?
You could use display:inline-table instead, but it only works in Opera,
even if it is correct way to handle this.

CSS21 has this inline-block for this, but it is not supprted by any
browser (including Opera 7 even if somepeople may say otherwise, in fact,
Opera 7 has worst support for inline-block.)


Float should work, so long as the first footer element is set to clear.

http://www.w3.org/TR/CSS2/propidx.html lists width, height and min-width
as ok with "all elements but non-replaced inline elements, table rows, and
row groups" - if the box rendering is mandatory, you should float it.
Jul 20 '05 #5

P: n/a
In article Neal wrote:
On Sun, 18 Jan 2004 06:38:02 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:

Snipped irrelevant quote, why didn't you quote this:
You propably must use float, but that breaks your footer some reason

Float should work, so long as the first footer element is set to clear.


No it don't, as OP propably uses absolute positioning etc for footer.
Probably OP does that incorrectly or unnecessarily though.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #6

P: n/a
Lauri Raittila wrote:
In article Neal wrote:
On Sun, 18 Jan 2004 06:38:02 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:

Snipped irrelevant quote, why didn't you quote this:
You propably must use float, but that breaks your footer some reason


Float should work, so long as the first footer element is set to clear.

No it don't, as OP propably uses absolute positioning etc for footer.
Probably OP does that incorrectly or unnecessarily though.


OP classes absolute positioning along with the meaning of life as one of
the esoteric enigmas only within the realm of sages' understanding.

OP just wants to align his divs vertically :(

(OP is having a hard time resisting table usage)

Jul 20 '05 #7

P: n/a
Firas D. wrote:
OP just wants to align his divs vertically :(


Horizontally.

div1 - div2 - div3

etc.

Jul 20 '05 #8

P: n/a
On Sun, 18 Jan 2004 10:42:49 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:
In article Neal wrote:
On Sun, 18 Jan 2004 06:38:02 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:


Snipped irrelevant quote, why didn't you quote this:
> You propably must use float, but that breaks your footer some reason

Was left off inadvertantly. Didn't mean to intend you didn't say it.
Float should work, so long as the first footer element is set to clear.


No it don't, as OP propably uses absolute positioning etc for footer.
Probably OP does that incorrectly or unnecessarily though.


Look at his stylesheet, he doesn't.

To OP - try replacing that display: inline with float: left
Jul 20 '05 #9

P: n/a
Neal wrote:
To OP - try replacing that display: inline with float: left


Like, totally, dude! Thanks. Will figure out the footer issue later;
thanks for pointing it out Raittila.

Any idea why (height: 30%;) doesn't apply to both divs, but width does?

Jul 20 '05 #10

P: n/a
In article Firas D. wrote:
Neal wrote:
To OP - try replacing that display: inline with float: left
Like, totally, dude! Thanks.


And if you change stupid styling of .footer to clear:both; it will work
too. OTOH, I don't know what you are after with it, as it didn't work
anyway on Opera 7.5p1
Will figure out the footer issue later;
thanks for pointing it out Raittila.
It works fine if you remove all styling from it, unless you already did.
Any idea why (height: 30%;) doesn't apply to both divs, but width does?


30% of what?

http://www.w3.org/TR/CSS21/visudet.html#x12
| Specifies a percentage height. The percentage is calculated with
| respect to the height of the generated box's containing block. If the
| height of the containing block is not specified explicitly (i.e., it
| depends on content height), and this element is not absolutely
| positioned, the value is interpreted like 'auto'. A percentage height
| on the root element is relative to the viewport.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #11

P: n/a
Lauri Raittila wrote:
Will figure out the footer issue later;
thanks for pointing it out Raittila.

It works fine if you remove all styling from it, unless you already did.


Well, I didn't remove styling, I put in clear: both :)
Any idea why (height: 30%;) doesn't apply to both divs, but width does?

30% of what?

http://www.w3.org/TR/CSS21/visudet.html#x12
| Specifies a percentage height. The percentage is calculated with
| respect to the height of the generated box's containing block. If the
| height of the containing block is not specified explicitly (i.e., it
| depends on content height), and this element is not absolutely
| positioned, the value is interpreted like 'auto'. A percentage height
| on the root element is relative to the viewport.


Ahh... I want it to be 30% of the window.

"http://www.w3.org/TR/CSS21/syndata.html#value-def-percentage"

"Specifies a percentage width. The percentage is calculated with respect
to the width of the generated box's containing block. If the containing
block's width depends on this element's width, then the resulting layout
is undefined in CSS 2.1. "

What's the difference? I'd say the W3C is engaged in some serious
dimension bias.

Jul 20 '05 #12

P: n/a
On Sun, 18 Jan 2004 12:20:07 -0500, Firas D. <fd********@firasd.org> wrote:

Ahh... I want it to be 30% of the window.

"http://www.w3.org/TR/CSS21/syndata.html#value-def-percentage"

"Specifies a percentage width. The percentage is calculated with respect
to the width of the generated box's containing block. If the containing
block's width depends on this element's width, then the resulting layout
is undefined in CSS 2.1. "

What's the difference? I'd say the W3C is engaged in some serious
dimension bias.


What if my browser is sized at 350px tall? The viewport will be even
shorter.

Width has definite limits. Height can go on all day. The height of the
entire page is subject to the amount of content. The height of the
viewport is dependant on user settings. So you cannot control either.
Jul 20 '05 #13

P: n/a
Neal wrote:
What's the difference? I'd say the W3C is engaged in some serious
dimension bias.

What if my browser is sized at 350px tall? The viewport will be even
shorter.


min-height to the rescue :)
Width has definite limits. Height can go on all day. The height of the
entire page is subject to the amount of content.
....that's weird, but it makes sense, I guess.

The height of the viewport is dependant on user settings. So you cannot control either.


I can't make two boxes look the same without going for pixel-based
sizing, then?

Jul 20 '05 #14

P: n/a
In article Firas D. wrote:
Neal wrote: The height of the
viewport is dependant on user settings. So you cannot control either.


I can't make two boxes look the same without going for pixel-based
sizing, then?


Of course you can. You just can't use % as unit. Use em or ex units
instead.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #15

P: n/a
Lauri Raittila wrote:
In article Firas D. wrote:
I can't make two boxes look the same without going for pixel-based
sizing, then?

Of course you can. You just can't use % as unit. Use em or ex units
instead.


Wow, where do I send the boquet--oh wait, it breaks in IE :(

http://firasd.org/tmp-indexbroken.html

Excuse me while I go shoot myself.

Q: What's the difference between CSS and Astrology?
A: <insert witty answer about one being unpredictable black magic and
the other being a way to tell the future>

Jul 20 '05 #16

P: n/a
Firas D. wrote:
Lauri Raittila wrote:
In article Firas D. wrote:
I can't make two boxes look the same without going for pixel-based
sizing, then?


Of course you can. You just can't use % as unit. Use em or ex units
instead.

Wow, where do I send the boquet--oh wait, it breaks in IE :(

http://firasd.org/tmp-indexbroken.html


Figured it out; apparently the specified height wasn't enough for one of
the divs so it was stretched to accomodate the text. Looks like IE
doesn't know how to calculate ems.

Jul 20 '05 #17

P: n/a
In article Firas D. wrote:
Q: What's the difference between CSS and Astrology?
A: <insert witty answer about one being unpredictable black magic and
the other being a way to tell the future>


s/CSS/IE

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #18

P: n/a
Lauri Raittila <la***@raittila.cjb.net> wrote:
In article Firas D. wrote:
Firas D. wrote:
> Firas D. wrote:
>
>> http://firasd.org/
>>
>> The divs of the 'box' class seem to have the effect I want in IE
>> (namely: consistent height and horizontal alignment along the set of
>> divs), but it totally falls apart in Firebird, like the p's inside teh
>> divs are independent of the div's properties... (looked okay until I
>> applied "display: inline;")

Could it be that width don't apply ro inline elements?
You could use display:inline-table instead, but it only works in Opera,
even if it is correct way to handle this.

CSS21 has this inline-block for this, but it is not supprted by any
browser


IE6 does support inline-block, as a matter of fact. It solved the
problem I brought up here earlier, inline CSS "buttons" for which I
could set the width and padding before I added the DOCTYPE that caused
those specifications to be ignored. When I set "display: inline-block"
for the "buttons", the padding and the width became effective again.
(including Opera 7 even if somepeople may say otherwise, in fact,
Opera 7 has worst support for inline-block.)


Opera 7 showed the same progression from (1) no DOCTYPE to (2) DOCTYPE
to (3) DOCTYPE and application of "display: inline-block", except that
in step 3 the padding doesn't work: the top of the text is aligned
with the top border.
--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #19

P: n/a
In article Harlan Messinger wrote:
Opera 7 showed the same progression from (1) no DOCTYPE to (2) DOCTYPE
to (3) DOCTYPE and application of "display: inline-block", except that
in step 3 the padding doesn't work: the top of the text is aligned
with the top border.


http://www.student.oulu.fi/~laurirai...block_bug.html
Buggy support - shouldn't exist. If they can't implement it, it should be
ignored, as spec says. It's been known for long enaugh that it is not
accident that they still react to inline-block.

I future, Opera 7 will be the problem browser that implement inline-block
badly instead of ignoring it, effectively making inline-block concept
avoided.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #20

P: n/a
Lauri Raittila <la***@raittila.cjb.net> wrote:
In article Harlan Messinger wrote:
Opera 7 showed the same progression from (1) no DOCTYPE to (2) DOCTYPE
to (3) DOCTYPE and application of "display: inline-block", except that
in step 3 the padding doesn't work: the top of the text is aligned
with the top border.


http://www.student.oulu.fi/~laurirai...block_bug.html


I see. Interesting. Well, it does work for <span>s. Strange that they
couldn't make it consistent.
--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.