- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Mon, 27 Jan 2014 13:05:12 -0800
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: public-webapps <public-webapps@w3.org>
- Message-ID: <CADh5Ky1bs0u+D6b-7jzvmQiJ3GRj0xzVfnOww+-=OEhqN13avQ@mail.gmail.com>
On Fri, Jan 24, 2014 at 5:53 PM, Ryosuke Niwa <rniwa@apple.com> wrote: > On Jan 23, 2014, at 2:45 PM, Dimitri Glazkov <dglazkov@google.com> wrote: > > As HTML imports [1] are implemented across browsers, there’s a potential > for diversity of opinion in how rendering of documents with imports occurs. > What blocks rendering? > > What doesn’t? To prevent the inevitable pain of converging on a de-facto > standard behavior, it would be super-nice to have precise documentation of > when the rendering engine should start (and stop) rendering the document. > > I don't think we want to expose when rendering / painting / style > resolution happens to the Web just like we don't want to expose GC timing > to the Web. e.g. it makes the UAs much more vulnerable against the timing > attacks. If the HTML imports specification exposes such timing, then we > should "fix" that so that we expose such timing. > > But before jumping to conclusions, could you clarify how exactly HTML > imports creates a dependency on the rendering timing? > There was a long thread around this subject in November: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/thread.html#msg476, which culminated in realization that developers ultimately want control over rendering: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0607.html The whole thread is worth the read, though. :DG<
Received on Monday, 27 January 2014 21:05:39 UTC