nichemtktg — 2011-06-14T21:23:53-04:00 — #1
I'm guessing, but how you redirect to same spot on the page sounds like a js question. If so, please provide some tips to get started.
I've created a long page that allows me to save form inputs as I go along, but it sends me back to the top of the page with each redirect (header('Location: http://localhost/acrobat7c.php')wink.gif. I'd like the redirect to send me back to where I was when I submitted inputs.
chris_upjohn — 2011-06-14T22:30:34-04:00 — #2
How does your code work when it adds a new form to the DOM as i have a thought in mind of how to get this working for you.
nichemtktg — 2011-06-14T22:44:12-04:00 — #3
It's pretty simple. The form sends the input to this script:
$key = "'" . key($_POST) . "'";
$val = "'" . $_POST[$key] . "'";
mysql_query("UPDATE stk SET width = " . $val . " WHERE id = " . $key . "") or die(mysql_error());
chris_upjohn — 2011-06-15T01:02:48-04:00 — #4
Sorry for the delay, try the following idea.
- When you create your form add an anchor element like the example below before it
- Then in your PHP script change your header redirect to
Basically my idea is to use anchor tags and a URL anchor so the browser does all the hard calculations to get the page position where it needs to be. Let me know how you go as im hoping this idea works for you.
nichemtktg — 2011-06-16T09:52:16-04:00 — #5
SgtLegend, worked like a dream. <a> is a tag that was waiting for me to use for the first time.
chris_upjohn — 2011-06-16T10:10:47-04:00 — #6
No problem, glad it worked for you
paul_wilkins — 2011-06-16T23:24:10-04:00 — #7
If it helps, the id attribute is one that has been around since HTML 4, so that instead of using a named anchor:
<a name="form_' . $form_id . '"></a>
You only now need to use the identifier by itself.
<form id=" . $form_id . '">
So that the very same identifier is used to reference that part of the page:
header('Location: http://localhost/acrobat7c.php#' . $key);
That helps to reduce confusion by relegating the name attribute to only inside of forms, for the purpose of naming form fields, whereas the id attribute is used to perform its proper job of uniquely identifying different parts of the page.
chris_upjohn — 2011-06-17T00:47:58-04:00 — #8
Thanks for the info Paul, i actually didn't know that "id" could be used as an anchor but now i do
paul_wilkins — 2011-06-17T05:25:21-04:00 — #9
Just to finish this off, here's how it's all connected.
The HTML 4.01 spec has several sections that bring this all together.
Target Anchor? Anchor Element?
The fragment identifer section gives a brief example of how the URI is used to refer to a certain location. Even though it says that it's pointing to an anchor, that doesn't mean to say that it's pointing to an anchor element. Keep in mind that by "anchor element" they don't mean the <a> element. Instead, a much broader meaning is meant.
The section on the [id attribute helps to clarify this, as the spec says that id is used for several tasks, including: "As a target anchor for [url="http://www.w3.org/TR/html401/struct/links.html#anchors"]hypertext links](http://www.w3.org/TR/html401/struct/global.html#h-7.5.2)" which links to the introduction page.
It's called a "target anchor" not because the id attribute is on hypertext links, it can be on virtually any HTML element at all. The target anchor allows some other page to use a hypertext link to link directly to an element within the target page. The id attribute serves as a target anchor.
The [introduction to links and anchors section provides much fuller details on how fragment identifiers work. It also links through to the [url="http://www.w3.org/TR/html401/struct/links.html#adef-name-A"]name section which includes a link to the [url="http://www.w3.org/TR/html401/struct/links.html#anchors-with-id"]Anchors with the id attribute](http://www.w3.org/TR/html401/struct/links.html#anchors) section.
How is the Name attribute affected?
At the time of the HTML 4.01 spec in 1999, they were transitioning over from using the name attribute on a limited number of HTML elements, to using the id attribute on virtually everything. 12 years ago they still had to provide consideration for web browsers that didn't support HTML4. Unthinkable now, but that was back in the day.
As time moved on and they developed the spec for XHTML (there's only one year between HTML 4.01 and [XHTML 1.0), they had formally deprecated the use of name attribute on all elements except for those used to provide form data. In the XHTML [url="http://www.w3.org/TR/xhtml1/#C_8"]fragment identifiers](http://www.w3.org/TR/xhtml1/) section they talk about completely removing the name attribute from all other elements.
Why would they do that? Because if we look back at the HTML 4.01 specs for forms, we find that in the form controls section that the name attribute has a special task to perform within forms themself, that has nothing to do with fragment identifiers.
In effect, the purpose of the name attribute is now solely meant for data fields within forms. And in fact, with the [HTML5 spec we now find that the [url="http://www.w3.org/TR/html5/association-of-controls-and-forms.html#attr-fe-name"]name](http://www.w3.org/TR/html5/) is exclusively used only for forms now.
Now more than 10 years on from HTML 4.01 and XHTML 1.0, the id attribute remains as the favored method by which to uniquely identify different parts of a web page.