Attach event/function to links within span tag

[johkar]

I need to cancel the link and execute a function onclick of all the
links within the span tag which has a class of "container" assigned.
There will be only one span tag with this class applied.

I know you can get a specific tag using
document.getElementsByTagName('span')[0], but I am unsure how to get
the one with the class="container". I know there is a getAttribute
method, just need a pointer or two to put it all together. Once I know
how to access the specific links I want do the equivelant of <a
href="hello.do?contain=yes" onclick="someFunction(this);return
false">Hello</a>. I am thinking I can add a global function or
setAttributes. Ideas?

<span class="container">
<a href="hello.do?contain=yes">Hello</a>
<span class="container"><a
href="goodbye.do?contain=yes">Goodbye</a>
</span>

Thanks,

John

 

[RobG]

I need to cancel the link and execute a function onclick of all the
links within the span tag which has a class of "container" assigned.
There will be only one span tag with this class applied.

Your example below has two. I'll guess that you didn't mean to add the
container class to the nested span.

I know you can get a specific tag using
document.getElementsByTagName('span')[0], but I am unsure how to get
the one with the class="container". I know there is a getAttribute
method, just need a pointer or two to put it all together. Once I know
how to access the specific links I want do the equivelant of <a
href="hello.do?contain=yes" onclick="someFunction(this);return
false">Hello</a>. I am thinking I can add a global function or
setAttributes. Ideas?

There is no 'document.getElementsByClassName' method, but you can get
all the spans using getElementsByTagName and look for one with a class
of 'container':

function getElementsByClassName(tName, cName)
{
var t = [];
var el, els = document.getElementsByTagName(tName);
for (var i=0, len=els.length; i<len; ++i){
el = els;
if (el.className && cName == el.className){
t[t.length] = el;
}
}
return t;
}

Then you can do:

var els = getElementsByClassName('span', 'container');


Now if you only have one 'container' element and you want all the A
elements inside it:

function addClicks()
{
var els = getElementsByClassName('span', 'container');
var aEl, aEls = els[0].getElementsByTagName('a');
for (var i=0, len=aEls.length; i<len; ++i){
aEl = aEls;
if (aEl.href){
// do stuff with aEl, e.g.
aEl.onclick = doAClick;
}
}
}

function doAClick()
{
var el = this;
alert(el.href);
return false;
}


If you don't want the link followed, have the onclick function return
false but make the HREF go somewhere useful for those without scripting
enabled. Or have script add the links in the first place, so non-script
users don't even see them.

If they aren't really links, use some other element and give them a
'clickable' style or use buttons.

Run 'addClicks' onload:

 

[Thomas 'PointedEars' Lahn]

I need to cancel the link and execute a function onclick of all the
links within the span tag which has a class of "container" assigned.
There will be only one span tag with this class applied.

I know you can get a specific tag using
document.getElementsByTagName('span')[0], but I am unsure how to get
the one with the class="container". I know there is a getAttribute
method, just need a pointer or two to put it all together.

You do not need and should not use getAttribute() for (X)HTML documents.
Although marked as deprecated in W3C DOM Level 2 HTML, the best way to
access attributes there, is to use the properties they are exposed as by
the respective element object interfaces.

Once I know how to access the specific links I want do the equivelant
of <a href="hello.do?contain=yes" onclick="someFunction(this);return
false">Hello</a>.
ACK

I am thinking I can add a global function or setAttributes.

What applies to getAttribute(), applies to setAttribute() as well.
See previous discussions on how to add an event listener for an
event to an element.

Note that unlike stated on occasions, the proprietary approach for this
cannot really be identified with the standards compliant one, hence

foo.addEventListener(
'click',
function()
{
// ...
return false;
},
false);

in practice is _not_ semantically equal to

foo.onclick = function()
{
// ...
return false;
};

I noticed this recently while trying to make my ObjectInspector standards
compliant in that regard. I observed that using the first approach, it was
not possible to implement a reliable display property toggle on `a[href]'
elements (for `ul' elements) in Mozilla/5.0; however, it was possible again
using the second approach again. (In case I overlooked something, I would
be thankful for any pointers as well.)

Ideas?

Yes. I have already written such a method and several people posted such
before, but to not spoil your coding experience, here is the pointer you
asked for:

