Re: Issue 101 Resolution

On Wed, Oct 6, 2010 at 12:36 PM, Bert Bos <bert@w3.org> wrote:
> On Wednesday 06 October 2010 01:48:17 Tab Atkins Jr. wrote:
>> This email is an attempt to resolve Issue 101
>> (http://wiki.csswg.org/spec/css2.1#issue-101)
>
>> Suggested Change
>> ================
>
> Why do you propose to change the spec? It's just an implementation bug,
> isn't it? One among others. It is only since version 3.5 or so that
> Firefox is able to handle left floats at all. And as recently as last
> year, right floats still didn't work in paragraphs with a non-zero
> text-indent. Should we have added a rule about floats and text indent
> to the spec? Some things apparently take time to fix.

It's a bug that every browser has, in an identical fashion.  It also
feels like it's probably in an area that would affect float-based
layouts, such that fixing it would break pages that have come to
depend on it.  Dbaron's comments in his original email seem to support
this - Moz tried to change behavior at some point, and quickly got bug
reports about it.


> The bug is probably the result of an "optimization" that wasn't thought
> through correctly. It's not intrinsic to the model and it clearly is
> possible to do correctly, as shown by several implementations that do
> not exhibit this bug.

All four major rendering engines exhibit the bug identically.  I don't
know if this was purely for bugwards compat, or what.


> You cannot change a standard that has been stable and implemented. That
> would be irresponsible. And foolish, if you want to remain in business.

You are completely correct.  Changing a stable, implemented standard
is generally a bad idea.

The point is that the standard *hasn't* been implemented here, at
least in the places that we care the most about.  Instead, some other
behavior has been implemented, and it appears that the web may have
grown around that behavior.  This change is making it so that CSS 2.1
actually matches reality.

It's possible that we could try and treat this as an evangelism issue,
but I suspect this isn't a place that's amenable to that.  I'm not the
best person to ask about that, though.


> That is true even if the changed behavior would be better in some way.
> But, in fact, it isn't better. It is much worse. It makes no sense that
> the width of the parent influences whether the two floats overlap.
> Floats shouldn't overlap in the first place. And if the parent has such
> influence, why not the grandparent? It just makes no sense at all.

I agree that this is a shitty rule.  But see above.


> Take this example. This is a little trick to center a green box, while
> there is already an orange box on the right. If there is not enough
> space for both, the green box is lowered.
>
>    <!doctype html public '-//W3C//DTD HTML 4.01//EN'>
>    <title>Test</title>
>    <style type="text/css">
>    .orange {width: 5em; height: 4em; background: orange; float: right}
>    .green {width: 5em; height: 3em; background: lime; float: left}
>    .centerwrapper {width: 5em; margin: auto}
>    </style>
>
>    <div class=orange></div>
>    <div class=centerwrapper>
>      <div class=green></div>
>    </div>
>
> (Try increasing the font size or narrowing the window until there is no
> room for green and orange side by side.) This works, both in the
> current spec and in Tab's proposed change. But in Tab's proposal only
> if the wrapper has the same width as the green box. In reality, it is
> easier to make a generic wrapper of width zero, and then the green box
> only needs to coordinate its own width and margins, as follows:
>
>    .centerwrapper {width: 0; margin: auto}
>    .green {width: 5em; margin-left: -2.5em;...}
>
> Under Tab's proposal, however, this creates overlap.
>
> I know there are other ways to get a similar effect, the best of which
> is maybe this:
>
>    .centerwrapper {text-align: center}
>    .green {display: inline-block;...}
>
> (Except that that triggers another bug in the browsers: the green box is
> slightly off-center. :-( ) But, the existence of a workaround doesn't
> mean the bug can remain unfixed.

I disagree that we should consider float-based layout tricks as a
valid use-case, except insofar as there is significant usage of such a
trick in the wild where changing behavior would break a lot of pages.
Floats are a typographic device, not a layout device, and I'm doing my
best to make sure CSS has the layout tools necessary to properly
obsolete float-based hacks such as this.

~TJ

Received on Wednesday, 6 October 2010 20:08:51 UTC