Separating scripts from anchor hrefs

[jim]

Hello,
I always get angry when I see codes like this:
<a onclick="openImage('aaa.jpg');">see image</a>

I mean, it's confusing, because such markup makes you think it's real link, and I often try to click it with middle mouse button, and get empty page (I know there's Firefox addon for it, recently found it, but it's better to solve problem).

There might be few methods to get rid of this ambiguity. For example, a new new element, let's say it <trigger /> which destination would be use for launching scripts; and to say to user that it would be no href, but a script launched, it will have by default other cursor (e.g. pointer in different color or something).

I know <span /> might be used, but no one does it. Maybe new element will encourage writers not to present scripts like hrefs...

<trigger onclick="doSomething();">text</trigger>

It'll be to discuss how to replace a combination
<a href="..." onclick=""></a>
I think <a><trigger></trigger></a> or <trigger onclick=".."><a href="..."></a></trigger> with well-defined how to handle such situations won't be bad.


It's only my general thought - it can evolve in different way, but I have no better idea right now. What do you think about it?

[zcorpan]

Do I understand correctly that the problem is as follows?:

1) Authors use links to perform scripts
2) Such links can't be opened in a new tab

And that a Firefox addon makes such links openable in a new tab? Or what does the addon do? If the addon solves the problem, wouldn't browsers doing the same thing by default also solve the problem?

[Erik Reppen]

There's no need for event handlers within the markup when you can access everything using the DOM from a linked js document and this has been adopted by a lot of designers as good practice.

Google "unobtrusive javascript."

If it were my spec, the only place for client-side scripting would be in an externally linked doc.

[SneakyWho_am_i]

I would LOVE to see the end of

Code: Select all

<a href="javascript: goToPage(5);">5</a>

Do I need to post examples of sites that do this?
Unfortunately I have this upsetting suspicion that this kind of bad practice can not be removed from the specification as it is employed by one or two sites that I visit at least one day a week.

It is hugely disruptive to my experience as a browser. On a website that allows user-submitted javascript in places I have to turn on javascript to navigate a product catalog, which I find frankly disgusting. You know what the goToPage() function does? It just navigates to a new page. There is no need for a javascript function to change the url.
Nor do we need javascript to open links in parent or child windows, but people do this too.

In the case of the userland navigation function, it's even more disruptive when I try to open links into a new tab. I use the middle mouse button mroe than the others, and I hat that these bad web designers are taking away basic functionality in the browser.

However as zcorpan pointed out, I guess that really if the browser is allowing my navigation to be broken this way then it is a bug in the browser, not in the specification.

The user agent SHOULD be able to navigate to a new page in response to some user-initiated action in javascript, despite the high level of abuse.

IS there any way that the standards process can shape this? I think it's too much to ask.
Surely we couldn't make javascript: urls invalid somehow.

Sounds like a bug to put to browser vendors.

[JAB Creations]

I use it on my site to be direct with visitors: I'm going to AJAX some content with an AJAX function so you're not going to a new page. You determine that by looking at the browser's status bar. I personally prefer seeing this versus seeing "#" in the status bar. Then I have no clue what it's going to do.

You want annoying: popups for any reason what-so-ever. How long has CSS2 been around? It's called layers people, get with the program.

Why do you have JavaScript disabled? Try talking for an entire day without using verbs and see how you are able to communicate with others around you.

Also JavaScript (X)HTML attribute events are important for backwards compatibility. Unobtrusive is ok though not necessarily business friendly where I use modular JavaScript calling only functions from XHTML JavaScript attribute events.

[campax]

I think that the xhtml event attributes will be deprecated when there will be a consistent implementation of XBL 2 and CSS Behavioural Extensions, allowing to separate action from semantic and without

document.getElementById('something').onclick = etc.
or worse
document.getElementById('something').addEventHandler('click',etc.)

using xbl, any xml element can act as a "trigger" element (provided it has a binding attached in any way)