The object referred to by `document' has a getElementsByTagName() method
(per the HTMLDocument interface of W3C DOM Level 2 HTML) that accepts an
asterisk (*; instead of an element type identifier) as string argument to
return a HTMLCollection of _all_ element objects in the DOM tree. You can
iterate through that collection and check for the `className'[1] string
property of each element object; references to all matching element objects
can be arranged in an Array or a user-defined collection object and
returned from a method. Note that `className', like the `class' attribute
value, can be a whitespace-separated list of (CSS) class names.

[1] `class' could not be specified, since that is a reserved word in
several languages a binding is provided for, including ECMAScript
implementations.

<span class="container">
<a href="hello.do?contain=yes">Hello</a>
<span class="container"><a
href="goodbye.do?contain=yes">Goodbye</a>
</span>

Although `span' elements can be nested, this does not look like a reasonable
piece of markup. Consider block-level elements like `div' to contain other
block-level elements like `ul' and inline-level elements like `a' and
`span'.


Happy coding!

PointedEars

 

[johkar]

Perfect, thank you. Yes, I didn't mean to nest the spans, just a
stupid cut and paste mistake.

John

 

[johkar]

Thanks for your insight, the nested spans were a mistake in posting my
'simple' example.

John

 

[RobG]

Perfect, thank you. Yes, I didn't mean to nest the spans, just a
stupid cut and paste mistake.

Forgot to mention that the getElementsByClassName function returns an
array that will contain references to all the elements with the tagName
and className specified, so you can use it for other purposes.

Because you only wanted the one element, the posted code was hard-coded
it to get the first element (i.e. index 0) of the returned array, but
you could loop through all of them if you wanted to.

As Thomas says, don't use getAttributes for this. DOM element objects
(e.g. span elements) also have a getAttribute() method, but again it's
not suitable for what you are doing.

 

[Thomas 'PointedEars' Lahn]

Just another way as a suggestion (by using a separate tag for
JavaScript psi-links).

You want to get informed about the informal meaning of the word "psi".

IMHO much easier to handle in all aspects plus
an explicit visual difference in case if script is disabled.

<html>

<head>
<title>JS Link</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
body {
background-color: #FFFFFF;

Missing (foreground) `color' declaration, so potentially harmful.

}

var{
font-style: normal;

Unnecessary; this is the general default. In fact, forcing a certain
font-style on this element (which has often font-style:italic in UA basic
stylesheets) is potentially harmful as it can no longer be distinguished
from the rest of the text. See below.

color: #0000FF;

Not True Web-Safe[tm], should be #00f.

text-decoration: underline;

Misleading for the user, as that element type specifies no visible
hyperlink.

cursor: not-allowed;

Invalid property value.

<URL:http://www.w3.org/TR/REC-CSS2/ui.html#propdef-cursor>

}
</style>

<script type="text/javascript">

function hOver(e) {
var hColor = '#FF0000';

See above.

var lnk = null;
if ((e)&&(e.currentTarget)&&

^^^^^^^^^^^^^^^^^
Misuse of the `currentTarget' property; should be

var t = e.target || e.srcElement;

before and using `t' in place of the marked section.

<URL:http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-currentTarget>

Simple expressions like variable references or property accesses
do not need to be enclosed in parantheses nor does it change the
result of the evaluation.

(e.currentTarget.tagName == 'VAR')) {

HTML element type identifiers (informal: tag names) are
case-insensitive, so that should be

(t.tagName.toLowerCase() == 'var')) {

lnk = e.currentTarget;
lnk.style.color = hColor;

See above.

}
else if ((event)&&
(event.srcElement)&&(event.srcElement.tagName == 'VAR')) {

This kind of branching is completely unnecessary, ...

lnk = event.srcElement;
lnk.runtimeStyle.color = hColor;

.... especially because the `runtimeStyle' property is unnecessary for
write access. The `style' property suffices for all DOMs this is
scripted for.

if (lnk.title) {window.status = lnk.title;}

Scripts should not manipulate the content of the status bar of windows
in such an irresponsible way.

<URL:http://jibbering.com/faq/#FAQ4_35>

}
else {
/*NOP*/
}

There is no "else", either it is the W3C DOM/Gecko DOM or the IE4 DOM;
this branch is unnecessary, especially as the "NOP" comment indicates
that nothing should be done in that case.

}

function hOut(e) {
[...]
}

The same nonsense here, even though it is far more reasonable to write
one method and use different argument values to facilitate both features.

