DXHTML alternative to script-compiled CSS

I often script-compile CSS, like:

var sty='<style type="text/css">'
+ 'p { color:red; }'
+ '</style>';
document.write(sty);

How can I do that without document.write?

DOM2 Style and DOM2 CSS. Moz-only naturally.

Originally posted by jkd
DOM2 Style and DOM2 CSS. Moz-only naturally.
Thanks - can you give a brief example or point me to some documentation - I'm familiar with reading existing rules, but not writing in new ones.

would using createElement("style") along with inserting textnodes(the actual declarations) work as well? Not as aesthetically pleasing though maybe.
I can't test now.

Uh, ya! PHP! *jab jab*

:D

http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSStyleSheet

Assuming you already have a stylesheet loaded into the variable "ss":

ss.insertRule("body { font-weight: bold; }", ss.cssRules.length);

If you'd rather dynamically create a new stylsheet, then append style rules into that, I think you might be out of luck.

DOM2 CSS defines:

document.implementation.createCSSStyleSheet("Dynamic Stylesheet", "screen");

However, oddly enough they never defined a way to associate this new stylesheet with the document.

Which means you'll either need to dynamically create a <link/> element or a <style> element and append it to the head, and then dynamically insert rules to that stylesheet.

IE has a similar interface to dynamically creating rules... like addRule() or something.

I was just going to ask this very same question!

I understand what JKD has said so far, but how would you load the stylesheet?
what i want to do is to dynamically add the rule: ".accesskey{text-decoration:underline;}" to my first stylesheet using the DOM.

Well what I did in the end was like this:

//create style node
var styleNode = document.createElementNS("http://www.w3.org/1999/xhtml", 'style'); // cheers Alex :)
styleNode.setAttribute('type','text/css');
styleNode.setAttribute('media','screen');

//append to head
document.getElementsByTagName('head')[0].appendChild(styleNode);

//retrieve stylesheet object
//[assuming the style object I just created is the last one in the collection!]
var myStyleSheet = document.styleSheets.item(document.styleSheets.length-1);

//insert rule
myStyleSheet.insertRule(".accesskey{text-decoration:underline;}", myStyleSheet.cssRules.length);

But if you already have a stylesheet, you can identify that in the styleSheets collection and write new rules into it, rather than creating a new one.

You can find it by ID, but I never give <link> stylesheet elements an ID, because then netscape 4 doesn't apply any of its rules; with any luck you don't have to care about that, but just in case, an alternative method for finding a stylesheet is to give it a TITLE attribute:

var linkTagCol = document.getElementsByTagName('link');
var linkTagLen = linkTagCol.length;
for(var i=0; i<linkTagLen; i++)
{
if(linkTagCol[i].title == 'whatever')
{
//the stylesheet you want is linkTagCol[i];
break;
}
}

Thank you veruy much, that is exactly what i wanted :thumbsup:

Wouldn't a while loop there be "better"

var linkTagCol = document.getElementsByTagName('link');
var link, i = 0;
while( link = linkTagCol[i++] )
{
if ( link.title == 'whatever' )
{
//the stylesheet you want is link;
break;
}
}

Okay, I know we're talkin milliseconds or something, but that's me.

Originally posted by beetle
Wouldn't a while loop there be "better"

var linkTagCol = document.getElementsByTagName('link');
var link, i = 0;
while( link = linkTagCol[i++] )
{
if ( link.title == 'whatever' )
{
//the stylesheet you want is link;
break;
}
}

Okay, I know we're talkin milliseconds or something, but that's me.

Use the language, don't abuse it. Using a while loop to iterate through a vector (NodeList in this case) is an abuse of Javascript-specifics, and also makes assumptions about the contents of the vector (namely that none of the items will typecast to false).

Use a for-loop, that's what it is for.

Hey hey, no need to get all snooty.

Okay, I'm willing to go along here. How, though, would one evaluate as false unless the index was outside the range of the NodeList? How can a retrieved node typecast to false?

More detail on the abuse of the "specific" would help me understand and avoid further "mis-use".

There are several ways to do this while loop, including treating the result as a vector. Likewise, a for loop can be made to mimick this while loop. I think you're talking more about the condition tested, and not the actual control-structure choice.

Hey hey, no need to get all snooty.


Sorry, I didn't mean for you to take it that way. Sometimes I'm too concise I guess.


Okay, I'm willing to go along here. How, though, would one evaluate as false unless the index was outside the range of the NodeList? How can a retrieved node typecast to false?


In this case, it can't. But I like consistency, and a NodeList is essentially a vector filled with Nodes. Now, a vector can be filled with other datatypes of course, so it just seems like a better idea to me to be consistent in the method of iteration.


More detail on the abuse of the "specific" would help me understand and avoid further "mis-use".


I'm rather fond of writing code than spans languages. Saying:

while( link = linkTagCol[i++] )


Invites disaster in languages like C++. Using the more correct "item" method (array indexing on a NodeList I don't think is explicitly defined in the specs) would alleviate that issue with out-of-bounds exceptions, but it still feels wrong.


There are several ways to do this while loop, including treating the result as a vector. Likewise, a for loop can be made to mimick this while loop. I think you're talking more about the condition tested, and not the actual control-structure choice.

The condition tested is a concern, as well as the way you proceed to the next Node. You're treating the NodeList as a NodeIterator, whereas instead of calling a .nextNode() method, you're manually advancing the "pointer".
However, nextNode() is guaranteed to be safe no matter the language or the size of the list, while [n++] isn't necessarily safe.

Call me picky, but I've been alternating between 3 different languages on a daily basis, and it just makes things that much easier to write similar code between the 3. :)

Okay, I can understand all that. I wasn't even contemplating the cross-langauge thing.

Of course, using a for-loop "manually advances the pointer" as well. I mean, a for-loop like brothercake's is really no different than

var i = -1;
while ( ++i < linkTagCol.length )

Or in this case, going backwards would work too

var i = linkTagCol.length;
while( i-- > 0 )

So if using item() or a nextNode() type method is preferred, why the props for the for-loop?

Of course, using a for-loop "manually advances the pointer" as well. I mean, a for-loop like brothercake's is really no different than

var i = -1;
while ( ++i < linkTagCol.length )


Correct. And we have a for-loop designed especially for that case of iteration.

for (var i = 0; i < linkTagCol.length; i++)

Looks and feels much nicer.


So if using item() or a nextNode() type method is preferred, why the props for the for-loop?

item() is just a more correct replacement for the for-loop.
for (var i = 0; i < bla; i++) {
current = mycollection.item(i);
}

Would be my preferred way of iterating through a NodeList. A for..in is debatable:
for (element in mylist)
I'd probably prefer more, but I can't remember offhand if just the Nodes appear, or if you also get all the JS property and method stuff with it.

Next up is the entirely different approach, an abstracted iterator datatype:

while (iterator.nextNode() != null) {
doSomething(iterator.currentNode);
}

Or while (iterator.nextNode()), or however much you want to rely on typecasting to booleans.

Thanks for sharing this site.. I ma a new site owner and I know that this will be helpfull for me.. I will try your suggestion tonight with the help of a friend.

name necklace (http://www.name-necklace.com/)