[whatwg] <a onlyreplace>

On Thu, Oct 22, 2009 at 1:56 AM, Daniel Glazman
<daniel.glazman at disruptive-innovations.com> wrote:
> 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 actually consider that a loss.  It's addressing a different problem,
you see.  HTMLOverlays is basically client-side includes.  While you
can hack it into solving a similar problem to @onlyreplace, that's not
its primary purpose and the bookmarkability seems like it would be
poor.  (Note - bookmarkability of abusing htmloverlays as a navigation
mechanism, not of using them as intended.)

@onlyreplace is simply a way of specifying slightly different
navigation semantics on your links.  The original page load is the
same as normal (unlike HTMLOverlays, where the initial request is a
partially-empty page), and navigation is what's changed (unlike
HTMLOverlays, which utilize normal navigation and just slot in the
overlays again on pageload).  Different solutions to different
problems.

> 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 :-)

I think that's because we're doing different things, like I said.  ^_^
 There's a very small target in the problem-space I'm working in
that's good, while nearly everything else is bad.  If people
interpreted HTMLOverlays as solving the same problem as what I'm
trying to solve with @onlyreplace, then yeah, it's a bad solution.  It
may be fine at solving its own problem.

> That said, there are a few problems to solve:
>
> - what means exactly "replacement" here? What's the scope of a
> ?<script> element?

"replacement" is semantically identical to setting outerHTML on the
target elements.  I'm not sure what you mean by "scope of a <script>
element".

> - what does it mean for stylesheets and scoped stylesheets?

Nothing special.

> - 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?

The entire subtree is replaced, root and all.  Event handlers attached
to the root or any child are lost.  Either reregister them in the
swapIn event, or use event delegation on an ancestor.

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

Hm?  There's nothing about @onlyreplace that only works for <body>
elements.  Where did you get that impression?  (I'd like to know so I
can reword things if needed.)  As long as an element has an id it can
be replaced.

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

I think you misunderstand the mechanics of @onlyreplace.  It doesn't
change anything when you first load a page, and it shouldn't be at all
similar to prefetching.  It only operates when you click on a link
with the @onlyreplace attribute.  The browser then makes an ordinary
request for the desired page, parses it with scripting disabled, and
locates elements with the given ids to swap into the old page.

~TJ

Received on Thursday, 22 October 2009 06:59:41 UTC