function init() {
var lnk = document.getElementsByTagName('VAR');

The previous test for the DOM method was omitted, this is error-prone.

<URL:http://pointedears.de/scripts/test/whatami#inference>

var len = lnk.length;
var cur = (window.ActiveXObject) ? 'hand' : 'pointer';

AFAIK, this is flawed as Netscape 6+ on Windows supports ActiveXObject
to facilitate support for the Windows Media Player plugin), but its
Gecko layout engine does not support the IE-proprietary cursor:hand.

for (var i=0; i<len; i++) {
lnk.style.cursor = cur;
lnk.onmouseover = hOver;
lnk.onmouseout = hOut;
}
}

window.onload = init;

Misusing the proprietary `onload' property of the object referred to by
`window', and not the standards compliant `onload' property of the `body'
element as it should be.

</script>

</head>

<body>
<p>
<var onclick="alert('OK')" title="Check mail">Click me 1</var>

Utter nonsensical misuse of the `var' element which has the purpose of
marking up variable identifiers or parameters in (X)HTML hypertext.

<URL:http://www.w3.org/TR/html4/struct/text.html#edef-VAR>

Once again you have proven sufficiently what an awfully bad (Web) developer
you really are.


PointedEars

 

[VK]

...

Have it read, had a lot of real fun (thanks for that).

No comments needed.

 

[Michael Winter]

VK wrote:
[snip]

color: #0000FF;

Not True Web-Safe[tm], should be #00f.

I personally don't care for that suggestion, and they are equivalent
(digit replication leads to the same value). General colour contrast is
a far more important concern.

[snip]

^^^^^^^^^^^^^^^^^
Misuse of the `currentTarget' property; should be

var t = e.target || e.srcElement;

A far better suggestion is to use the this operator. The obvious intent
is to change the colour of the element to which the listener is
attached, therefore:

function hOver() {
if(this.style) {
this.style.color = '#ff0000';
}
}
function hOut() {
if(this.style) {
this.style.color = '#0000ff';
}
}

would seem a better solution, though one could go a step further and use:

function setColor(object, color) {
if(object && (object = object.style)) {
object.color = colour;
}
}

function hOver() {
setColor(this, '#ff0000');
}
function hOut() {
setColor(this, '#0000ff');
}

[snip]

Misusing the proprietary `onload' property of the object referred to by
`window', and not the standards compliant `onload' property of the `body'
element as it should be.

That thought isn't always practical. For the BODY element to be
accessible as a property of the document object, it needs to have been
parsed on most, if not all, implementations. Clearly, it won't have been
if the code is included by a SCRIPT element child of HEAD.

[snip]

Mike

 

[Thomas 'PointedEars' Lahn]

color: #0000FF;

Not True Web-Safe[tm], should be #00f.

I personally don't care for that suggestion, and they are equivalent
(digit replication leads to the same value).

First read and understand the CSS section about this, then try to argue
about it. Digit replication is only performed if the display device
supports it.

General colour contrast is a far more important concern.

It is an important aspect as well, one that is addressed better with
True Web-Safe[tm] colors.

A far better suggestion is to use the this operator.

True, in this case.

That thought isn't always practical. For the BODY element to be
accessible as a property of the document object, it needs to have been
parsed on most, if not all, implementations. Clearly, it won't have been
if the code is included by a SCRIPT element child of HEAD.

I do not see your point. The most important point of preferring
the `onload' event handler attribute of the `body' element over
`window.onload' is that you can be _sure_ that the _document_ was
loaded and that the respective element objects have been created.


PointedEars

 

[Michael Winter]

[#rgb and #rrggbb are equivalent]

First read and understand the CSS section about this, then try to
argue about it.

The RGB color model is used in numerical color specifications.
These examples all specify the same color:

Example(s):

EM { color: #f00 } /* #rgb */
EM { color: #ff0000 } /* #rrggbb */
EM { color: rgb(255,0,0) }
EM { color: rgb(100%, 0%, 0%) }

The format of an RGB value in hexadecimal notation is a '#'
immediately followed by either three or six hexadecimal
characters. The three-digit RGB notation (#rgb) is converted
into six-digit form (#rrggbb) by replicating digits, [...].
This ensures that white (#ffffff) can be specified with the
short notation (#fff) and removes any dependencies on the color
depth of the display.
-- 4.3.6 Colors, CSS 2 Specification

That seems to make it rather clear that #00f and #0000ff specify the
same colour.

[snip]

[...] the standards compliant `onload' property of the `body'
element as it should be.

