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