W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: The :min-width/:max-width pseudo-classes

From: James Robinson <jamesr@google.com>
Date: Fri, 22 Mar 2013 16:35:08 -0700
Message-ID: <CAD73mdKaFzT8jMG8htAYy0Q2U9e_LA3uNiDDR0iNs-=9=ozVxA@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
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/   𝄂
>
>
Received on Friday, 22 March 2013 23:35:36 GMT

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