W3C home > Mailing lists > Public > www-style@w3.org > March 2008

RE: CSS WG - Pulling Back the Curtains

From: Alan Gresley <alan@css-class.com>
Date: Fri, 28 Mar 2008 09:05:40 -0700
To: Anne van Kesteren <annevk@opera.com>
cc: www-style@w3.org
Message-ID: <20080328090540.f8d1e42eb1f8db40312f41775502f7f0.a00e964ab8.wbe@email.secureserver.net>

Anne van Kesteren wrote:


> On Fri, 28 Mar 2008 03:54:35 -0700, Alan Gresley <alan@css-class.com>  
> wrote:
> > The above was written on the 23rd of Jun 2007 (the rate of change is  
> > remarkable). I only have one question at this point. Does CSS2.1 have  
> > holes in it that are just so big that they are just being overlooked on  
> > purpose?
> 
> There are things that are not adequately covered, such as the table model.  
> But that's not overlooked on purpose, that's just delayed for CSS3 to  
> solve.
> 
> Things that the WG does consider solvable for CSS 2.1 are fixed, such as  
> the various parsing issues raised on this list. Furthermore, since all  
> technical discussion happens in public and we've two implementors who do  
> their work in public intentionally hiding "big holes" seems rather tricky.  
> Is there a particular reason why you raise this concern?
> 
> 
> -- 
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>


Parsing is brilliant, tables are trick anyway. It's more the basic layout principles.



9.4.1 Block formatting contexts

http://www.w3.org/TR/CSS21/visuren.html#block-formatting


9.4.1 Block formatting contexts (part of 3rd paragraph):

#In a block formatting context, each box's left outer edge 
#touches the left edge of the containing block. This is true 
#even in the presence of floats, unless the box establishes a 
#new block formatting context.

This has been changed to - 
http://www.w3.org/TR/CSS21/changes.html#q54
C.2.47 Section 9.4.1 Block formatting contexts

|In a block formatting context, each box's left outer edge 
|touches the left edge of the containing block. This is true 
|even in the presence of floats, except boxes that establishes 
|a new block formatting context.

Can the change please be updated in the spec for 9.4.1 (the easy found one so others to hunt down the changes).


So with my test case.

http://css-class.com/test/css/viseffects/overflow-box-next-to-float2.htm

Firefox and now IE8 is following this (the changed version) to the letter but at the same time this spec is suppose to cover where overflow it not just simple overflow.

http://css-class.com/test/css/viseffects/overflow4.htm


It all gets murky with.

10.3.3 Block-level, non-replaced elements in normal flow

http://www.w3.org/TR/CSS21/visudet.html#blockwidth

and this test case (resize so each test is 400px wide).

http://css-class.com/test/css/viseffects/overflow-auto-with-inner-box.htm

No where in the spec does it mention that the margin-right of the child element should be clipped. But now Firefox3, Safari 3, IE8 all do it. Opera 9.5 has some mystery space.

My question to the implementers is, is there some weirdness happing in all browsers when we mix both floats and overflow together? I would believe that the way IE7 shows overflow in the last test case was correct since nothing was clipped (luckily IE7 had hasLayout to achieve this). Now because IE8 must clip the padding-right of an overflow box and also incorrectly clips the margin-right of the child elements now when you float the overflow box the boxes are now un-scrollable.

http://css-class.com/test/css/overflow/floated-overflow-length-with-inner-box-float.htm

I do report the frozen backgrounds but somehow now all overflows boxes can not be scrolled in IE8. Is this due to every implementation first establishing the true width of the overflowing content ( from margin edges) and the overflow box width including padding and then once this is done the padding right on the overflow box and the margin-right of the child elements are clipped?

We want IE to follow the specs to the letter but as they were trying to do so they discovered holes in CSS2.1 so instead of attempting to fixed the holes, they just copied other implementations behaviors.

All I'm am doing is asking the questions. Can the CSS WG working group publicly admit that there are holes in CSS2.1. I have heard from a second hand source that Hixie also see the holes and that we should just ignore various parts of CSS2.1. Hearing this second hand doesn't give me much faith. When I read the CSS2.1 specs regarding layout all I do is going round in circles without ever finding the answers. :-)

Alan

http://css-class.com/
Received on Friday, 28 March 2008 16:06:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:02 GMT