Develop Reference

Determine which link (on same page) was used?

I have a page with two links to an introduction/registration page. We want to show different content based on which link the user uses. They appear in different contexts on the same page, and we would like to tailor the message on the registration page to that context. For SEO purposes I was told not to change the URL.
I'm using rails. Since the incoming user will have the same referrer regardless of which link was clicked, what is the best way to know which link was used to get to my page? Is it possible in a practical way without altering the URL?

I would change the href on click like described in How to change href of <a> tag on button click through javascript
But I would not change the whole url. I would only append a parameter. This should not influence SEO.

I want to get an event for an HTML onContextMenu *after* the final selection, not at initial click

If I do
<a href ... oncontextmenu="myFunction(event)">
It gets called when the user right clicks on a link, before the context menu appears. But I want to get an event after a context menu item has been selected. Ideally, only when they have selected "Open link in ...", so having access to what they actually clicked is desirable.
Would prefer a non-JQuery answer, but if needed, JQuery is o.k.
Added: Explanation what I'm trying to do:
When the user directly clicks a link to another (commercial hotel finder) site, I bring up a little alert "If you book a room, please enter XXXX as the Gift Code"). Would also like to put up this alert if they right click and open the link in a new tab etc.,.,
Added#2: Thanks for the prompt and direct answers. See my "answer" below for what I ended up doing. I'll leave this question open in case there are other options.

This is not possible to do in Javascript, but you might be able to achieve what you are looking for by replacing the default context menu with a custom one.

You can't. The primary purpose of the contextmenu event is to allow a page to replace the browser's context menu with a menu of its own rendered as HTML. The contents of the browser's context menu are not specified by any HTML standard, and will vary from browser to browser. Most of the options in the context menu refer to actions outside the scope of the page (e.g, "copy", "view page source", "open link in new window", "save as", etc.), and there is no event fired on the page when they are selected unless the action being performed would normally fire an event. (For instance, selecting "Print" might fire onbeforeprint and onafterprint events.)
The WHATWG HTML5 specification specifies a menu element which can be used to add items to the browser's context menu, but it's currently only supported under Firefox. So that's probably not really an option either.

Just an idea, and I'm not sure exactly what you are trying to do, but I would try calling the function on a set delay, like this:
Right-Click Me, then wait for 3 seconds.
The only downside is that once the alert() is called, the context menu is hidden.
Hope this helps!