[snip]

[...] the `onload' event handler attribute of the `body' element
[...]

You seem to have muddled your terminology. Are you referring to the
onload attribute (HTML) or the onload property (OM)?

[snip]

Mike

 

[VK]

As I mentioned before, the post Message-ID:
<[email protected]> gave me a lot fun and seemed to
not need any comments. But as some kind of discussion still raised, I
may provide a bit more explanations why it's so funny.

The main problem is that my code using VAR tag (Message-ID:
<[email protected]>) is an *actual*
code I have used for my clients.
Therefore it is not a so frequent in clj "reverberating in its purity
mental composition" but a real code having to deal with the dirt and
sin of the real imperfect world. Each detail has some purpose in that
world - and at the same time not correct / unnecessary on the heavens

The fun effect of the criticism was exactly from this collision when
someone having zero practical knowledge (but a lot of theory) is
commenting on a real world fact.

As I cannot express 8 years of practice in one post (moreover I have no
such intention), just few hints:

1. Color values
#FFF instead of #FFFFFF is possible, but *not* recommended, because for
say #F5F5F5 you still have to use the full form. And one with any
web-design skills will never advise to use color names instead of RGB
values. When Thomas will make at least 1/100th of the pages I've made,
it will become a taboo rule for him either: *one cannot trust color
names, they are not guaranteed to be the same across browsers and
platforms*.
I'm not talking about the most primitive colors like "black" or
"white". But it's again brings the question of uniform coding - and
#FFFFFF format remains the only one which should be used.
You are free to call shit on the demented VK mind, but a friendly
advise: while looking for design job within 300 miles around Silicon
Valley, one "background-color: aqua" may override all your perfect
references. And there is a practical reason for it.

2. eventObject.target vs. eventObject.currentTarget (W3C model)
One will find the purpose of it after several *practical* cases like
this one:
<var onclick="
alert(event.currentTarget.tagName)">aaaaaa<span>oooooooo</span></var>

<var onclick="
alert(event.target.tagName)">aaaaaa<span>oooooooo</span></var>

(Click on "aaa" and "ooo" parts in both cases. So that are we going to
use?)

3. window.onload = someFunction vs. <body onload="someFunction()"

Both variants are perfectly valid, but the second one allows passing
arguments w/o using sweetheart closures. While making an easy to
maintain solution for non-experienced users the second variant is much
better, because with closures you have 10/1 chance that the closure
curliness will be smashed to hell. In any case it is always a
per-solution decision and not a subject of some universal regulations.

4. VAR is not intended for psi-links (thus to execute JavaScript code
while staying on the same page).
Sure A is intended for this! Oh wait - we are not misusing it, it's
really a link on noscript.html plus some little side effect
<a href="noscript.html" onclick="myFunction();return true;">

Oh common - that's a hypocrisy of the worst kind, really.

P.S.
5. "psi" means something else.
As I already said I cannot control everyone's stream of association.
For someone "Ajax" leads to washing, "Bachelor of Science" to bullsh**,
"Vector data type" to geometry and "psi" I even scared to think to
what.
In one cafe when I was talking with my friend on the check stand, the
checker asked me to "stop that as we have children here" when I used
the word "voluntarism". Now I'm ready to pay to know *what* association
did work for him.

FYI: psi is 23 letter of Greece alphabet, it has a wide and
domain-specific use in math and physics. One should try to build your
association chain from this starting point.

 

[Norman L. DeForest]

On 21 Jan 2006, VK wrote:
[snip]

4. VAR is not intended for psi-links (thus to execute JavaScript code
while staying on the same page).
Sure A is intended for this! Oh wait - we are not misusing it, it's
really a link on noscript.html plus some little side effect
<a href="noscript.html" onclick="myFunction();return true;">

Oh common - that's a hypocrisy of the worst kind, really.

[snip]

There is attached semantic meaning ("variable") that may be inappropriate
in some cases. "var" defaults to displaying as italics with my copy of
Firefox. It could be something else with other browsers. (Screen-readers
might use a different voice.)

On the other hand, a typo[0] showed me there's another, albeit invalid,
alternative that doesn't misuse predefined tags:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Test</title>
<style>
..foo {background:yellow; color:red}
</style>
</head>
<body>
<p>
Just <spam class="foo" onclick="alert('SPAM works!')">Testing</spam>.
</p>
</body>
</html>

