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

Re: Used Style Computation (and Viewport/Canvas Layout)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 23 Sep 2012 09:01:33 -0700
Message-ID: <CAAWBYDBwgzKXznLoKkiCOhjKV-C6ZE0TtyVDEaH4M6qo-VVDRQ@mail.gmail.com>
To: François REMY <fremycompany_pub@yahoo.fr>
Cc: CSS WG <www-style@w3.org>
(Heh, though I'm still converting your email to plain text, you're one
of the only people I've ever seen on the W3C lists who use HTML email
for good rather than evil. ^_^ )

On Sun, Sep 23, 2012 at 6:46 AM, François REMY
<fremycompany_pub@yahoo.fr> wrote:
> I have a (probably implementation specific) question to ask to people in
> known of actual browser implementations.
> Suppose I have a “display: block; position: relative; width: 100px; width:
> 100px;” element whose every child is “position: absolute” (see picture). [1]
> Its used style doesn’t depend on the used style of its children (nor
> should it even depend on their existence), right?

*Almost*. I think the abspos children might generate scrollbars on the
parent, which can affect its layout.

> Would it be possible for a browser to “give” to me the used style of that
> element (let’s say I can use a debugger to stop the program execution
> anywhere and look at the memory) without actually having done the
> computation of the children’s used style?
> If not, would it be possible to refactor the browser’s code to achieve
> that (for example by creating a new ‘display: viewport’ layout that would
> have that property no matter what (ie: knowning for sure that the layout of
> children don’t have to be computed to compute the parent layout, a bit like
> in the case of a seamless iframe but without actually creating a new
> document))?

I'm working on a proposal that I'll bring to the list soon about this
exact problem, actually.  It's part of a solution to the problem of
very long lists in the DOM, and getting them to react and scroll

Received on Sunday, 23 September 2012 16:02:21 UTC

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