Stylesheet problem with generated nodes

J

jesdynf

I'm having trouble applying a stylesheet to content I'm generating
after the fact.

Here's the sample code:

<html>
<head>
<title>CSS/DOM Problem Example</title>
<style type="text/css">
..historylinks {
a:link { color: blue; text-decoration: none }
a:active { color: red; text-decoration: none }
a:visited { color: blue; text-decoration: none }
a:hover { color: green; text-decoration: underline }
}
</style>
<script type="text/javascript">
function writeToHistory () {
var hlist = document.getElementById("historyList");
var li = document.createElement('li');
var a = document.createElement('a');
a.appendChild(document.createTextNode('Test!'));
a.setAttribute("onClick", "alert(\"Alert!\");");
a.setAttribute("class", "historylinks");
li.appendChild(a);
hlist.insertBefore(li,hlist.firstChild);
}
</script>
</head>
<body>
<p>When you click this button, a new link appears at the top of the
history list.
Click on one of these links to perform an action.</p>
<button onClick="writeToHistory();">Test</button>
<ul id="historyList">
<li>End of History</li>
</ul>
</body>
</html>

Mozilla reports that it doesn't understand the "a" declaration, and
that might be a part of it, but as far as I can tell it's valid CSS. I
tried assigning the style with both a.className and a.setAttribute;
both generate valid HTML, but neither takes.

(After /that/ I need to figure out why IE6 won't popup the Alert
box...)

I appreciate any help you offer.
 
M

Martin Honnen

<style type="text/css">
.historylinks {
a:link { color: blue; text-decoration: none }
a:active { color: red; text-decoration: none }
a:visited { color: blue; text-decoration: none }
a:hover { color: green; text-decoration: underline }
}

You can't nest CSS that way, you need e.g.
.historylinks a:link { ... }
.historylinks a:active { ... }
.historylinks a:visited { ... }
.historylinks a:hover { ... }
var a = document.createElement('a');
a.appendChild(document.createTextNode('Test!'));
a.setAttribute("onClick", "alert(\"Alert!\");");

Don't use setAttribute when scripting HTML documents, IE's
implementation is much different from what the W3C DOM specifies and
other browsers like Mozilla implement. Use element properties e.g.

a.onclick = function () { alert("Alert!"); };

and e.g.
a.setAttribute("class", "historylinks");

a.className = "historylinks";

that works across user agents when scripting HTML.
 
V

VK

a.setAttribute("onClick", "alert(\"Alert!\");");
a.setAttribute("class", "historylinks");
li.appendChild(a);
hlist.insertBefore(li,hlist.firstChild);

<html>
<head>
<title>Demo</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function init() {
var lnk = document.links[0];
lnk.setAttribute('onclick', 'abrakadabra');
window.alert(lnk.getAttribute('onclick'));
// displays "abrakadabra"
}
window.onload = init;
</script>
</head>
<body>
<h1><a href="/">Demo</a></h1>
</body>
</html>

How strange, setAttribute / getAttribute seem working just fine
everywhere, including IE...

Oh, got it! You meant to say: "Setting onclick attribute value in the
relevant DOM Tree node is not always equal to setting onclick event
handler in the element's scriptable DOM Interface".

The question is then: why in the name would it be otherwise? It is true
that some browsers do parse attrubute values and do update the
interface thus they are making
element.setAttribute('onclick', 'strValue');
and
element.onclick = myFunction;
equal up to some extend (only "up to some extend" because DOM Tree and
DOM Interface are too different to completely hide it).

Such convenience "bridging" is neither directly prohibited nor required
by the current specs. It means that there can be always UA's without
such extension. One of such UA happens to take 85% or more of the
current market share: thusly it is highly recommended for now do not
use behavioral extension of setAttribute: use the standard interface
scripting methods instead:

a.onclick = myFunction;
a.className = 'historylinks';
 
J

John W. Kennedy

Martin said:
Don't use setAttribute when scripting HTML documents, IE's
implementation is much different from what the W3C DOM specifies and
other browsers like Mozilla implement. Use element properties e.g.

a.onclick = function () { alert("Alert!"); };

and e.g.


a.className = "historylinks";

that works across user agents when scripting HTML.

Not altogether sound advice. IE /correctly/ refuses to set element
properties that are described as "read-only" in the DOM, but does allow
them to be set by setAttribute(). Firefox /incorrectly/ accepts the
property setting.

E.g.,

var post = document.createElement("input");
post.type = "submit";

will incorrectly work under Firefox, but correctly fail under IE, whereas

var post = document.createElement("input");
post.setAttribute("type", "submit");

will work everywhere.
 
R

Randy Webb

VK said the following on 12/15/2006 2:16 PM:
<snip>

Is there some reason you would put a request in the subject yet you have
absolutely nothing in your post regarding any possible wording for an
entry? If you want to request an entry, by all means do so. But don't
imply in the subject that you want one and then not even mention it in
the post.
 
M

Martin Honnen

John said:
IE /correctly/ refuses to set element
properties that are described as "read-only" in the DOM, but does allow
them to be set by setAttribute(). Firefox /incorrectly/ accepts the
property setting.

E.g.,

var post = document.createElement("input");
post.type = "submit";

The current W3C DOM specification is W3C DOM Level 2 HTML
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-62883744>
it does not say that the type property (respectively type attribute in
IDL terms) of HTMLInputElement objects is readonly. So using that sample
above to claim a DOM implementation is incorrectly accepting changes to
readonly properties is rubbish, that property is not readonly at all.
will incorrectly work under Firefox, but correctly fail under IE,

