W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

Re: [whatwg] allow <link> in body + DOM position as a rendering hint

From: Ilya Grigorik <igrigorik@gmail.com>
Date: Wed, 5 Nov 2014 09:44:45 +0900
Message-ID: <CAKRe7JGPkkuvSuxkGo7J-E4maxVOwuyr+oii8nvqpTb1Hk0=yw@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Jeremy Keith <jeremy@adactio.com>, WHATWG <whatwg@whatwg.org>, Domenic Denicola <d@domenic.me>
On Wed, Nov 5, 2014 at 9:08 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

> > Re, re-evaluation previous elements: note that UA *can*, just as it does
> > today (modulo some error conditions), hold painting until it finds all
> the
> > stylesheets, regardless of the <link> position in the document. So,
> > assuming that's the default behavior, allowing <link> in body doesn't
> > change anything short of reflecting what developers are already doing.
> That
> > said, the UA *could* use the position of the <link> element in the body
> as
> > a hint to optimize how it renders -- the exact logic here is deferred to
> > the UA... Similarly, assuming UA follows the render-optimization
> heuristic,
> > the developers *can* optimize the content of the positioned stylesheets
> to
> > minimize reflows, etc.
> I talked more with a rendering & layout expert in our team, and he pointed
> out that we may need to add a new attribute to trigger this behavior since
> many existing websites have link elements to load stylesheets that affect
> contents above it.  But that should be a relatively simple &
> straightforward change to the proposal.

Makes sense, Jason (IE) also mentioned that we might need some <meta>
opt-in flag, or some such... That said, before we go there, I'd love to see
if we can gather some data on potential impact of making this opt-in vs

Received on Wednesday, 5 November 2014 00:45:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:26 UTC