Forum Moderators: open
This requires the use of target="_top" in the link. If you try this with a meta refresh redirect, which is what the site currently tries, it seems that the syntax of the meta refresh tag and the target="_top" attribute are mutually exclusive.
I never use meta refresh redirects myself, but I think the correct syntax is:
<meta http-equiv="refresh" content="5;url=page2.html">
When you try to squeeze in target="_top" into this syntax, there's really no place for it that I can make work.
Current redirect code on the site is... ;) ...
<meta http-equiv="Refresh" content="5 URL=page2.html"target="_top">
The page actually does redirect, at least in IE, but the destination page ends up being framed, which isn't what's desired.
Complicating factor, which makes me surprised the page redirects at all... one of the redirecting pages is a booking engine on someone else's server, and we don't have access to the head section, so the redirect has, up until now, been included in the body of the page. On IE, anyway, the redirect does execute.
My question is two part...
1) Out of curiosity, is there a way to combine a meta refresh redirect with the target="top" attribute?
2) In the case of the page where we don't have access to the head section, what's the best way of accomplishing the redirect... probably with CGI or javascript and, I'd guess, a standby manual ("if not redirected in 10 seconds") link?
1) Out of curiosity, is there a way to combine a meta refresh redirect with the target="top" attribute?
Not that I know of. A referesh, by definition, applies to just the document itself and not the entire display.
2) In the case of the page where we don't have access to the head section, what's the best way of accomplishing the redirect... probably with CGI or javascript and, I'd guess, a standby manual ("if not redirected in 10 seconds") link?
I think you've got it -- I'd say CGI would be best because it's server side and independent of the user agent's configuration. But JavaScript would still work for the great majority of visitors.
I am not following this setup you described 100%, however. It sounds like when the form is submitted, a new page loads and that page has a meta-refresh. What couldn't the frame load the final destination page onSubmit? In other words, why the need for the interim, meta-refresh page?
I am not following this setup you described 100%, however. It sounds like when the form is submitted, a new page loads and that page has a meta-refresh. What couldn't the frame load the final destination page onSubmit? In other words, why the need for the interim, meta-refresh page?
The form is a remote booking engine, framed on the site I'm optimizing (call it the "local site") but not belonging to it. The local site has only partial access to the code of the framed booking engine pages and to the additional pages it serves up. This access allows customization, branding, and linking (and/or redirection) to the local site.
Redirection is used to serve up local confirmation pages, or to redirect to secondary booking engines if the primary engines returned unsatisfactory results.
I'm not sure this fully answers your question, but that's the setup as best as I can describe it in general terms. Variations of this setup have appeared in a variety of places, with a couple of engines, on the site.
Can that first load of the local confirmation page be done target="_top"? Then the meta-refresh wouldn't be an issue. I can imagine that there might be other logisitical reasons that you don't want to do that, such as if the process fails in some way.
I think I understand. It sounds, then, like the "local confirmation" page loads inside a frame -- and then refreshes to the primary booking engine.
tedster - I think either I may have described it badly, or I'm misunderstanding what you're saying.
The primary booking engine loads either a process-completed page or a not-available page inside the frame.
If the remote process-completed page loads, we'd like that to refresh to the local confirmation page (that could be framed or unframed, as we have control over it).
If the remote not-available page loads, we'd like that to refresh, say after 5 seconds, to a secondary booking engine that would also be framed.
All you should need is each of those pages to have the appropriate meta refresh. You do not require a target. The new "refreshed" url can be framed or not it doesn't matter as it is it's own complete entity. I do not use frames now but used to call framed pages from non and non-framed from framed the way you describe.
If the remote process-completed page loads it should have "<meta http-equiv="refresh" content="5;url=local_confirmation_page.html"> in its header.
If the remote not-available page loads it should have "<meta http-equiv="refresh" content="5;url=secondary_booking_engine.html"> in its header.
Does this help or am I missing the point?
Does this help or am I missing the point?
It does help, and you're not missing the point... but I also omitted an important bit of information.
I don't like frames, particularly when it comes to optimizing or bookmarking, so what I've done on this site, which is mostly non-framed, is to use individual framesets for each unique framed booking engine.
So, instead of:
url=secondary_booking_engine.html
I would have:
url=secondary_booking_engine_frameset.html
and second_booking_engine.html would be framed in that frameset.
This has worked great with targets... has all sorts of SEO and bookmark advantages... and the load time for the frameset is negligible.
I could probably drop the framesets when the engine is, in fact, secondary. The secondary engines are sometimes primary in other categories, if this makes sense, and if I can be consistent in how the pages and frameset combos are displayed, I'd like to be. Thus, I'm trying to make the targets work.
There are some other issues too... the confirmation page called up by a framed booking engine has a logo on top, as does the top frame in the frameset. If I drop the logo and the confirmation page is called up by a non-framed page, then I've got another problem.