What I ended up doing is inserting an intermediate page on my site.
Instead of directly going to the external site, the route (I'm using node & Express) brings up a intermediate page with the explanatory text, a checkbox "Got it, don't show this page again", (in my case, the answer gets stored in localStorage, others might store on the server) and a big green OK button that takes you to the external site.
If the route includes the query "?directXXX=true", (read from localStorage) you skip over the intermediate page and are immediately redirected to the external page.
This way I get a much nicer explanatory page, with an image, etc... (dialogs, even if you use something like alertify, look klunky) and I get to "intercept" all calls to the external site.

Is it possible to use a hyperlink to change the page and activate a script on the target page?

My idea is that, if I click a link on Page 1, it will load Page 2 (same window) and activate a script on Page 2. All of this done by through the same link.
More specifically, the page I'm making will have a link to an article on Page 2, and on Page 2 the article is hidden but will be expanded using JavaScript (like a "Read More" function you might see in some blogs). Page 1 would have a link that leads straight to the article and expands it at the same time.
Thanks for the help.
edit 1: Sorry, I may not have clarified completely. Basically, the Page 2 would have multiple articles on it. From Page 1 I intend to have different links to activate different articles on Page 2 (also articles on other pages from different links, but I just need to get at least one working first).

Just set an onload on page 2, to trigger whatever javascript you like. It's hard to trigger a js function on a page that doesn't yet exist.
<body onload="expandArticle()">
If you want to send parameters to page2 (like article id to expand), there are several options to do so. For example, set it in the page url:
Read article
and then pick that request parameter in your javascript at articles page (page 2).
function expandArticle() {
var url = window.location.href,
articleId = url.split("?")[1].split("=")[1];
console.log("articleId = " + articleId);
// do something with article
}
(This isn't the most fancy way of extracting request parameters, and it depends on the parameter structure. But for a simple example like this it works though. Using regular expressions are probably the best way of doing it, like here: How can I get query string values in JavaScript?)

I suggest you using the fragment identifier part of the URL to decide which content to show on load.
Suppose your second page is example.com/foo
In you first page you set the href of link tag to something like :
My Link
And you modify you second so that your onDocumentReady listener looks like
function onLoad() {
switch (document.location.hash) {
case "bar": showContentForBar(); break;
case ....
}
}
Using the fragment part of the url ensures that the server won't be affected (the browser won't send the fragment part). Historically, the fragment was used for anchor links, and can be still used today to achieve the same "state save" functionality.
Note that prior the HTML5 History API, this was the widespread technique (a more elaborated version though) to implement single page webapps.
Hope this will help.

In page1 have a simple link that redirects to Page2 and in the page2 use Jquery document.ready function to call the javacript functions according to your need.

Multipage vs Single Page and Unobtrusive Javascript

I have a section of a site with multiple categories of Widget. There is a menu with each category name. For anybody with Javascript enabled, clicking a category reveals the content of the category within the page. They can click between categories at will, seeing the DOM updated as needed. The url is also updated using the standard hash/hashbang (if we are being Google-friendly). So for somebody who lands on example.com/widgets, they can navigate around to example.com/widgets#one, example.com/widgets#two, example.com/widgets#three etc.
However, to support user agents without Javascript enabled, following one of these category links must load a new page with the category displayed, so for someone without javascript enabled, they would navigate to example.com/widgets/one, example.com/widgets/two, example.com/widgets/three etc.
My question is: What should happen when somebody with Javascript enabled lands on one of these URLS? What should someone with Javascript enabled be presented with when landing on example.com/widgets/one for example? Should they be redirected to example.com/widgets#one?
Please note that I need a single page site experience for anybody with Javascript enabled, but I want a multi-page site for a user agent without JavaScript. Any answer that doesn't address this fact doesn't answer the question. I am not interested in the merits or problems of hashbangs or single-page-sites vs multi-page-sites.

This is how I would structure it:
Use HistoryJS to manage the URL. JS pushstate browsers got full correct URLs and JS non-pushstate browsers got hashed urls. Non-JS users went to the full URL as normal with a page reload.
When a user clicks a link:
If they have JS:
All clicks to other pages are handled by a function that prevents the default action, grabs the HREF and passes the URL to an ajax request and updates the URL at the same time. The http response for that ajax request is then parsed and then loaded into the content area.
Non JS:
Page refreshed as normal and loads the whole document.
When a page loads:
With JS: Attach an event handler to all your links to prevent the default so their href is dealt with via Ajax.
Without JS: Nothing. Allow anchors to work as normal.
I think you should definitely have all of your content accessible via a full, correct URL and being loading it in via ajax then updating the URL to reflect the address where you got your content from. That way, when JS isn't running, you don't have to change anything.
Is that what you mean?

Apparently your question already contains the answer. You say:
I need a single page site experience for anybody with Javascript enabled
and then ask:
What should someone with Javascript enabled be presented with when landing on example.com/widgets/one for example? Should they be redirected to example.com/widgets#one?
I'd say yes, they should be redirected. I don't see any other option, given your requirements (and the fact that information about JavaScript capabilities and the hash fragment of the URL are not available on the server side).
If you can accept relaxing the requirements a bit, I see another option. Remember when the web was crowded with framesets, and we landed on a specific frame via AltaVista (Google wasn't around yet!) search? It was common to see a header saying that page was supposed to be displayed as a frame, and a link to take the user to the frameset version.
You could do something similar: when scripting is available, detect that you're at example.com/widgets/one and add a link to the single-page version. I know that's not ideal, but it's better than nothing, and maybe better than a nasty client-side redirect.

Why should you need to redirect them to a different page. The user arrived at the page looking for an answer. He gets the answer even if he has javascript enabled. It doesn't matter. The user's query has been fulfilled.
But what would happen if the user lands on example.com/widgets#one ? You would need to set up an automatic redirect to example.com/widgets/one in that case. That could be done by checking the if javascript is enabled in the onload event and redirect to the appropriate page.

One way for designing such pages is to design without javascript first.
You can use anchors in the page so:
example.com/widgets#one
Will be a link to the element with id 'one'
Once your page works without javascript, then you add the javascript layer. You can prevent links to be followed by using the event.preventDefault.
(https://developer.mozilla.org/fr/docs/DOM/event.preventDefault), then add the desired javascript functionality.

Create cookie if link clicked, redirects to clicked link on next visit

Site has two sections; 'Everywhere' and 'LA'.
Default is 'Everywhere' section.
How would I go about creating a cookie if the visitor clicks the 'LA' section link and when they return to the main site on another visit, they are redirected to that 'LA' section?
I've tried altering this script; http://www.javascriptsource.com/cookies/cookie-redirect.html
Instead of checkboxes, its a link and only one. But doesn't seem to work.

What I do usually is create a conditional, and create an embed with the cookie inside. I also tend to use this add-on: http://devot-ee.com/add-ons/cookies

Tad,
For setting the cookie you are going to want to use javascript, using a click handler on the LA section link. If you need some help with setting the cookie in javascript there is a good introductory article at http://www.quirksmode.org/js/cookies.html which isn't bang up to date but is still in full working order.
Once the cookie is set then you will switch to using one of the plugins for EE so that you can check for the existence of it in a template (probably in the an embeded or snippeted template) on page load. If you find the cookie then you can use the standard EE redirect syntax to send the visitor to the relevant section.