 | |
height in floats
Cascading Style Sheets Layout/presentation on the WWW (comp.infosystems.www.authoring.stylesheets)
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: height in floats -
11-10-2007
, 03:43 PM
|
In article <5plkaoFrpvqsU1 (AT) mid (DOT) individual.net>, "John L." <removeme (AT) edombmtech (DOT) co.uk> wrote: It's amazing how often this problem comes up (i.e., containers collapsing due to floats being out of the document flow). There needs to be a standard property to do what 'overflow: hidden;' does. It is better to think of it as containers not growing in the first place rather than collapsing. If a container, say a div, is not given a height by an author and only has floats within, then it simply does not develop height at all in most standards compliant browsers. It is blind to the presence of such children, it simply does not respond to them. In IE 6, the culture is different and floated children are seen and enveloped by the parent. That this problem comes up is not so surprising. If you read the css2.1 rules on floats, even quite carefully, it is not all that easy to predict how browsers made by the most willing follower of those rules, will behave. |
floats affect preferred minimum and preferred maximum widths of
shrink-to-fit containers are not precisely specified).
But it could be more readable.
Quote:
|
But in one respect at least, in terms of height, most modern browsers (not IE) are consistent. |
#12
| |||
| |||
|
|
On 2007-11-10, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote: In article <5plkaoFrpvqsU1 (AT) mid (DOT) individual.net>, "John L." <removeme (AT) edombmtech (DOT) co.uk> wrote: It's amazing how often this problem comes up (i.e., containers collapsing due to floats being out of the document flow). There needs to be a standard property to do what 'overflow: hidden;' does. It is better to think of it as containers not growing in the first place rather than collapsing. If a container, say a div, is not given a height by an author and only has floats within, then it simply does not develop height at all in most standards compliant browsers. It is blind to the presence of such children, it simply does not respond to them. In IE 6, the culture is different and floated children are seen and enveloped by the parent. That this problem comes up is not so surprising. If you read the css2.1 rules on floats, even quite carefully, it is not all that easy to predict how browsers made by the most willing follower of those rules, will behave. It is mostly pretty well laid down (although some details like how floats affect preferred minimum and preferred maximum widths of shrink-to-fit containers are not precisely specified). But it could be more readable. |
presenting comprehensive ways of picturing and making sense of
its rules or even the reason for all its rules. Perhaps it could
be made more readable, as you say, but it is a big ask! I know
what you mean and I am not disputing anything you say. The
following expresses my surprise.
For myself at least, and surely for many others too, it helps to
make pictures and stories up that model the rules. It is not that
easy to do this *and* get all the stories that model the various
rules to be a consistent easy to remember whole story.
Now, please, I am not wanting to get some discussion going on
quantum mechanics, but much is very clear about the rules of such
and when used to make predictions and calculations (by
physicists), was and is one of the most outstanding successes in
the history of science. It is the maths and the precise mechanics
that are the engine for all this, not the stories that people
tell themselves to try to "make sense" of it in visual and/or
more commonly understood processes. Indeed many of the paradoxes
arise because they clash with our intuitive ways. Parts of the
theory are modelled one way and other parts another way and these
different ways are not exactly integrated, as you will
appreciate, and give rise to the delicious 'paradoxes'.
The physical non-man made world is a mysterious place and it is
not so that very surprising that we might not be able to model
its processes in easy to remember pictures and familiar common
sense processes. Here is my surprise: that here is a man-made
object, css, for man-made projects, website production, that is
so hard to model in whole easy to remember stories and pictures
and processes. What is not surprising is that its competent
application needs quite a bit of study nor that folk can be
expected to walk in and do it well quickly.
Quote:
|
But in one respect at least, in terms of height, most modern browsers (not IE) are consistent. That part is very clear. |
dorayme
#13
| |||
| |||
|
|
In article <slrnfjc9gv.ovv.spamspam (AT) bowser (DOT) marioworld>, Ben C <spamspam (AT) spam (DOT) eggs> wrote: [...] It is mostly pretty well laid down (although some details like how floats affect preferred minimum and preferred maximum widths of shrink-to-fit containers are not precisely specified). But it could be more readable. Naturally, one cannot expect such a technical doc to be presenting comprehensive ways of picturing and making sense of its rules or even the reason for all its rules. Perhaps it could be made more readable, as you say, but it is a big ask! I know what you mean and I am not disputing anything you say. The following expresses my surprise. For myself at least, and surely for many others too, it helps to make pictures and stories up that model the rules. |
Quote:
|
It is not that easy to do this *and* get all the stories that model the various rules to be a consistent easy to remember whole story. Now, please, I am not wanting to get some discussion going on quantum mechanics, but much is very clear about the rules of such and when used to make predictions and calculations (by physicists), was and is one of the most outstanding successes in the history of science. It is the maths and the precise mechanics that are the engine for all this, not the stories that people tell themselves to try to "make sense" of it in visual and/or more commonly understood processes. Indeed many of the paradoxes arise because they clash with our intuitive ways. Parts of the theory are modelled one way and other parts another way and these different ways are not exactly integrated, as you will appreciate, and give rise to the delicious 'paradoxes'. The physical non-man made world is a mysterious place and it is not so that very surprising that we might not be able to model its processes in easy to remember pictures and familiar common sense processes. Here is my surprise: that here is a man-made object, css, for man-made projects, website production, that is so hard to model in whole easy to remember stories and pictures and processes. |
does see section 9.4.1" is not the best answer.
I think there sort of is a rationale for most of these things (as you
say: there should be, this isn't physics), which does make them easier
to remember. Perhaps I will try to write some sort of tutorial.
The reason floats pour out of their containers like that is because
they're really meant for figures embedded in paragraphs of text. So of
course they extend past the paragraphs they start in and text in
following paragraphs flows around them. That's not all that surprising,
but the consequences of the same rules are when the blocks contain only
floats and no text, which they often do when people are trying to do
sidebars and columns and things.
#14
| |||
| |||
|
|
dorayme wrote: Ben C wrote: [...] It is not that easy to do this *and* get all the stories that model the various rules to be a consistent easy to remember whole story. Now, please, I am not wanting to get some discussion going on quantum mechanics, but much is very clear about the rules of such and when used to make predictions and calculations (by physicists), was and is one of the most outstanding successes in the history of science. It is the maths and the precise mechanics that are the engine for all this, not the stories that people tell themselves to try to "make sense" of it in visual and/or more commonly understood processes. Indeed many of the paradoxes arise because they clash with our intuitive ways. Parts of the theory are modelled one way and other parts another way and these different ways are not exactly integrated, as you will appreciate, and give rise to the delicious 'paradoxes'. The physical non-man made world is a mysterious place and it is not so that very surprising that we might not be able to model its processes in easy to remember pictures and familiar common sense processes. Here is my surprise: that here is a man-made object, css, for man-made projects, website production, that is so hard to model in whole easy to remember stories and pictures and processes. I agree. That's why saying "because that's just what oveflow: hidden does see section 9.4.1" is not the best answer. I think there sort of is a rationale for most of these things (as you say: there should be, this isn't physics), which does make them easier to remember. Perhaps I will try to write some sort of tutorial. The reason floats pour out of their containers like that is because they're really meant for figures embedded in paragraphs of text. So of course they extend past the paragraphs they start in and text in following paragraphs flows around them. That's not all that surprising, but the consequences of the same rules are when the blocks contain only floats and no text, which they often do when people are trying to do sidebars and columns and things. |
that might help the sort of thing we are discussing here. Pages 1
to 5 I am sort of happy with but from then on it is in a rougher
stage... Page 6 is quite an alarming thing to work on, I have not
completed the screenshots for all browsers I have yet but there
some significant differences how different browsers treat html
order and floats.
In a recent thread there was discussion about the html/css tools
and how good they were and I was trying to get one of the
participants who was pretty critical about the adequacy of these
tools to try to discount the effect of different browsers going
their different ways (esp, the elephant, as you called it, IE!).
Well, things get pretty interesting seeing the combos on page 6
in different browsers. There is much in common between the
browsers of course, but also specific differences which need to
be learnt by web authors. Anyway, the thing I am playing with is
at: http://tinyurl.com/2qeb3y.
--
dorayme
#15
| |||
| |||
|
|
In article <slrnfjdj6p.u9q.spamspam (AT) bowser (DOT) marioworld>, Ben C <spamspam (AT) spam (DOT) eggs> wrote: [...] Well, things get pretty interesting seeing the combos on page 6 in different browsers. There is much in common between the browsers of course, but also specific differences which need to be learnt by web authors. Anyway, the thing I am playing with is at: http://tinyurl.com/2qeb3y. |
for the same reason which is the one you describe on page 4: if there is
already some text (or inline images) on a line, Firefox aligns the top
of the float with the top of the _next_ line.
It's particularly clear what's going on in Fig 13: the first float is
aligned to the top of the container, because there are no inlines before
it. The inline after it is what makes the next float start aligned to
the top of the next line down. This is incorrect behaviour (see below
[1]).
Note however that the correct behaviour (Safari/Opera) can get quite
complicated. Consider an example like this:
some text here <span></span> and there
Suppose the span is a left float with some width and height set on it.
Opera/Safari will basically do this:
FLOAT some text here and there
But, suppose the container is rather narrow and there isn't enough room
for the word "here". Then you might expect it to wrap like this:
FLOAT some text
here and
there
(The float is really much taller than I've drawn it). But what we see
above breaks one of the rules-- the top of the float is higher than the
word "here", but appears after it in the HTML source. It won't do, so in
that case, the browser has to backtrack and do this:
some text here and there
FLOAT
Which is what Firefox would have done in the first place regardless
(because it always puts the float one line down).
It looks odd (perhaps) because you end up with the float below "there",
even though it appears before it in the source. But it is correct. The
float cannot be higher than "here", but "there" _is_ allowed to be
higher than the float-- that's what the rules say.
[1]
This violates CSS 2.1 9.5.1:
6. The outer top [p. 100] of an element's floating box may not be higher
than the top of any line-box [p. 126] containing a box generated by
an element earlier in the source document.
[...]
8. A floating box must be placed as high as possible.
Firefox doesn't break 6, but it could put the float higher without
breaking 6, which means it's breaking 8.
And in 9.5:
If there's a line box, the top of the floated box is aligned with the
top of the current line box.
#16
| |||
| |||
|
|
On 2007-11-11, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote: In article <slrnfjdj6p.u9q.spamspam (AT) bowser (DOT) marioworld>, Ben C <spamspam (AT) spam (DOT) eggs> wrote: [...] Well, things get pretty interesting seeing the combos on page 6 in different browsers. There is much in common between the browsers of course, but also specific differences which need to be learnt by web authors. Anyway, the thing I am playing with is at: http://tinyurl.com/2qeb3y. The combos on page 6 differ between Firefox and Safari/Opera I think all for the same reason which is the one you describe on page 4: if there is already some text (or inline images) on a line, Firefox aligns the top of the float with the top of the _next_ line. It's particularly clear what's going on in Fig 13: the first float is aligned to the top of the container, because there are no inlines before it. The inline after it is what makes the next float start aligned to the top of the next line down. This is incorrect behaviour (see below [1]). Note however that the correct behaviour (Safari/Opera) can get quite complicated. Consider an example like this: Yes, indeed, I go on to consider (on pages 7 and 8 that are not |
wide and there is more wrapping. It gets complicated.
Thanks Ben for your further remarks I will study them more
closely when I get a chance to play more with my little project...
--
dorayme
#17
| |||
| |||
|
|
On 2007-11-11, dorayme wrote: Ben Cwrote: [...] Well, things get pretty interesting seeing the combos on page 6 in different browsers. There is much in common between the browsers of course, but also specific differences which need to be learnt by web authors. Anyway, the thing I am playing with is at: http://tinyurl.com/2qeb3y. The combos on page 6 differ between Firefox and Safari/Opera I think all for the same reason which is the one you describe on page 4: if there is already some text (or inline images) on a line, Firefox aligns the top of the float with the top of the _next_ line. It's particularly clear what's going on in Fig 13: the first float is aligned to the top of the container, because there are no inlines before it. The inline after it is what makes the next float start aligned to the top of the next line down. This is incorrect behaviour (see below [1]). Note however that the correct behaviour (Safari/Opera) can get quite complicated. Consider an example like this: some text here <span></span> and there Suppose the span is a left float with some width and height set on it. Opera/Safari will basically do this: FLOAT some text here and there But, suppose the container is rather narrow and there isn't enough room for the word "here". Then you might expect it to wrap like this: FLOAT some text here and there (The float is really much taller than I've drawn it). But what we see above breaks one of the rules-- the top of the float is higher than the word "here", but appears after it in the HTML source. It won't do, so in that case, the browser has to backtrack and do this: some text here and there FLOAT Which is what Firefox would have done in the first place regardless (because it always puts the float one line down). It looks odd (perhaps) because you end up with the float below "there", even though it appears before it in the source. But it is correct. The float cannot be higher than "here", but "there" _is_ allowed to be higher than the float-- that's what the rules say. [1] This violates CSS 2.1 9.5.1: 6. The outer top [p. 100] of an element's floating box may not be higher than the top of any line-box [p. 126] containing a box generated by an element earlier in the source document. [...] 8. A floating box must be placed as high as possible. Firefox doesn't break 6, but it could put the float higher without breaking 6, which means it's breaking 8. And in 9.5: If there's a line box, the top of the floated box is aligned with the top of the current line box. |
screenshots I did. On page 7, the parent container is much
narrower (you talk about this above) and there is a link also to
some *screenshots*. Just did this quickly and have no time to
check all out yet but I have noticed differences between browsers
on this issue of representing floats and inline text and pics and
hitherto have just simply been careful to check how my own sites
actually behave and adjust as necessary to avoid nonsense (not
mere difference). But it is an interesting matter and it now and
again comes up in various contexts where people are puzzled at
the behaviour of their websites.
I have not confirmed of late that IE 6 actually does behave as I
say on these pages but in an earlier draft with slightly
different examples, it did. I have no idea just right now whether
IE 7 is more like Firefox than IE 6 but some clues in remarks
from folk here suggest it might be. (I will get to a machine that
runs IE7 soon enough but perhaps someone who takes an interest in
this can say by looking at both cols of the table at:
http://tinyurl.com/2umvw4
and
http://tinyurl.com/2od2fy
how IE 7 stands?
Anyway, just for now, without apportioning blame to what follows
or does not follow what parts of the specs in CSS 2.1, it is
quite a surprise to me to see that FF, an open source
development, is continuing to flout the specs that you outline.
It seems to me that there must be some good arguments to
configure the browsers the way they do, that the differences are
not mere inattention to detail on the part of the developers.
--
dorayme
#18
| |||
| |||
|
|
In article <slrnfjgb0m.cne.spamspam (AT) bowser (DOT) marioworld>, Ben C <spamspam (AT) spam (DOT) eggs> wrote: [...] The combos on page 6 differ between Firefox and Safari/Opera I think all for the same reason which is the one you describe on page 4: if there is already some text (or inline images) on a line, Firefox aligns the top of the float with the top of the _next_ line. [...] On page 6 now (of http://tinyurl.com/2qeb3y) is a link to some screenshots I did. On page 7, the parent container is much narrower (you talk about this above) and there is a link also to some *screenshots*. Just did this quickly and have no time to check all out yet but I have noticed differences between browsers on this issue of representing floats and inline text and pics and hitherto have just simply been careful to check how my own sites actually behave and adjust as necessary to avoid nonsense (not mere difference). But it is an interesting matter and it now and again comes up in various contexts where people are puzzled at the behaviour of their websites. I have not confirmed of late that IE 6 actually does behave as I say on these pages but in an earlier draft with slightly different examples, it did. I have no idea just right now whether IE 7 is more like Firefox than IE 6 but some clues in remarks from folk here suggest it might be. (I will get to a machine that runs IE7 soon enough but perhaps someone who takes an interest in this can say by looking at both cols of the table at: |
after any inlines (like Firefox). I've read here before that that's what
IE7 does and you have observed that IE6 does too.
Whether IE7 gets the container height right (i.e. so as not to include
the float) I don't know.
Quote:
| http://tinyurl.com/2umvw4 and http://tinyurl.com/2od2fy how IE 7 stands? Anyway, just for now, without apportioning blame to what follows or does not follow what parts of the specs in CSS 2.1, it is quite a surprise to me to see that FF, an open source development, is continuing to flout the specs that you outline. It seems to me that there must be some good arguments to configure the browsers the way they do, that the differences are not mere inattention to detail on the part of the developers. |
doing is also simpler.
I can't think of a good reason that users would appreciate for it. And
in any case, there's no excuse for violating the specification even if
you do have a good reason.
The workaround is usually to move floats in the source text until
they're right at the beginning of the container.
It probably is in their system as a bug, to be fixed with all the other
bugs in some priority order.
The thing is if you have a bug in common with IE6/IE7 it's one you're
less likely to see in the wild because people will have either avoided
it or will be expecting the IE behaviour. This lowers its priority. On
the other hand slipstreaming behind your main competitor's bugs and
unpublished specifications is ultimately always going to be a doomed
strategy.
#19
| |||
| |||
|
|
On 2007-11-13, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote: In article <slrnfjgb0m.cne.spamspam (AT) bowser (DOT) marioworld>, Ben C <spamspam (AT) spam (DOT) eggs> wrote: [...] [...] I think both versions of IE always start the float on the next line after any inlines (like Firefox). I've read here before that that's what IE7 does and you have observed that IE6 does too. http://tinyurl.com/2umvw4 and http://tinyurl.com/2od2fy how IE 7 stands? Anyway, just for now, without apportioning blame to what follows or does not follow what parts of the specs in CSS 2.1, it is quite a surprise to me to see that FF, an open source development, is continuing to flout the specs that you outline. It seems to me that there must be some good arguments to configure the browsers the way they do, that the differences are not mere inattention to detail on the part of the developers. On that particular one it's possible they were copying IE. What they're doing is also simpler. I can't think of a good reason that users would appreciate for it. And in any case, there's no excuse for violating the specification even if you do have a good reason. The workaround is usually to move floats in the source text until they're right at the beginning of the container. |
Quote:
|
It probably is in their system as a bug, to be fixed with all the other bugs in some priority order. The thing is if you have a bug in common with IE6/IE7 it's one you're less likely to see in the wild because people will have either avoided it or will be expecting the IE behaviour. This lowers its priority. On the other hand slipstreaming behind your main competitor's bugs and unpublished specifications is ultimately always going to be a doomed strategy. |
or Firefox developer table... (Camino gets a certain following, I
think growing, in the Mac community and it also follows IE in
this respect. I understand it uses a "Gecko" rendering engine. It
is as if these deviations from the standards are set in stone!
--
dorayme
#20
| |||
| |||
|
|
In article <slrnfjld4c.g44.spamspam (AT) bowser (DOT) marioworld>, Ben C <spamspam (AT) spam (DOT) eggs> wrote: [...] (Camino gets a certain following, I think growing, in the Mac community and it also follows IE in this respect. I understand it uses a "Gecko" rendering engine. |
Quote:
|
It is as if these deviations from the standards are set in stone! |
particular one.
See http://www.tidraso.co.uk/misc/negativeHeight.html for a div with a
used height of -200px (if you follow CSS 2.1 10.6.4.5).
Konqueror (and Safari I should think) give it its content height,
Firefox gives it a height of zero.
Perhaps they're all wrong and the box's bottom purple border should
appear 200px above its green top border.
Maybe the spec does say somewhere what's supposed to happen but I
haven't found it.
It does say that setting -200px explicitly is illegal, but what are you
supposed to do with a "used" negative height?
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.