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

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 24 Sep 2012 12:18:28 -0400
Message-ID: <506087D4.1080104@mit.edu>
To: www-style list <www-style@w3.org>
On 9/24/12 6:22 AM, François REMY wrote:
> |  De : Boris Zbarsky <bzbarsky@MIT.EDU>
> |
> |  Yes, but that depends on what one thinks of as "used value"...  Anyway,
> |  not that relevant.
>
> I thought this terminology was clearly defined by the CSS 2.1 specification :-)

It ... really depends.  :(

> |  That's not necessarily all there is to it, actually.  As a simple example, in
> |  Gecko each element has an object correponding to it that encapsulates its
> |  computed style.  This object has a pointer to the object of the same type it
> |  should inherit styles from.  Any time style is recomputed in a debug Gecko
> |  build there is a post-condition that asserts that none of these objects have
> |  stale "parent style" pointers. This postcondition would fail unless computed
> |  style were actually updated across the whole tree.
>
> Ok, I see. This issue could be managed easily in the case I've in my mind without
> even reworking that condition, since the inner and outer layouts would live in
> different worlds and would not see each other very closely.

I don't follow that.  How are they "living in different worlds"?

> I mean, we already have that working for iframes. When you change the layout
> of the page in the frame, you don't have to udpate the layout of the parent
> page (well, I think, at least).

Sure.  There's also all sorts of other stuff that's separate for 
iframes: stuff inside them does not affect the layout of anything else 
on the page (which is not true for abspos things), separate JS global, 
separate set of style information altogether, etc.

It would be possible to define some iframe-like things, obviously.  It'd 
just take some rearchitecting to implement them.

> Also, I think this is true the other way around at least
> if the size of the content box of the iframe isn't updated. I should make a test about
> that to be sure, though.

Yes, if the iframe size doesn't change relayout in it doesn't have to be 
done.

> My idea would be to replicate that kind of mechanism withing a single document

OK.  It would need to not allow visible overflow, and make certain 
guarantees about its behavior, but it could be done in general.  On the 
actual implementation end, in Gecko, it'd be a huge amount of work, I 
suspect.  :(

-Boris
Received on Monday, 24 September 2012 16:18:59 GMT

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