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

Re: Additional value for the visibility property

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Wed, 09 Jul 2008 21:14:44 -0700
Message-ID: <48758CB4.3040103@terrainformatica.com>
To: robert@ocallahan.org
CC: "Ph. Wittenbergh" <jk7r-obt@asahi-net.or.jp>, W3C Style List <www-style@w3.org>

Robert O'Callahan wrote:
> On Thu, Jul 10, 2008 at 6:26 AM, Andrew Fedoniouk 
> <news@terrainformatica.com <mailto:news@terrainformatica.com>> wrote:
> 
>     In this case we shall define something like "rendering is undefined"
>     for the case when transparent element has not in-flow children.
> 
> 
> Making rendering "undefined" is unacceptable when there's a perfectly 
> reasonable alternative.
> 
> You can try to write a spec for exactly what Opera does, but you'll find 
> it's significantly more complicated than just creating a stacking 
> context for the element with 'opacity'. Which is why I would argue that 
> Opera's behaviour is actually *not* more natural.
> 

Opera does simple thing for elements with opacity:
It renders only in-flow children on the offscreen buffer (layer).

As I said that requires only "in-flow" to be added to the existing spec.
Nothing else.

About 'naturality'

Imagine that you have container that become gradually visible.
Say in script: ontimer() { cnt.style.opacity += 0.1; }
It is *highly* not desirable (not natural if you wish) when it
suddenly become not a stack context container when counter will hit 1.0.
All absolute positioned children will jump to other places.
I wouldn't treat this as a natural behavior.

Consider floating round problems and you will get all bells and whistles
of the Chaos Theory.

Demand of treating opacity < 1.0 as stack context trigger is
is exactly what "significantly complicates" all things.
Like what is exact precision of opacity < 1.0 comparison that
triggers that stack context role? Any threshold?

-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Thursday, 10 July 2008 04:15:14 GMT

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