W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: Issue 101 Resolution

From: Alan Gresley <alan@css-class.com>
Date: Thu, 07 Oct 2010 15:57:55 +1100
Message-ID: <4CAD5353.7000006@css-class.com>
To: Bert Bos <bert@w3.org>
CC: www-style list <www-style@w3.org>
Bert Bos 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?


To make the spec reflect reality.


> It's just an implementation bug, isn't it?


No, it's a result that may be due to browsers following rule 1.


   | The left outer edge of a left-floating box may not be to the
   | left of the left edge of its containing block. An analogous
   | rule holds for right-floating elements.


Gecko was the first to honor this rule way back in 2008. IE8 followed 
Gecko behavior, then WebKit and finally Opera this year for cases in 
LTR text flow. WebKit just has to fix up both RLT cases and Opera just 
the last RTL case (float left in RTL) [1].


> One among others. It is only since version 3.5 or so that 
> Firefox is able to handle left floats at all.


What? Is this to do with inline boxes or whitespace?


> 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.


How about we just get those 9 rules fixed for 9.5.1.


> The bug is probably the result of an "optimization" that wasn't thought 
> through correctly.


This is just like the empty substring attribute selectors matching. It 
where the spec does not match the reality.


> 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.


It is IE8 and IE9 beta that does not having the same rendering.


> You cannot change a standard that has been stable and implemented.


Are we talking a real world computations of a CSS standard that was 
prose wrongly in the beginning. This is why it was wise to leave thing 
undefined until CSS2.1 was interoperable (post IE8) and now we can 
better define CSS2.1.


> That 
> would be irresponsible. And foolish, if you want to remain in business.


Tell the W3C that CSS2.1 will reach REC eventually. Do you truly 
comprehend what you created back in 1996? Do you realize that the 
fruits of this are only now just starting to happen?


> 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.


That is why we must look at those 9 rules of 9.5.1.


> 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.
> 
> 
> 
> Bert


The last case is why people have wanted float center. What the web 
design community need to understand is that centering can alway break 
since horizontal overflow only happens in one direction.


1. 
<http://css-class.com/test/css/bidi/visible-overflow-containing-block-ltr.htm>


-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Thursday, 7 October 2010 04:58:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:32 GMT