Re: [whatwg] links within an iframe cannot replace the parent document?

"Constantine A. Murenin" <mureninc@gmail.com> schrieb am Tue, 28 May
2013 12:35:37 -0700:

> […]
>
> The use-case is a deterministic URL shortener, where the user wants to
> get access to certain information, which may be available via multiple
> independent content providers (which are all known to the shortening
> service).

Do you mean a URN resolver or something like that?

> For example, right now, when someone requests
> http://mdoc.su/-/ifconfig, I simply return a 300-Multiple-Choices
> page, without actually loading any useful and readable content as an
> appetizer.  What I might want to do instead is load one of the URLs in
> a full-screen iframe (already possible through CSS, not possible with
> HTML5 alone, since iframe's width/height must only contain pixel-based
> values), and overlay my navigation that provides links to other
> content providers with `z-index` (already possible through CSS), but
> not squat on the Location bar (currently impossible not to squat on
> the location bar).

Why not use the Location header for the most appropriate resource?

> Also, I think this is something that's useful for deterministic URL
> shortening in many other cases, too:  say, when I enter
> http://dx.doi.org/10.1109/ITCC.2005.129, it'd be useful if the URL
> stays in the location bar, until I navigate away from the page that is
> ultimately loaded.

I beg to differ. By using <iframe> elements to emulate redirects, you
are obscuring the semantics of the document location – possibly
breaking stuff like fragment identifiers or referers that work quite
well now. You should avoid hard dependencies on the redirect resolver,
otherwise you *will* ruin many days for people who save URLs when the
resolver goes dark but the original document is still online (this
happened multiple times in the past and is bound to happen again).

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

Received on Wednesday, 29 May 2013 08:31:30 UTC