Re: Shadows vs. layout

On Aug 3, 2009, at 4:57 PM, fantasai wrote:

> David Hyatt wrote:
>> Having two types of overflow means that when it comes time to  
>> calculate scroll dimensions, you have to omit the shadow  
>> information.  This means that overflow information that is  
>> propagated to containers now has to come in two flavors...  the  
>> overflow information *has* to be cached for efficient dirty rect  
>> intersection testing on repaints, so you're left with the choice of  
>> either caching two sets of propagated numbers or just not using the  
>> cached numbers when computing scroll information.   The first  
>> solution will impact memory.  The second solution will impact  
>> performance.  Neither solution makes me very happy as an implementor.
>
> Usually both sets will coincide. If you've got free state bits, you  
> can
> store the more unusual data in a property-table and only look it up  
> when
> needed. Gecko does this for certain types of overflow data.

Yeah, we do something similar.  That of course incurs a performance  
hit since you have to do lookups to get to the data, but we would  
probably do this if the decision is made that there's going to be this  
weird new kind of overflow.  I'm scared of text-shadow too.... e.g.,  
you're talking about a potentially large map if text-shadow is used  
heavily on a page.

I still think a sentence or two in the shadow section of CSS3  
backgrounds/borders is not the way to specify this.  It's a new type  
of overflow that is going to be a core part of the definition of that  
property, and so needs to be specified in the definition of overflow  
(that backgrounds/borders can then reference).

dave
(hyatt@apple.com)

Received on Monday, 3 August 2009 23:05:17 UTC