tagsToLowerCase()

Forgive my ignorance, but when would this be useful? When working on other people’s bad code?

By the way, it should be known that I keep my Wolf function requests to a minimum these days. For any youngsters in the audience, Googling is a much better way to generally solve problems like these. Maybe my Googling skills are in decline, but I looked for more than an hour and found nothing. I even tried The Dutch Wolf first but he was unsuccessful (something about being drunk and not coherent enough to grapple regexes at the time).

The final loop can be reduced/simplified to: return html.replace(/(</?[a-z][a-z0-9]*| [a-z]+=)/gi, function($0, $1) { return $1.toLowerCase(); })

Hmm.. I was working around the exact same problem (in Safari) and used a php function instead. But I took a completely different route—walking through the tag character by character, keeping track of whether I was in an attribute or not. I also applied

The performance improvement in mine is probably negligible with modern computers. Yours is certainly prettier.

Now I have to think about where that action makes more sense, in the browser or on the server.

Oh come on, I wasn’t drunk. Just very tired, and with somewhat higher levels of caffeine and alcohol running through my veins. And I had a good excuse.

I remember doing something really similar for the purposes of getting the innerHTML to look right. Ultimately, I ended up addapting Wubben’s “importNode” function from his site (takes a reference to an html node):

function cleanedInnerHTML(oNode) {
  var oFront = "";
  var oTail = "";

  if(oNode.nodeType == 1) {
    // tag
    var tagname = "<"+oNode.nodeName.toLoweCase();
    for(var i = 0; i < oNode.attributes.length; i++){
      tagname += " "+oNode.attributes[i].name.toLowerCase();
      tagname += "=""+oNode.attributes[i].value+""";
    }
    tagname += ">";

    // tag on end of front
    oFront = oFront + tagname;

    // close on end
    oTail = "</"+oNode.nodeName.toLowerCase+">"+oTail;
  } else if(oNode.nodeType == 3) {
    // text adds to front
    if (!oNode.nodeValue.match(/^s+$/)) {
      oFront = oFront + oNode.nodeValue;
    }
  }

  if(oNode.hasChildNodes()){
    for(var oChild = oNode.firstChild; oChild; oChild = oChild.nextSibling){
      oFront = oFront + this.generateNodeCode(oChild);
    }
  }

  return oFront+oTail;
};

The results of which were then kicked over into flashvars. It’s purpose was to pass an entire UL navigation structure into flash as proper XML (of which flash could easily deconstruct and build it’s menu dynamically).

Well, my anonymous function works in Safari 2.0.3 and I do not have access to 1.x :]

It would seem more practical to do this on the server rather than with JavaScript… but hey, if you say it’s useful…arighty then.

Thanks, thats a handy function to have.

First thing the function does is cinch up any space around attribute equal signs.

Actually, the first line of this routine cinches up the space around any equals sign followed by a double or single quote, not just those within attributes. So if run this against a code example like:

$foo = "string value";

it’ll cinch the space around that equals sign, too.

Well, Reg Ex can be expensive, and innerHTML is evil. So, how about a pure DOM solution:

//    get the source of a node
function getNodeSource(node) {
    var source = "";
    //    normalize tag case
    var tag = node.nodeName.toLowerCase();
    //    attributes for tag, normalizing attribute name case
    var att_str = "";
    if (node.attributes.length > 0) {
        for (var j = 0; j < node.attributes.length; j++) {
            att_str += ' ' + node.attributes[j].name.toLowerCase() + '="' + node.attributes[j].value + '"';
        }
    }
    //    source for child nodes ("innerHTML")
    if (node.childNodes.length > 0) {
        for (var i = 0; i < node.childNodes.length; i++) {
            //    element nodes
            if (node.childNodes[i].nodeType == 1) {
                source += getNodeSource(node.childNodes[i]);            //    DEBUG-RECURSION
            }
            //    text nodes
            else if (node.childNodes[i].nodeType == 3) {
                source += node.childNodes[i].nodeValue;
            }
            //    comment nodes; broken in Safari... sigh
            else if (node.childNodes[i].nodeType == 8) {
                source += '<!-- ' + node.childNodes[i].nodeValue + '-->';
            }
        }
    }

    return '<' + tag + att_str + '>' + source + '<' + '/' + tag + '>'; 
}

Seems a bit snappier than your original for large nodes. Only tested on Firefox (fine) and Safari because that’s what I have handy. Unfortunately, Safari doesn’t understand comment nodes (node.nodeType == 8 or node.nodeName == “#comment”) so on Safari this will strip comments, but who comments their markup ;)

Whoops.. just looked at Jakob’s comment, which is doing pretty much the same thing as mine. Sorry ‘bout that!

I wrote something slightly related in HTML to XHTML.

While that is a great function to use for the task, I agree with Jakob and Jeff. It’s just another reason why innerHTML should not be used. Sure it’s easy and convenient, but isn’t it lazy? And how long will it continue to be around? Mike, is this just another one of those things that you’ll change when it stops working and not do it right the first time around? And please don’t take this as rude, I’m genuinely curious as to why you’re using innerHTML.

Zack:

Mike, is this just another one of those things that you’ll change when it stops working and not do it right the first time around?

Ummm, I’m sorry, do I have a reputation for not doing things right that I don’t know about? Or are you just speaking in general terms? I don’t think I’ve ever coded anything that has “stopped working” because of browser evolution.

Whether innerHTML or DOM doesn’t matter so much to me, really. InnerHTML is not going away any time soon… like any time in the next five years at least. It may be “going away” from an “uncool to use” standpoint, but not from an “actually works” standpoint. Part of the reason I needed this code to begin with was to deal with the inadequacies a spellchecking component we just launched. I guarantee you that the spellchecker will be updated/replaced long before innerHTML stops being a viable fix. That said, I do recognize the long-term benefits of DOM methods vs. RegEx methods.

Mike,

Cool. That answers it. Thanks.

And what I was referring to was from your article, March to Your Own Standard where you said:

If I only had a few small errors on a few random pages around my site, I could easily miss the day when “the big switchover” happens and wind up with broken pages I don’t know about. And since this code is in the form of a server-side include, I can freely remove it with a few clicks.

And no, I didn’t mean that you weren’t doing things “right”. I was just wondering if using innerHTML was another one of those tests (referred to in your article). You do amazing work (which is why I read your blog regularly) and I am just curious as to your reasoning behind it.