w3c / css-houdini-drafts

Mirror of https://hg.css-houdini.org/drafts
https://drafts.css-houdini.org/
Other
1.84k stars 141 forks source link

First load and render #182

Open ryanseddon opened 8 years ago

ryanseddon commented 8 years ago

So after diving into Houdini and the various specs available I'm super excited about this but am wondering what's the story around first load and render on a cold cache?

Is this like web components where if I'm not super informed about my assets loading and have no knowledge of how a browser renders does that mean If i buy into a custom layout like regions or masonry library using a layoutWorklet I could see a FOUL (Flash of Unstyled Layout) for custom layouts as on initial parse of the CSS display: layout('masonry') is discarded?

Keen to here what all your thoughts are on this.

bfgeek commented 8 years ago

Hey Ryan,

Completely agree, this is something that we need to solve more generally for the web platform.

One thing that we were thinking about (@esprehn in particular) was a promise that you could resolve once your page was ready for it's first paint. I.e.

var p = document.getFirstPaintPromise(); // TODO: Come up with a better name.

layoutWorklet.import('foo.js').then(() => {
  p.resolve();
});

This would also be alleviated once we have <link> support for worklet scripts as well but doesn't solve it completely.

Thoughts?

FremyCompany commented 8 years ago

Hi Ryan,

Technically the rendering of unstyled content is a definite possibility indeed. If you are relying on a custom layout, I think it would be a good idea to make use of definite width/height (or min-height) or even strict layout containment (to minimize layout trashing).

I guess providing an alternative layout for browsers that do not have JavaScript enabled may be necessary anyway. If you are building a webapp where this is not necessary, hiding the children by default until the layout is ready is an option (to avoid unstyled rendering).

It is not impossible we actually want to specify that layout containment is going to be the default value for custom layout, but this hasn’t been widely discussed yet. For the rendering, browsers might do like they do for web fonts and apply the visibility hiding automatically for a few seconds before giving up and showing whatever they got

Not sure what thoughts other people have about this, but this a really interesting conversation, thanks for starting it

ryanseddon commented 8 years ago

@bfgeek

One thing that we were thinking about (@esprehn in particular) was a promise that you could resolve once your page was ready for it's first paint. I.e.

Interesting I think the firstPaint/LayoutPromise() idea is a nice hook to have (definitely useful for perf metrics) but I think the declarative approach via <link> would be the most user friendly way for a consumer of a houdini based library.

@FremyCompany

It is not impossible we actually want to specify that layout containment is going to be the default value for custom layout...

So it would essentially apply contain: strict? What would happen if I override that I just get layout thrashing without being aware what I've done?

FremyCompany commented 8 years ago

Yeah if you override it, you might get layout trashing. I guess if you take the time to set the value, you have a very good reason to do it, though ;-)