On Jan 27, 2014, at 1:05 PM, Dimitri Glazkov <dglaz...@google.com> wrote:
> On Fri, Jan 24, 2014 at 5:53 PM, Ryosuke Niwa <rn...@apple.com> wrote: > On Jan 23, 2014, at 2:45 PM, Dimitri Glazkov <dglaz...@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 Thanks. On the surface, guaranteeing that certain elements, e.g. pending stylesheets, will block the painting seems valuable, but I don’t see howe can spec. that. For example, WebKit waits for the pending stylesheets but it can timeout at some point and paint the contents anyways. In general, UAs use various heuristics to determine when a page is ready to be shown to the user, and I don’t think we want to necessarily spec that. We also need to be extremely careful not to preclude future optimizations and improvement such as doing layout and painting in parallel and reducing FOUC as this area has historically allowed UAs to innovate. - R. Niwa
