On Fri, Mar 22, 2013 at 3:17 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Friday 2013-03-22 12:42 -0400, Boris Zbarsky wrote:
> > >Hm, ok. Well then, we should investigate the <iframe> behavior, and
> > >see if it's okay to duplicate, perhaps with my suggestion of an opt-in
> > >way to get the more expensive "true" value out of getComputedStyle.
> >
> > So I just double-checked, and at first glance UAs now seem to do the
> > right thing with <iframe> in general (though I can't quite tell why
> > from code inspection...).
>
> In Gecko, it's because of this code:
>
> https://hg.mozilla.org/mozilla-central/file/3825fdbcec62/content/base/src/nsDocument.cpp#l6968
> which ensures that anything that requires up-to-date style in an
> iframe ensures up-to-date layout of the parent first.
>
>
For the record and not strictly apropos this thread, there's no such code
in WebKit, and as such WebKit will (sometimes) return the wrong answer when
querying computed style. For instance, adding a class to an ancestor of an
<iframe> that would cause it to be display:none and then querying computed
style or layout on an element inside the <iframe> will inconsistently
return 0 or actual values depending on if styles have been flushed outside
the <iframe>. I consider this a bug in WebKit.
- James
-David
>
> --
> 𝄞 L. David Baron http://dbaron.org/ 𝄂
> 𝄢 Mozilla http://www.mozilla.org/ 𝄂
>
>