height in floats

In article <slrnfjmqh3.gpr.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2007-11-14, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
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.

So does Firefox: i.e it's the same code, not a coincidence.

Yes, I did know this, I was just mentioning about Camino. It is
relevant to the surprise I mentioned in that it was an extra
opportunity to do something about the "wrong" following of the
specs on floats (by the Camino makers). A missed opportunity. But
perhaps the makers were only interested in porting it to Mac (it
is blazingly fast as a result as compared to the seemingly
bloated FF!) and no more than that.

It is as if these deviations from the standards are set in stone!

Well some things in the specification are a bit silly, although not this
particular one.

Just looking at how Safari and Opera treats the order of inlines
with floats, I agree. For one thing, it looks easier to remember
and work with how Safari and Opera treats the code on page 6 of
that thing I made (http://tinyurl.com/2slyy4). And if that is how
the standards in CSS 2.1 dictate it, then that is is how FF
should do it, if you hear of any specific reasoned reluctance the
developers have on this score, please do mention it, it is
interesting.

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?

I guess the point is that the css 2.1 recommendations have a
certain indeterminancy and different browsers do their best to
juggle the competing claims that arise... <g>

--
dorayme

On 2007-11-15, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <slrnfjmqh3.gpr.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:
[...]
Just looking at how Safari and Opera treats the order of inlines
with floats, I agree. For one thing, it looks easier to remember
and work with how Safari and Opera treats the code on page 6 of
that thing I made (http://tinyurl.com/2slyy4). And if that is how
the standards in CSS 2.1 dictate it, then that is is how FF
should do it, if you hear of any specific reasoned reluctance the
developers have on this score, please do mention it, it is
interesting.

I'm sure it isn't reluctance, just how do they put all the bugs and
things they've got to do into priority order.

One can probably find the bug in bugzilla and see what the comments
are.

Aha, here it is: https://bugzilla.mozilla.org/show_bug.cgi?id=50630

Raised 2000-08-28. Priority is P1 (most important), Target Milestone is
"Future".

They describe the bug and quickly get to the bottom of it.

Then they work out that it's not so simple because you may have to
reflow the line you've just started.

Then in early 2003 David Baron says that in spite of that, fixing it
shouldn't be that hard. About an hour later he returns to say that it's
actually pretty messy. Nothing much happens after that, except lots of
duplicates are reported. It's good to see that our friend Gérard Talbot
is also involved.

Someone does mention that IE does the same thing, but it isn't an issue.

It looks to me like the main reason it hasn't been fixed yet is it's
actually a bit tricky to do, which reduces the number of people who
could fix it without breaking anything else.

In article <slrnfjo17k.m63.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2007-11-15, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
In article <slrnfjmqh3.gpr.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:
[...]
Just looking at how Safari and Opera treats the order of inlines
with floats, I agree. For one thing, it looks easier to remember
and work with how Safari and Opera treats the code on page 6 of
that thing I made (http://tinyurl.com/2slyy4). And if that is how
the standards in CSS 2.1 dictate it, then that is is how FF
should do it, if you hear of any specific reasoned reluctance the
developers have on this score, please do mention it, it is
interesting.

I'm sure it isn't reluctance, just how do they put all the bugs and
things they've got to do into priority order.

One can probably find the bug in bugzilla and see what the comments
are.

Aha, here it is: https://bugzilla.mozilla.org/show_bug.cgi?id=50630

Raised 2000-08-28. Priority is P1 (most important), Target Milestone is
"Future".

They describe the bug and quickly get to the bottom of it.

Then they work out that it's not so simple because you may have to
reflow the line you've just started.

Then in early 2003 David Baron says that in spite of that, fixing it
shouldn't be that hard. About an hour later he returns to say that it's
actually pretty messy. Nothing much happens after that, except lots of
duplicates are reported. It's good to see that our friend Gérard Talbot
is also involved.

Someone does mention that IE does the same thing, but it isn't an issue.

It looks to me like the main reason it hasn't been fixed yet is it's
actually a bit tricky to do, which reduces the number of people who
could fix it without breaking anything else.

I see. It's hard. I am starting to get the idea that there is an
inadvertant thing involved, a bug. Whereas I had been thinking
some deliberate decision and argument was entered into by the
developers!

Yes, Talbot does take a keen interest in these things and that is
something I have come to respect a lot.

--
dorayme