Stylesheet problem with generated nodes
jes...@gmail.com
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.
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.
--
Martin Honnen
http://JavaScript.FAQTs.com/
VK
jes...@gmail.com wrote:
> 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';
jes...@gmail.com
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);
}
John W. Kennedy
> 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.
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.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
John W. Kennedy
> 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">
Your CSS is a mess.
<style type="text/css">
#historyList a:link { color: blue; text-decoration: none }
#historyList a:active { color: red; text-decoration: none }
#historyList a:visited { color: blue; text-decoration: none }
#historyList a:hover { color: green; text-decoration: underline }
</style>
--
Randy Webb
<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.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Martin Honnen
> 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:
<http://home.arcor.de/martin.honnen/javascript/2006/12/test2006121601.html>
> 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/default.asp?url=/workshop/author/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.
ASM
>
> 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/default.asp?url=/workshop/author/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
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Stephane Moriaux and his (less) old Mac already out of date
Randy Webb
> 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/default.asp?url=/workshop/author/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.
Richard Cornford
> ASM said the following on 12/16/2006 11:20 AM:
>> 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.
I don't know, Mac IE might be a very good choice for demonstrating
something not working ;-)
Richard.
ASM
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)
John W. Kennedy
> John W. Kennedy wrote:
>
>> 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>
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.
>
>> 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:
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).
> <http://home.arcor.de/martin.honnen/javascript/2006/12/test2006121601.html>
>
>> 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/default.asp?url=/workshop/author/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.
Randy Webb
You have a very valid point.