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

On 29 May 2013 01:30, Nils Dagsson Moskopp
<nils@dieweltistgarnichtso.net> wrote:
> "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?

More like an ISBN resolver, where multiple independent providers (e.g.
shops) could serve the request.

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

Because there is no most appropriate resource?

Because some resources can take several seconds to load and some might be down?

Because the whole point is to develop a web-application that gives
users a choice of which resource to go to?  Duh.

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

The IEEE example might have been a wrong one.

But the location is only obscured because iframes don't work right --
as it is, the location doesn't change when you navigate off of the
originally-loaded full-screen iframe.

http://www.whatwg.org/html/browsers.html#valid-browsing-context-name-or-keyword
http://www.w3.org/TR/html5/browsers.html#valid-browsing-context-name-or-keyword

When reading the table referenced above, keep in mind that `seamless`
is only applicable for same-origin documents, which makes those
columns with "seamless" irrelevant, and that, I think, is wrong.

..

In regards to going dark, you're confusing the domains.  For the
application I'm developing, there are many more cases of the original
documents going dark.  Should the shortening service go dark, the
determinism would make it very easy and straightforward to access the
documents in one of the many mirrors, or even replace all the
bookmarks through a search-and-replace regexp.

By way of analogy, I'm suggesting that there should be a way to
develop an application to automatically access a given resource on any
mirror of user's choice, clearly giving the user such choice at their
convenience.  Instead, you suggest that a random dodgy mirror is be
redirected to, which somehow is less likely to go dark than the very
lightweight application in question.

And you still leave the underlying problem untouched:

    Why would anyone non-malicious and usability-friendly would need
non-same-origin documents within a full-screen iframe open-up within
the said full-screen iframe ("_self"), and not at the top of the frame
("_top")?  In this inquiry, I want them opened up at the top of the
frame, replacing my original page with the iframe; do you disagree
that such is a reasonable request?

Cheers,
Constantine.

Received on Thursday, 30 May 2013 06:10:33 UTC