☺[1]

[0] Yes, I did mistype "spam" for "span" in one file and then was
surprised to find out it still worked.
[1] Look it up and then decide how serious I am.

 

[Thomas 'PointedEars' Lahn]

[#rgb and #rrggbb are equivalent]

[...] The three-digit RGB notation (#rgb) is converted
into six-digit form (#rrggbb) by replicating digits, [...].
This ensures that white (#ffffff) can be specified with the
short notation (#fff) and removes any dependencies on the color

^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

depth of the display. ^^^^^^^^^^^^^^^^^^^^^
-- 4.3.6 Colors, CSS 2 Specification

That seems to make it rather clear that #00f and #0000ff specify the
same colour.

Iff the color depth of the display device allows that, hence the remark on
the dependency of the color depth of the display that is removed by using
it instead of the six-digit form.

[snip]

[...] the standards compliant `onload' property of the `body'
element as it should be.

[snip]

[...] the `onload' event handler attribute of the `body' element
[...]

You seem to have muddled your terminology. Are you referring to the
onload attribute (HTML) or the onload property (OM)?

The `body' element's _attribute_ is meant on both occasions. I would
have referred to the `onload' property of an _object_, not an element,
otherwise. Sorry for causing confusion, yet I think I had been clear
enough.


PointedEars

 

[Thomas 'PointedEars' Lahn]

The main problem is that my code using VAR tag

There is no "VAR tag". There is a `var' _keyword_ in JS and a `var'/`VAR'

(Message-ID:
<[email protected]>) is an *actual*
code I have used for my clients.

Those poor people.

The fun effect of the criticism was exactly from this collision when
someone having zero practical knowledge (but a lot of theory) is
commenting on a real world fact.

Talking of "zero practical knowledge", which is not true, when you are
misusing clearly specified markup that works in a certain way in reality.
Well, not in your reality.

As I cannot express 8 years of practice in one post (moreover I have no
such intention), just few hints:

1. Color values
#FFF instead of #FFFFFF is possible, but *not* recommended, because for
say #F5F5F5 you still have to use the full form.

Nonsense. It is entirely possible to mix the six-digit and three-digit form
of color values, even in one selector. However, colors such as #F5F5F5 are
not recommended for the reasons I have given for preferring True Web-Safe
colors over those colors.

And one with any web-design skills will never advise to use color names
instead of RGB values.

Nonsense. Using color names is specified _and_ supported as color values
are, if not better, since they originate from HTML. However, when using
color names, which I did not even mentioned in my reply to your code, you
should stick to the specified ones. There is not a single and otherwise
working CSS-capable UA out there that is not capable of parsing and
displaying _them_.

When Thomas will make at least 1/100th of the pages I've made,
it will become a taboo rule for him either: *one cannot trust color
names, they are not guaranteed to be the same across browsers and
platforms*.

Nonsense. The _specified_ color names are specified ever since. They even
have a counterpart in the HTML 4.01 Specification, and HTML UAs support
them as well in color format attributes.

I'm not talking about the most primitive colors like "black" or
"white".

Neither color name was even mentioned before you did in the posting I am
replying to.

But it's again brings the question of uniform coding - and
#FFFFFF format remains the only one which should be used.

Nonsense, as explained above.

You are free to call shit on the demented VK mind,

[x] done

but a friendly advise: while looking for design job within 300 miles
around Silicon Valley, one "background-color: aqua" may override all
your perfect references. And there is a practical reason for it.

Show me one UA that does not support it and I show you at least five that
do.

However, I did not use, mentioned or recommended background-color:aqua or
named colors, for that matter, anywhere in my posting. Your accusations
and assumptions simply do not apply, and you should apologize.

2. eventObject.target vs. eventObject.currentTarget (W3C model)
One will find the purpose of it after several *practical* cases like
this one:
<var onclick="
alert(event.currentTarget.tagName)">aaaaaa<span>oooooooo</span></var>

<var onclick="
alert(event.target.tagName)">aaaaaa<span>oooooooo</span></var>

(Click on "aaa" and "ooo" parts in both cases. So that are we going to
use?)

Using markup misuse to fail to prove your point, while you completely
miss the fact that the meaning of `currentTarget' and `target' differs
fundamentally. Figures.

3. window.onload = someFunction vs. <body onload="someFunction()"

Both variants are perfectly valid,

The former is not at all valid. It is proprietary, therefore error-prone;
the `onload' attribute is neither.

but the second one allows passing arguments w/o using sweetheart closures.
While making an easy to maintain solution for non-experienced users

Closures have disadvantages, especially for non-experienced users, as
described in the FAQ. But you are missing the point again.

4. VAR is not intended for psi-links

What are these "psi-links" of yours, for God's sake?

(thus to execute JavaScript code while staying on the same page).
Sure A is intended for this! Oh wait - we are not misusing it, it's
really a link on noscript.html plus some little side effect
<a href="noscript.html" onclick="myFunction();return true;">

At least it is providing for the graceful degradation your code lacks
completely.

Oh common - that's a hypocrisy of the worst kind, really.

If that were so, which it is not, as graceful degradation is an important
aspect of providing for interoperable content: so what? Compared to it,
your behavior here demonstrates but pure incompetence, and what makes that
even worse, ignorance (of the facts available, valid arguments from other
people and last but not least your clients and their users), as others and
I have showed on numerous occasions before, and has been shown in this
thread three times now. When will you ever learn?

P.S.
5. "psi" means something else.

What it means _to you_ regarding links will probably remain one of the
mysteries of your mind, because none of the meanings established via
dictionaries and encyclopedias applies here.


PointedEars

 

[Lasse Reichstein Nielsen]

Michael Winter wrote:

Iff the color depth of the display device allows that, hence the remark on
the dependency of the color depth of the display that is removed by using
it instead of the six-digit form.

No, #00f and #0000ff specify exactly the same color, #0000ff,
aka. rgb(0,0,255), independently of what device it may be displayed on.
The equivalence is at the defintion level - the meaning of #xyz is
defined as the meaning of #xxyyzz.

Translating this color to an actual display happens later.

The `body' element's _attribute_ is meant on both occasions. I would
have referred to the `onload' property of an _object_, not an element,

Well, in the W3C DOM's ECMAScript mapping, HTML elements are
represented by Element objects, and I would personally call them
"elements" when discussing them. Just as I call functions that,
even though they are "just" special objects.

/L

 

[Thomas 'PointedEars' Lahn]

[...] The three-digit RGB notation (#rgb) is converted
into six-digit form (#rrggbb) by replicating digits, [...].
This ensures that white (#ffffff) can be specified with the ^^^^
short notation (#fff) and removes any dependencies on the color

^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

depth of the display.

^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^

-- 4.3.6 Colors, CSS 2 Specification

That seems to make it rather clear that #00f and #0000ff specify the
same colour.

Iff the color depth of the display device allows that, hence the remark
on the dependency of the color depth of the display that is removed by
using it instead of the six-digit form.

huh?

#fff will always render the same colour as #ffffff,

No, it will not. The color will probably _look_ the same, but it will not
always _be_ the same.

there is no colour depth issue).

Yes, there is. Read the spec.


PointedEars

 

[Thomas 'PointedEars' Lahn]

No, #00f and #0000ff specify exactly the same color, #0000ff,
aka. rgb(0,0,255), independently of what device it may be displayed on.

Wrong. #00f is _not_ equivalent to rgb(0, 0, 255) on all displays.


PointedEars

 

[Matt Kruse]

No, it will not. The color will probably _look_ the same, but it
will not always _be_ the same.

You are incorrect.

If you aren't convinced, then provide an example of what would happen and
what a user would see at different color depths given both forms.

 

[VK]

There is attached semantic meaning ("variable") that may be inappropriate
in some cases. "var" defaults to displaying as italics with my copy of
Firefox. It could be something else with other browsers. (Screen-readers
might use a different voice.)

Every single tag in HTML has some semantic attached. For example <A
href> has semantic of navigation to a Web resource. Both VAR and A are
semantically neutral about executing JavaScript code on the current
page (both have nothing to do with it).
I ruled out neutral container <SPAN> because I wanted a clear easy way
to get all psi-links (and psi-links only) with a single call w/o
sorting out the results.

Moreover there is no behavior attached to VAR (unlike A) so you are
free to add some, but you don't have to worry about overriding the
default one.

There was a discussion of this kind long ago where I said that the only
one *perfectly semantically correct* solution was to add new namespace
(say JS) and define A in that namespace:
<js:a onclick="myFunction()">JavaScript link</js:a>

One is welcome to do this, but I personally decided that it is
unnecessary complicates the picture without any material benefits.