W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

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

From: Ryosuke Niwa <rniwa@apple.com>
Date: Tue, 28 Jan 2014 18:19:02 -0800
Cc: public-webapps@w3.org
Message-id: <59548123-9456-4DE5-BCA8-F71DF1840EE5@apple.com>
To: Jake Archibald <jaffathecake@gmail.com>
On Jan 28, 2014, at 2:11 PM, Jake Archibald <jaffathecake@gmail.com> wrote:
> I'm really fond of the <link rel="import" elements="x-foo, x-bar"> pattern, but I yeah, you could end up with a massive elements list.
> 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?  Isn't it better to delegate this to the component author?

I have a trouble believing that we can impose one default behavior on all web components without providing abilities for web components to override those defaults.

> As with images, the site developer could apply styling for the component roots before they load, to avoid/minimise the layout change as components load. This could be visibility:hidden along with a width & height (or aspect ratio, which I believe is coming to CSS), or display:block and additional styles to provide a view of the data inside the component that's good enough for a pre-enhancement render.

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.

> * 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.

- R. Niwa
Received on Wednesday, 29 January 2014 02:19:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC