Re: webcomponents: <import> instead of <link>

On Tue, 14 May 2013 09:45:01 +0200, Hajime Morrita <morrita@google.com>  
wrote:

> Just after started prototyping HTML Imports on Blink, this idea comes to  
> my
> mind: Why not have <import> for HTML Imports?
>
> The good old <link> has its own semantics which allows users to change  
> the
> attributes dynamically. For example, you can change @href to load other
> stylesheets. @type can be dynamically changed as well.
>
> In contrast, importing HTML document is one-shot action. We don't allow
> updating @href to load another HTML. (We cannot do that anyway since  
> there
> is no de-register of custom elements.) This difference will puzzle page
> authors.
>
> And an implementer (me) is also having troubles... Current <link>
> implementation is all about dynamic attribute changes. disabling its
> dynamic nature only with @rel="import" seems tricky.
>
> Well, yes. I can just refactor the code. But this complication implies  
> that
> making it interoperable will be a headache. There will be many hidden
> assumptions which come from underlying <link> implementation. For  
> example,
> what happens if we update @rel from "import" to "style" after the element
> imported document or vice versa? We need to clarify all these cases if we
> choose <link> as our vehicle. It seems burden for me.
>
> Using new element like <import> doesn't have such issues. We can just
> define what we need. Also,
> we'll be able to introduce import-specific attributes like @defer, @async
> or even something like @sandbox without polluting <link> vocabulary.
>
> One downside is that we'll lose the familiarity of <link>.  But having
> indirection like the "Import" interface smells like we're just abusing  
> it.
>
> What do you think? Is this reasonable change or am I just restarting
> something discussed before?

I have proposed <script import=url></script> instead of <link rel=import  
href=url> before.

http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0009.html
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0024.html

Benefits:

  * Components can execute script from an external resource, which <script  
src> can do as well, so that seems like a good fit in terms of security  
policy and expectations in Web sites and browsers.
  * <script src> is not dynamic, so making <script import> also not dynamic  
seems like a good fit.
  * <script> can appear in <head> without making changes to the HTML parser  
(in contrast with a new element).

To pre-empt confusion shown last time I suggested this:

  * This is not <script src>.
  * This is not changing anything of the component itself.

-- 
Simon Pieters
Opera Software

Received on Tuesday, 14 May 2013 21:09:10 UTC