Both IE/Win (tested with IE 6) and Mozilla/Firefox allow the above code
without errors, that is creating a new input element object and setting
its type property directly after that before the input element object is
inserted into the document:

whereas

var post = document.createElement("input");
post.setAttribute("type", "submit");

will work everywhere.

See above test case, it does not make a difference in IE or Mozilla
whether you use inputElement.type (or input['type']) or
inputElement.setAttribute('type', '...'). The problem with IE's HTML DOM
and setAttribute is that it pays attention to the case of attribute
names and that it wants typed property values and not attribute strings:
<http://msdn.microsoft.com/library/d...thor/dhtml/reference/methods/setattribute.asp>
There it clearly says that the second argument is not (always) a string
but rather a variant that can be a boolean, string or number. Then it
has a third argument to indicate whether case should matter or not, by
default it matters. In the W3C Core DOM the setAttribute method has two
attributes that are always strings, and there is no third attribute.


Where IE 6 refuses to set the type (but it refuses it with setAttribute
as well as setting the type property) is when the input is already in
the document:
<http://home.arcor.de/martin.honnen/javascript/2006/12/test2006121602.html>


So I think my advice is sound, in general and in particular for the
example properties the original poster had, onclick and className.
 
A

ASM

Martin Honnen a écrit :
See above test case, it does not make a difference in IE or Mozilla
whether you use inputElement.type (or input['type']) or
inputElement.setAttribute('type', '...').

Yes that does any difference with my Firefox, but ...
The problem with IE's HTML DOM
and setAttribute is that it pays attention to the case of attribute
names and that it wants typed property values and not attribute strings:
<http://msdn.microsoft.com/library/d...thor/dhtml/reference/methods/setattribute.asp>

my IE (Mac) doesn't accept to set type attribute what you'll can try
(the function breaks/stop from this point)
So I think my advice is sound, in general and in particular for the
example properties the original poster had, onclick and className.

nothing previously declared
 
R

Randy Webb

ASM said the following on 12/16/2006 11:20 AM:
Martin Honnen a écrit :
See above test case, it does not make a difference in IE or Mozilla
whether you use inputElement.type (or input['type']) or
inputElement.setAttribute('type', '...').

Yes that does any difference with my Firefox, but ...
The problem with IE's HTML DOM and setAttribute is that it pays
attention to the case of attribute names and that it wants typed
property values and not attribute strings:
<http://msdn.microsoft.com/library/d...thor/dhtml/reference/methods/setattribute.asp>


my IE (Mac) doesn't accept to set type attribute what you'll can try
(the function breaks/stop from this point)

IE on a Mac wouldn't be my choice of a browser to choose to use as a
demo of whether something works or not.
 
R

Richard Cornford

Randy said:
ASM said the following on 12/16/2006 11:20 AM:

IE on a Mac wouldn't be my choice of a browser to choose to
use as a demo of whether something works or not.

I don't know, Mac IE might be a very good choice for demonstrating
something not working ;-)

Richard.
 
A

ASM

Richard Cornford a écrit :
I don't know, Mac IE might be a very good choice for demonstrating
something not working ;-)

some things work better than with IE 6

and ... you do what you want about info I can give ... :-(

Now I can also talk about my NC4 :)
(I doesn't more see functions with gEBI taking care if it can be used)
 
J

John W. Kennedy

Martin said:
The current W3C DOM specification is W3C DOM Level 2 HTML
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-62883744>

Dated late in 2000. IE6 (2001), as far as I can tell, implemented the
DOM 1 specs, where HTMLInputElement.type _is_ readonly.
it does not say that the type property (respectively type attribute in
IDL terms) of HTMLInputElement objects is readonly. So using that sample
above to claim a DOM implementation is incorrectly accepting changes to
readonly properties is rubbish, that property is not readonly at all.


Both IE/Win (tested with IE 6) and Mozilla/Firefox allow the above code
without errors, that is creating a new input element object and setting
its type property directly after that before the input element object is
inserted into the document:

Then that's a recent patch, because it was failing on an up-to-date IE6
as recently as October (it cost me several hours of misery, IE6
diagnostic facilities being as vile as they are).
whereas

var post = document.createElement("input");
post.setAttribute("type", "submit");

will work everywhere.

See above test case, it does not make a difference in IE or Mozilla
whether you use inputElement.type (or input['type']) or
inputElement.setAttribute('type', '...'). The problem with IE's HTML DOM
and setAttribute is that it pays attention to the case of attribute
names and that it wants typed property values and not attribute strings:
<http://msdn.microsoft.com/library/d...thor/dhtml/reference/methods/setattribute.asp>

There it clearly says that the second argument is not (always) a string
but rather a variant that can be a boolean, string or number. Then it
has a third argument to indicate whether case should matter or not, by
default it matters. In the W3C Core DOM the setAttribute method has two
attributes that are always strings, and there is no third attribute.

Hey, I never said IE doesn't suck.
Where IE 6 refuses to set the type (but it refuses it with setAttribute
as well as setting the type property) is when the input is already in
the document:
<http://home.arcor.de/martin.honnen/javascript/2006/12/test2006121602.html>
So I think my advice is sound, in general and in particular for the
example properties the original poster had, onclick and className.

Let's just say the whole situation is a mess, no matter what approach
you take.
 
R

Randy Webb

Richard Cornford said the following on 12/16/2006 12:26 PM:
I don't know, Mac IE might be a very good choice for demonstrating
something not working ;-)

You have a very valid point.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top