Daniel Glazman schrieb:
> Hi there,
>
> That onlyreplace attribute is not enough, and trust me, I have
> spent quite a while on solutions transforming HTML documents using
> bits contained in external instances...
>
> Hixie referenced at some point in the thread my HTMLOverlays proposal
> [1] and that proposal has a clear plus compared to the onlyreplace
> attribute: it's not meant to ONLY replace but ALSO to add elements to
> an existing container, using an order defined by the web author and not
> only appending overlaid elements.
> That's a _major_ win compared to onlyreplace.
>
> I am not saying here that onlyreplace is a bad idea, it's even a very
> good one. And I find VERY amusing to read super-positive comments about
> it that are exactly contrary to comments I received myself on
> HTMLOverlays while the two proposals are rather similar :-)
They are crucially different in some points:
- HTMLOverlays is a ready-to-use script solution. It does not require
any specification nor implementation by UAs. Instead, it requires work
on the authoring side; using HTMLOverlays means totally re-writing your
websites.
- HTMLOverlays does not degrade nicely. If a UA does not support
scripting, or the script is not found for any reason, there is no way to
render the page in a useable manner. This also applies to search
engines, which will not see anything that is part of the overlay - this
will typically apply to the whole navigation.
> That said, there are a few problems to solve:
>
> - what means exactly "replacement" here? What's the scope of a
> <script> element?
> - what does it mean for stylesheets and scoped stylesheets?
> - what does it mean for the root of the replaced subtree? Let's call
> that the bound element and the binding : how are deferred to the
> subtree even handlers attached to the bound element?
> - I don't like <a onlyreplace> because that works only with elements
> inside the body of a document. I want a generic mechanism that can
> apply to elements in head too...
Are you sure about that? I assumed this was valid:
<html>
<head>
<title id="title">My title</title>
<style id="mystyle">
@import url(mystyle.css);
#contents h2 { color:red; }
</style>
<script>
alert("This one is not replaced");
</script>
<script id="script2">
function foo() { alert("bar"); }
</script>
<base onlyreplace="title mystyle script2 contents">
</head>
<body>
<ul id="navigation">
<li><a href="otherpage.html" onlyreplace></li>
</ul>
<div id="contents">
<p>Text</p>
<div>
</body>
</head>
Anyway, it might be reasonable to always replace the <title> element, as
it is recommended to have individual titles for every page, and looks
like an overkill to give this unique element an id, just to reference it
in the onlyreplace list.
> - I think a mechanism using a <link> element is better because it's
> similar to prefetching. It's also semantically better because it
> used a _very_ old proposal of mine called "link dereferencing" [1].
> And of course it is better because it can help resolving the
> progressive rendering issues of <a onlyreplace> since the head
> is parsed before the body...
Can you give a code example how this could look like?
