 | |
Float and Shrinkwrap
Cascading Style Sheets Layout/presentation on the WWW (comp.infosystems.www.authoring.stylesheets)
 |
| | Thread Tools | Display Modes |
#51
 
| |||
| |||
|
Re: Float and Shrinkwrap -
04-09-2008
, 06:51 AM
|
On 2008-04-05, Gus Richter <gusrichter (AT) netscape (DOT) net> wrote: dorayme wrote: There is a fairly fairly consistent rendering of the phenomenon you have been wondering about, this is true. So some rules are being followed! I find the the talk of the various contexts, stacking etc not easy to negotiate - to be frank. The thing about stacking order for layers is that normally we say that elements must be positioned to overlap in order for any z-index to visually take effect. Things can overlap quite easily without being positioned, especially when overflow and overflow: visible are involved. |
I was simply saying that "normally" we say ..... Well, here ...
Quote:
|
[...] Well, in the instance of a float we actually already have the float layered on top of the containing block with line boxes (which we've been calling div#shrink in our examples) and regarding this the spec http://www.w3.org/TR/CSS21/visuren.html#floats> has this to say: "The contents of floats are stacked as if floats generated new stacking contexts, except that any elements that actually create new stacking contexts take part in the float's parent's stacking context. A float can overlap other boxes in the normal flow (e.g., when a normal flow box next to a float has negative margins). When this happens, floats are rendered in front of non-positioned in-flow blocks, but behind in-flow inlines." The common case of a float on top a box it would be underneath (if it didn't get a higher stacking level) is this kind of thing: p blah blah span style="float: left; height: 500px; width: 200px"></span blah blah /p p blah blah blah /p The float sticks out of the bottom of the first P, but is stacked on top of the second P, even though the second P comes later in the document. Assume P has a non-transparent background in this example. |
there is no stacking at all. Am I missing something?
Quote:
|
I think that's the basic reason for giving floats a higher level than normal flow blocks. The inlines go on top of the float but usually they don't need to because they flow around it. |
#52
| |||
| |||
|
|
On 2008-04-06, Gus Richter <gusrichter (AT) netscape (DOT) net> wrote: dorayme wrote: I earlier gave an indication of a test for when it has sunk in for a normal human. It was a predictive one, not a hindsight one. I am still not as optimistic as you. The slight thing that worries me in my pessimism is that many browsers *do* the same thing, so someone or some group who programmed the browsers had a certain understanding of these things. However, I can't even be sure of this. It may turn out that the programmers put in a set of rules and one of the consequences is the phenomenon you raised, but it takes a blind machine to bring it out (like a not particularly intended consequence). What would be nice is a model that tells a story that is consistent and meaningful and useful. That one can see in practical circumstances as useful. That one can understand for prediction. I am suspicious of the act of staring at tracts of convoluted human unfriendly systems of rules and saying in hindsight, ah, the penny has dropped. This seems to me to be a different kind of understanding than the one that can predict things. We can predict consistent behaviour as soon as we accept that: 1. The float's real estate covers that of the containing block, where both start at 0,0 (without any positioning). Either may have smaller or larger width and/or height. 2. In the instance of a float we actually 'already' have the float layered on top of the containing block with a pre-established stacking order. 3. _Without any positioning applied_ to the containing block, the float has a higher stacking order. The float is on top. 4. _With positioning applied_ to the containing block, the containing block has a higher stacking order. The float is on bottom. 5. _With positioning applied_, the stacking order may be changed by applying z-index to the containing block. Exactly right. Not sure if it answers dorayme's question, but for that you have to ask what are the reasons for wanting to bring floats and positioned boxes forward in the stacking order, and what would happen if you didn't. The idea of the rules is for the default behaviour to give you what you want most of the time. You can always z-index if you need to do unusual things. |
--
Gus
#53
| |||
| |||
|
|
Ben C wrote: [...] The common case of a float on top a box it would be underneath (if it didn't get a higher stacking level) is this kind of thing: p blah blah span style="float: left; height: 500px; width: 200px"></span blah blah /p p blah blah blah /p The float sticks out of the bottom of the first P, but is stacked on top of the second P, even though the second P comes later in the document. Assume P has a non-transparent background in this example. Even with a background color applied to the float in order to see it, |
Quote:
|
there is no stacking at all. Am I missing something? |
just that the float is stacked on top of the second P's background
instead of going behind it.
That's because floats get a higher stacking level. Consider this
alternative, with no floats:
div.p
{
background-color: red;
height: 40px;
margin: 10px;
border: 10px solid gray;
}
div.notfloat
{
background-color: green;
width: 100px;
height: 300px;
/* float: left */
}
<div class="p">
blah blah
<div class="notfloat">
not a float
</div>
</div>
<div class="p">
blah blah blah
</div>
And then uncomment float: left to see the difference.
#54
| |||
| |||
|
|
On 2008-04-06, Gus Richter <gusrichter (AT) netscape (DOT) net> wrote: dorayme wrote: I earlier gave an indication of a test for when it has sunk in for a normal human. It was a predictive one, not a hindsight one. I am still not as optimistic as you. The slight thing that worries me in my pessimism is that many browsers *do* the same thing, so someone or some group who programmed the browsers had a certain understanding of these things. However, I can't even be sure of this. It may turn out that the programmers put in a set of rules and one of the consequences is the phenomenon you raised, but it takes a blind machine to bring it out (like a not particularly intended consequence). What would be nice is a model that tells a story that is consistent and meaningful and useful. That one can see in practical circumstances as useful. That one can understand for prediction. I am suspicious of the act of staring at tracts of convoluted human unfriendly systems of rules and saying in hindsight, ah, the penny has dropped. This seems to me to be a different kind of understanding than the one that can predict things. We can predict consistent behaviour as soon as we accept that: 1. The float's real estate covers that of the containing block, where both start at 0,0 (without any positioning). Either may have smaller or larger width and/or height. 2. In the instance of a float we actually 'already' have the float layered on top of the containing block with a pre-established stacking order. 3. _Without any positioning applied_ to the containing block, the float has a higher stacking order. The float is on top. 4. _With positioning applied_ to the containing block, the containing block has a higher stacking order. The float is on bottom. 5. _With positioning applied_, the stacking order may be changed by applying z-index to the containing block. Exactly right. |
Thanks for all the explanations in this thread. I found all of them
helpful for various reasons.
On the question of predictability, to be perfectly frank, I don't *know*
this is *exactly* right because I don't know who - really - are the "we"
that Gus refers to. Or what - really - "predict" means here. Or even
quite what is to be explained (there have been a few variations on a
theme in this thread).
If browsers can go different ways on some combinations, so too might
humans. And we don't actually know if it is all consistent.
It is a difficult issue and who will have the patience to look at it! I
have this idea that the css specs set can be seen to talk to browsers
and/or to talk to the human mind. In order to talk to browsers it has to
initially talk to humans who program the browsers. We know for a fact
that humans program browsers a bit differently and so this is some
evidence that they read the same bible words differently (not complete
evidence, they may perhaps all read it the same way but are differently
beholden to pressures, commercial and other and ignore what they read).
Once instantiated in real code, we get machine predicticability. Given
the same set of circumstances, they do the same thing. Machines have
little worries or doubts about the meaning of their instructions. If
they don't understand them, they just ignore them. And if they seem to
understand them, they ipso facto do understand them and simply act on
their understanding. And we can learn the ways of this machine up to a
point. I have previously made the point in this thread that there is a
lot of agreement among browsers on a lot of things to do with visual
order and this speaks of an underlying logic.
But there is another interesting issue to do with human mental
ergonomics. The fit of html and css to the human mind is not exactly one
of the wonders of the world. Not like English which ranks up there with
the Sydney Opera House as an eighth wonder.
If you hand picked a few people and asked them to draw what they would
expect to see from various snippets of code, you would get a fair bit of
agreement on a lot of things. But what things and what are the
conditions for this imaginary experiment? Who is to be picked? Have we
picked the wrong people if they go all wobbly or differ among
themselves?
Thought experiments are one thing and real field tests are another
altogether. It is well known that the world has a bad habit of biting
the most scientific thoughts and predictions.
It is easy to say stuff in hindsight. Well, let me qualify that! It is
*not* always so easy! Some people do it brilliantly. Ben C does it
better than anyone (at least to my ears). I am not belittling the
hindsight test as much as the use of the word "hindsight" suggests. But
a hindsight test is *not* a prediction test.
And, crucially, the word "prediction" is not some piece of linguistic
magic that imprints its meaning on all mortal beings in the same way. I
say this because there will be a lot of people who think they know
*exactly* what is meant by *the rules predict the behaviour* and I am
just a little bit more skeptical.
I am not trying to be awkward. I *am* this without effort most of the
time <g>
--
dorayme
#55
| |||
| |||
|
|
Gus Richter wrote: When time permits I try some of the many variables possible. Dorayme seems to be doing likewise. I note that on alt.html dorayme is responding to a question "DIV - dynamic height" wherein she gives another variable on her referenced page: http://netweaver.com.au/floatHouse/page10.html That page should be included in this thread as well. The terminology of nuclear family should be removed, however, and replaced with "containg block" and "floats". IMHO of course. |
be useful on the phenomenon you have raised. (btw, I accept now that
there are reasonable explanations for what goes on).
In that particular page, the word "nuclear" was doing a particular job.
I won't explain it here.
______________________
On the question of z-indexing, dorayme is going to do a job for itself
in its very own language to have a parallel scheme that makes more
intuitive sense to normal martians (that have hearts and blood running
in their veins) and keenly listens to you all to make sure that nothing
in my stories ever results in anything but sure predictions of webpage
phenomena.
I don't exactly enjoy thinking in terms of the css rules, they are
martian unfriendly and I am thinking that humans maybe are some kind of
robot underneath. I look at humans for tell-tale signs of oil leaks and
fancy every bump on their backs under their clothes is a sign of a
clockwork wind-up key. I swear on both my antennae that I heard an
Australian Lifesaver the other day mumble in a machine monotone the
float rules as he patrolled up and down Coogee beach.
--
dorayme
#56
| ||||||||
| ||||||||
|
|
In article <slrnfvordn.6kn.spamspam (AT) bowser (DOT) marioworld>, Ben C <spamspam (AT) spam (DOT) eggs> wrote: On 2008-04-06, Gus Richter <gusrichter (AT) netscape (DOT) net> wrote: [...] We can predict consistent behaviour as soon as we accept that: 1. The float's real estate covers that of the containing block, where both start at 0,0 (without any positioning). Either may have smaller or larger width and/or height. 2. In the instance of a float we actually 'already' have the float layered on top of the containing block with a pre-established stacking order. 3. _Without any positioning applied_ to the containing block, the float has a higher stacking order. The float is on top. 4. _With positioning applied_ to the containing block, the containing block has a higher stacking order. The float is on bottom. 5. _With positioning applied_, the stacking order may be changed by applying z-index to the containing block. Exactly right. Thanks for all the explanations in this thread. I found all of them helpful for various reasons. On the question of predictability, to be perfectly frank, I don't *know* this is *exactly* right because I don't know who - really - are the "we" that Gus refers to. Or what - really - "predict" means here. Or even quite what is to be explained (there have been a few variations on a theme in this thread). If browsers can go different ways on some combinations, so too might humans. And we don't actually know if it is all consistent. It is a difficult issue and who will have the patience to look at it! I have this idea that the css specs set can be seen to talk to browsers and/or to talk to the human mind. In order to talk to browsers it has to initially talk to humans who program the browsers. We know for a fact that humans program browsers a bit differently and so this is some evidence that they read the same bible words differently (not complete evidence, they may perhaps all read it the same way but are differently beholden to pressures, commercial and other and ignore what they read). |
get it wrong (bugs), sometimes they have something that's almost right
and mostly works (and may pre-date the spec) and that's a lot of risk to
change.
Occasionally they ignore the spec deliberately where it just seems
wrong-headed, but this is rare these days with CSS.
Quote:
|
Once instantiated in real code, we get machine predicticability. |
Quote:
|
Given the same set of circumstances, they do the same thing. |
contents of uninitialized memory (i.e. whatever was left there by the
last program that used that bit of memory), and things well outside the
scope of what you thought was the input you were giving the program.
Quote:
|
Machines have little worries or doubts about the meaning of their instructions. If they don't understand them, they just ignore them. |
Quote:
|
And if they seem to understand them, they ipso facto do understand them and simply act on their understanding. And we can learn the ways of this machine up to a point. |
code, although this is effectively what some web developers have had to
do to improve predictability with IE.
The best advice for any web developer targetting crappy browsers is to
try to stick to the subset of the specification that does work. If you
find something that doesn't work as you expect check whether it's
actually wrong according to the spec. If it is, don't try to
second-guess it, reverse-engineer it, or touch it with a bargepole but
find some other way of doing it.
If it is wrong according to the spec it's more likely to be different in
different browsers and also in newer releases of the same browser.
Quote:
|
I have previously made the point in this thread that there is a lot of agreement among browsers on a lot of things to do with visual order and this speaks of an underlying logic. But there is another interesting issue to do with human mental ergonomics. The fit of html and css to the human mind is not exactly one of the wonders of the world. Not like English which ranks up there with the Sydney Opera House as an eighth wonder. If you hand picked a few people and asked them to draw what they would expect to see from various snippets of code, you would get a fair bit of agreement on a lot of things. But what things and what are the conditions for this imaginary experiment? Who is to be picked? Have we picked the wrong people if they go all wobbly or differ among themselves? |
always what you want in another.
Take floats for example: when people use them for columns they are
surprised that the container doesn't make any height for them.
But if someone were using them to embed figures in paragraphs of text,
they would be equally surprised and annoyed if each container stretched
to fit the floats leaving big gaps between the text in each paragraph.
How to avoid annoying surprises is one of the difficult things about
designing any kind of human/machine interface.
Broadly there are two schools of thought here. Do you make a simple but
powerful system for which people have to read the manual and write
correct input (but it's for their own good), or do you give them lots of
features to do every little thing and accept any input with hidden rules
for "doing what they mean"?
Compare your old camera which had one dial for shutter speed and one for
aperture with your new one which replaced them with a button for
mountains, another one for people in front of mountains, one for the sun
rising over the same mountains, one for pictures of galloping horses,
people wearing large hats, tulips, skyscrapers, the moon, etc.
HTML/CSS seems to ended up with a bit of both design policies, to the
point where some authors are using obscure side-effects of overflow:
hidden because they understand what the machine is supposed to do and
others are setting vertical-align: middle on DIVs because they want them
vertically aligned to the middle of something.
Quote:
|
Thought experiments are one thing and real field tests are another altogether. It is well known that the world has a bad habit of biting the most scientific thoughts and predictions. It is easy to say stuff in hindsight. Well, let me qualify that! It is *not* always so easy! Some people do it brilliantly. Ben C does it better than anyone (at least to my ears). |
Quote:
|
I am not belittling the hindsight test as much as the use of the word "hindsight" suggests. But a hindsight test is *not* a prediction test. And, crucially, the word "prediction" is not some piece of linguistic magic that imprints its meaning on all mortal beings in the same way. I say this because there will be a lot of people who think they know *exactly* what is meant by *the rules predict the behaviour* and I am just a little bit more skeptical. I am not trying to be awkward. I *am* this without effort most of the time <g |
are the way they are. There is some kind of rationale for most of it and
if you can figure it out there's much more chance you can implement it
correctly as a programmer or find the simplest ways to get the rendering
effects you want as an author/designer.
#57
| |||
| |||
|
|
On 2008-04-08, Gus Richter <gusrichter (AT) netscape (DOT) net> wrote: dorayme wrote: I am inclined to actually use the phrase "containing block" where the context shows it to do a job of containing. Because the point is that it is the container, the parent, the big house where the children live... It is crucial that it is on the container, the parent, that rel pos is made for the abs to work. And I find it interesting how the "layers" work and yet the float still exerts the influence to push aside (displace) the text or pics in the following divs. Just had never thought of the float rules operating from a smothered "underneath" position! Those float rules are powerful voodoo huh? <g 1. Any floated item will be out of the normal flow. 2. When floated left, it will position itself to top,left (0,0) of its "container block". 3. The special feature of a float is that any inline box content in the "container box" will shift over to make room for the float. 4. Blah, blah, blah, blah. You are having difficulty in accepting the container thing, so try asking yourself: "If the float positions itself to 0,0 of the container block, then what could be the container block?" Sometimes 0,0 of more than one container blocks occupy the same pixel on the screen, so this is not a good criterion. body float div In this example, 0,0 of div and body are in the same place because of margin collapsing. So which is the containing block for the float? Body, not the div, because it's the block level ancestor as specified. |
My explanation of 0,0 of the container block fits simplistically.
The following condenses the spec a little more in detail:
1. Any floated item will be out of the normal flow.
2. A float will position itself to the _top_ of any "block", "float" or
"line box" earlier in the source (further rules are provided in the case
of collapsing margins).
3. When floated left, it will position itself to the _left_ of its
"containing block" and when floated right, it will position itself to
the _right_ of its "containing block" (further rules are provided in the
case of collapsing margins).
[A "Containing Block" is a generated box for the content/descendants
and the containing block's behavior is determined by the "type" of box
generated.]
4. The special feature of a float is that any inline box content in the
"container box" will shift over to make room for the float.
Caveat: Although I "got it" when I wrote it, I find on re-reading that I
have to reference the spec (bad part: in several different chapters) to
see what I was talking about. So it needs quite a few more re-reads for me.
--
Gus
#58
| ||||
| ||||
|
|
The following condenses the spec a little more in detail: 1. Any floated item will be out of the normal flow. 2. A float will position itself to the _top_ of any "block", "float" or "line box" earlier in the source (further rules are provided in the case of collapsing margins). |
It goes to the top of the current line box provided that putting it
there doesn't mean that the line breaks such that text before the float
ends up on the line box beneath it. In that case it goes at the top of
the next line box. Firefox 2 and IE always put it at the top of the next
line box anyway although this is technically wrong.
Quote:
|
3. When floated left, it will position itself to the _left_ of its "containing block" and when floated right, it will position itself to the _right_ of its "containing block" |
there are other floats already in the way.
Quote:
|
(further rules are provided in the case of collapsing margins). |
(well not directly, although they might influence the position of other
floats).
[...]
Quote:
|
4. The special feature of a float is that any inline box content in the "container box" will shift over to make room for the float. |
<div>
<tall float that sticks out of the bottom>
</div>
<div>
This text will shift over to make room for the float in the div
above.
</div>
#59
| |||
| |||
|
|
On 2008-04-07, Gus Richter <gusrichter (AT) netscape (DOT) net> wrote: [...] In my examples, "wrapper" and "containing block" are two different things. The "wrapper" is simply used to reposition the segment pairs. In your examples in the link I mention above, you use headings to accomplish this w/o wrappers. The "containing block" is each one of the yellow boxes in every one of your examples on the page linked above (yellow boxes in my examples as well). It is a bit counter-intuitive in that normally a container comes first in the markup, but in the case with floats, the "container block" comes _after_ the float. No the containing block for a float is always above it in the document tree. |
markup/source the normal would be to have the float come _second_ as:
<div id="shrink">
<div id="float">Some text and more</div>
Some text and some more to get a few more lines.
</div>
when compared to where the float comes _first_:
<div id="float">Some text and more</div>
<div id="shrink">Some text and some more to get a few more lines.</div>
--
Gus
#60
| |||
| |||
|
|
The float sticks out of the bottom of the first P, but is stacked on top of the second P, even though the second P comes later in the document. Assume P has a non-transparent background in this example. Even with a background color applied to the float in order to see it, Perhaps it will help to give the <p>s also thick borders. The point is just that the float is stacked on top of the second P's background instead of going behind it. |
--
Gus
|
« 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.