Re: Shadows vs. layout

On 3 Aug 2009, at 20:18, L. David Baron wrote:

> On Monday 2009-08-03 13:55 -0500, David Hyatt wrote:
>> On Aug 3, 2009, at 1:54 PM, Boris Zbarsky wrote:
>>> David Hyatt wrote:
>>>> You're saying the engine has to track shadows as visual overflow  
>>>> for
>>>> the purposes of accurate container repainting, but then somehow
>>>> track a completely second set of visual overflow numbers that
>>>> exclude shadows just to ensure that you don't include shadow
>>>> overflow when scrolling?
>
>>> Note that Gecko is planning to do just that; it's needed anyway to
>>> deal with fonts where glyphs don't fit inside their claimed bounding
>>> box (unless you think that that situation should also trigger
>>> scrollbars, basically any time you have justified text in such a  
>>> font
>>> and such a glyph at end of line?).
>>
>> I do think it should trigger scrollbars yes.
>
> I seem to recall we tried this and it broke pages by triggering
> scrollbars in too many places, but roc would probably know for sure.
> I haven't been able to find the relevant bug reports...


See for example https://bugzilla.mozilla.org/show_bug.cgi?id=503718

Note that the main cause of problems is not glyphs such as an italic  
'f' that clearly project beyond their advance width. These are  
relatively uncommon, and it may be acceptable for them to potentially  
cause scrolling, although I'm not at all sure it's a good thing. But  
the real problem comes from glyphs whose "true" outline does *not*  
project, but where antialiasing causes "overflow" pixels to be  
painted. We have some drawing problems that arise from failing to  
paint or refresh such pixels properly (so does Safari, FWIW, though  
the worst issues occur on Windows with ClearType, so they may not be  
seen so clearly or often in Safari). Attempting to fix this by  
ensuring these pixels are included in overflow calculations is what  
led to widespread problems.

It seems to me that shadows like the "blur" of antialiasing in that  
they should (of course) be painted accurately and completely (wherever  
they fall within the visible area), but they should not contribute to  
the "structural" size of the element that is relevant for scrolling  
calculations. This does seem to imply two distinct types of "overflow".

JK

Received on Monday, 3 August 2009 19:54:52 UTC