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

Re: Shadows vs. layout

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 4 Aug 2009 11:37:59 +1200
Message-ID: <11e306600908031637g2610268fxc8be4b82a30cef41@mail.gmail.com>
To: David Hyatt <hyatt@apple.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, W3C style mailing list <www-style@w3.org>
On Tue, Aug 4, 2009 at 11:04 AM, David Hyatt <hyatt@apple.com> wrote:

> 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.
>

As Jonathan Kew mentioned earlier, if you're scrupulous about calculating
visual overflow correctly for Cleartype and even Quartz, you have to account
for overflowing antialiased pixels on almost every piece of text, so you
already have this "potentially large map". Up till now Gecko and Webkit have
been working around the problem by calculating the visual overflow
incorrectly (which does lead to visible bugs).

In Gecko we're optimizing "small" overflows by storing 4 x 8-bit "overflow
distances", one for each edge, so if your overflow is less than 255 layout
units (40 CSS pixels) we don't need to heap-allocate a property. But we
haven't turned on the proper accounting for overflowing antialiased pixels
because we started causing scrollbars to appear in many unwanted places. So
we really do have to split overflow into these two different concepts: "ink
overflow" (purely an implementation issue that does not affect scrolling),
and "layout overflow". The spec needs to define the latter precisely and
explain exactly what contributes to it.

BTW, other than glyph overflows, 'outline' overflows also need to be
excluded from "layout overflow". We have bugs filed by authors where an
element that gets an outline on focus is at the edge of an overflow:auto
element and focusing it creates an unwanted scrollbar. Basically I think
"layout overflow" for an element should be computed by unioning together the
border-boxes of all its descendants and accounting for clipping. The
definition should also clarify whether an empty border-box positioned far
away should contribute to "layout overflow" --- I think it should.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
Received on Monday, 3 August 2009 23:38:40 GMT

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