W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-regions][css3-gcpm] Thoughts on Plan A and Plan B

From: Dimitri Glazkov <dglazkov@google.com>
Date: Wed, 15 Feb 2012 13:26:29 -0800
Message-ID: <CADh5Ky1XWjXWKq=ky0FycK2_KsXVJGqBPzJmMna0CuRoBpbe1g@mail.gmail.com>
To: David Hyatt <hyatt@apple.com>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org Style" <www-style@w3.org>
On Wed, Feb 15, 2012 at 12:12 PM, David Hyatt <hyatt@apple.com> wrote:
> On Feb 15, 2012, at 1:59 PM, David Hyatt wrote:
>> I think using explicit elements or shadow elements is the worst of the solutions I listed. While I put it on the list for completeness, it's not my preferred choice. I'd be careful about pushing a shadow DOM agenda with this feature, as I don't think it's a particularly good fit. There is value to being able to create anonymous boxes in CSS without backing them with DOM elements.
> Just to expand on this point, in WebKit, a column in CSS multi-column is super lightweight. It has no unique renderer. It has no DOM element. It doesn't take up any memory at all. When columns have uniform widths and heights, you can do crazy fast hit testing, selection, painting, etc., because knowing what column you're in is just math. Typically you don't even need to store individual column rects
> CSS Regions are full of similar potential optimizations. They can have uniform widths, uniform heights, not use any unique styling, etc.
> If you look at an 800 page textbook that has on average 3-4 regions per page, making shadow DOM elements for all those regions from a performance perspective starts looking pretty stupid. Do you really want 2400 extra DOM nodes in your document, shadow or otherwise, just to handle a textbook that uses no more than 10 different types of pages that each have simple 2-3 column layouts with a figure or two? No way.

I don't mean to derail this discussion, but actually, if we could
support multiple render boxes per DOM element, we could get away with
having just 10 DOM subtrees for each page type, and then project the
render tree into the right places as many times as necessary.

> We need to avoid falling into the more heavyweight DOM if at all possible. Anonymous boxes can be optimized away, handled however we want, etc. DOM elements can't. They bring along too  much baggage. Let's keep performance and memory use in mind here and not make the mistake of requiring the DOM for simple page templates.
> dave
> (hyatt@apple.com)
Received on Wednesday, 15 February 2012 21:26:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:12 UTC