Re: [HTML Imports]: Sync, async, -ish?

On 28 January 2014 18:19, Ryosuke Niwa <rniwa@apple.com> wrote:
>
> > How about making link[rel=import] async by default, but make elements
> with a dash in the tagname display:none by default?
> Is it really the right thing to do in all cases?


Nope, but no default is. The default shouldn't be slow for the user.
<script>'s default is terrible, and we're still fighting its default with
education. <img>'s default however is pretty good.


> Isn't it better to delegate this to the component author?
>

Yep, you can get the blocking behaviour back. In fact, you can display:none
<body> until all your components are there if you want, but that's the bar
you should have to jump over to create something that results in the user
looking at a blank screen during loading.


> But that would mean that document authors need to be aware of exact
> dimensions, styles, theme, etc... of each component they use on the page,
> and add relevant CSS rules.  In addition, each component then needs to
> cancel/override those rules when they get instantiated.
>

Nope, in some cases appearing would be fine. In others you can reserve
space. In others you can show the inner data without interaction. If you
really must, you can show a blank screen until everything has loaded.

>
> > * Performance by default (we'd have made scripts async by default if we
> could go back right?)
> > * Avoids FOUC by default
>
> Could you clarify how this proposal avoids FOUC?  If unresolved elements
> were to be initially display: none and turns into display: block/inline
> later, then that would most likely cause a reflow/relayout of the page and
> causes a FOUC.
>

You never see a flash of unstyled content. Content is only shown once its
styles are ready.

Basically, html imports are taking cues from <script>, and script's default
behaviour is a mistake. If we must follow the behaviour of something
legacy, it should be <img>. Don't block rendering, show on load, allow the
user to do something more blocking if they must.

Received on Wednesday, 29 January 2014 17:08:21 UTC