W3C home > Mailing lists > Public > www-style@w3.org > February 2009

Re: [css, bug of specification] negative margins, painting order, stacking context.

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Sat, 7 Feb 2009 17:16:25 +0100
Message-ID: <65307430902070816p2de76086g38df4f963d7345ac@mail.gmail.com>
To: Andrew Fedoniouk <news@terrainformatica.com>, www-style@w3.org
Trying to follow from the CSS3 version of stacking contexts (css3-box, sect
14 Stacking Contexts [1]):

1) if the element is the root (that for an HTML document is <body>), paint
the background => white
4) for all in-flow, non-positioned block-level children, paint background =>
first a red box, then a green box
7) first for the element, then for all in-flow, non-positioned block-level
children
7.2) for each line box in the element => line boxes: "This text", "has red",
"background"
7.2.1) for each box child of that element, in that line box, of that line
box => anonymous inline box "This text"
7.2.1.4.1.1) for an inline element, if it is a run of text
7.2.1.4.1.1.3) [draw] the text

Ok, the algorithm is awfully complex, but it works.

And for what concerns :hover: "CSS doesn't define which elements may be in
the above states, or how the states are entered and left" (CSS21, sect
5.11.3 Dynamic Pseudo Classes [2])

Giovanni

[1] http://www.w3.org/TR/css3-box/#stacking
[2] http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes

2009/2/6 Andrew Fedoniouk <news@terrainformatica.com>

>
> As we know[1]  rendering of static children of elements happens in
> following order:
>
> for all static children:
>  step #1: draw backgrounds of these elements;
>  step #2: draw content of these elements (text in particular);
>
> This algorithm (strange, imo) works in most cases but plays
> badly with negative margins.
>
> Here is an example of very strange (non-intuitive if you wish) effect that
> can
> be observed when negative margins are used:
>
> <html>
> <head>
>  <style>
>   div.red     {  width:100px;    height:100px;    background-color:red;
> margin-bottom:-100px;    }
>   div.green  {  width:90px;      height:90px;      background-color:green;
>    }
>   div.red:hover { background-color:orange;  }
>   div.green:hover { background-color:lime;  }
>  </style>  </head>
> <body>
>  <div class="red">This text has red background.</div>
>  <div class="green"></div>
> </body>
> </html>
>
> Problem here is that due to [1] these two elements have non-trivial
> overlaying structure.
> Each point inside div.green participate in following layers:
>
> 1) background of  div.red
> 2) background of  div.green
> 3) content(text) of  div.red
> 4) content(text) of  div.green
>
> This clearly produces logical errors in detection of div.red:hover and
> div.green:hover
> conditions. Try to move mouse over and near the text.
>
> That appears as a bug of the specification.  Non-intuitive, non-logical,
> etc.
>
> Possible resolutions of the problem:
>
> A) To change [1] so drawing of the element background and its content is
> atomic:
>
>   For each static child draw its background and content(text) on top of it.
>   (That  is how it is made in all UI systems I know)
>
> If this change is not desirable at this point then plan "B":
>
> B) Treat all elements having negative margins as a separate layer laying
> over
>   normal static children of the element thus rendering will happen this
> way:
>
>  step #1, for all static children *without* negative margins do:
>     step #1.1: draw backgrounds of elements;
>     step #1.2: draw content of elements (text in particular);
>  step #2, for all static children *with* negative margins do:
>     step #2.1: draw backgrounds of elements;
>     step #2.2: draw content of elements (text in particular);
>
> Mouse hover detection algorithms have to be updated accordingly. In both
> cases.
>
> [1] http://www.w3.org/TR/CSS21/zindex.html
>
> --
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>
>
>
>
Received on Saturday, 7 February 2009 16:17:00 GMT

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