|
Posted by Ben C on 12/19/07 08:04
On 2007-12-19, dorayme <doraymeRidThis@optusnet.com.au> wrote:
> In article <slrnfmgfu6.99u.spamspam@bowser.marioworld>,
> Ben C <spamspam@spam.eggs> wrote:
[...]
>> >> > It is (in its unfinishedness) at:
>> >> >
>> >> > http://netweaver.com.au/floatHouse/page1.html
>> >>
>> >> That's more about float placing. I meant the other one. You had a box
>> >> with some floats in it and some parables about parents ignoring their
>> >> children.
>> >
>> > Ah... you mean:
>> >
>> > http://netweaver.com.au/floatHouseOfAlice/normalHouse.html
>>
>> Yes that's the one I was thinking of.
>>
>> > I found it still on the server. Well, that one was just an
>> > earlier version of the longer one. You have to read the longer
>> > one on a bit to see that it *is* concerned about how to think
>> > about parents, floated children and height.
>>
>> You're right, I had forgotten that. I only remembered the next bit about
>> how floats and inlines arrange themselves.
>>
>> In fact there's some good stuff there about container heights between
>> about pages 3 and 5 which might be useful to the OP to look at.
>
> I now need to incorporate some things about these block
> formatting contexts of which you (and rf) speak. Interesting
> stuff.
Yes. The idea there is that they limit the scope of floats. Usually
floats spill out of their containers and anything inline that's in the
way has to flow around them.
Block formatting contexts limit the damage. A float never sticks out of
one or into one. Clear refers to floats within your own BFC. A BFC is
the smallest guaranteed "sealed environment" for floats. All the other
rules for BFCs can be understood in terms of this basic idea.
The purpose of block formatting contexts is floats, they aren't relevant
to anything else that I can see. They might have been named "float
contexts" instead, perhaps less confusingly.
> I am thinking of ditching a lot of stuff about browser
> differences, these differences simply take up all of one's time!
Yes, good plan. That's a separate document (to put off writing until
people have stopped using IE anyway). Although you might want to make
brief mention of the Firefox/IE7 shared non-conformance of always
putting floats in the next line if there are any inlines preceding them,
since that's quite a big one.
> I wish the W3C had made their own browser to follow their own
> standards.
I think that's what Amaya was meant to be, but it is hopeless at
following the standards getting basic things completely wrong. The
authoring tool side of it is said to be not bad however if you like that
kind of thing.
> Then everyone would see at a glance how IE and Safari and FF measure
> up to the standard.
Certainly a proper reference implementation would be good. For one thing
it would prove whether it was actually possible.
[Back to original message]
|