On Tue, 14 May 2013 09:45:01 +0200, Hajime Morrita <[email protected]>
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
