Carpe diem on any duplicate content worries: we now support a format that allows you to publicly specify your preferred version of a URL. If your site has identical or vastly similar content that's accessible through multiple URLs, this format provides you with more control over the URL returned in search results. It also helps to make sure that properties such as link popularity are consolidated to your preferred version.

Yahoo!
Fighting Duplication: Adding more arrows to your quiver

Avoiding duplicates in the search engine index has consistently been a key concern we’ve heard from webmasters and site owners. Over the last few years, we have made significant strides in finding duplicates in our crawler and index algorithmically and provided webmasters with better tools for controlling these. Today we are announcing our support for a new HTML tag, the tag, which helps reduce duplicates by documenting the preferred URL form to access each page.

*yes, I'm done. Three days, a lot of careful planning and more regular expressions that I've ever written later, everything on my site is now cool like this ( http://www.drunkenfist.com/art/graffiti-art/black-book/index.php ) Dash heaven.

The good news is, I rarely do anything here that will tax IE6 heavily and the redesign will likely be architected in such a way that it will probably work pretty well in IE6 even without specific attention. The bad news is, 11% equals about 6000 people and the thought of annoying, even slightly, that many folks over a month worries me. The thing is, I just can't support three versions of a browser, especially when one of them is such an odd man out. IE7/IE8 are comfortably supportable browsers. IE6 plainly sucks.

Spurred on by this:

Microsoft: IE 8 won't be done until 2009

So I've got to draw a line in the sand.

Now if I can just convince them to do the same at work…

Here's the code*:

function getElementsByClass(theClass,node) {
    var classElements = [];
    var i;
    if ( node == null ) {
    	node = document
    }
    if (node.getElementsByClassName) {
    	var tempCollection = node.getElementsByClassName(theClass);
        for (i = 0; i < tempCollection.length ; i++) {
    		classElements.push(tempCollection[i])
    	}
    }
    else {
    	var els = node.getElementsByTagName("*");
    	var elsLen = els.length;
    	var pattern = new RegExp("(^|\\s)"+theClass+"(\\s|$)");
    	for (i = 0; i < elsLen; i++) {
    		if ( pattern.test(els[i].className) ) {
    			classElements.push(els[i]);
    		}
    	}
    }
    return classElements;
};

The above code works as expected in Firefox 2, 3; IE 6,7,8, Opera 9.5 and Safari 2.

Interestingly it doesn't work in Safari 3.1. Safari supports the native getElementsByClassName, so one would expect it to work alongside Firefox 3 and Opera 9.5.

It does not.

Here's a sample. Click "start" and everything should go from blue to black (which means the class is removed from the LIs) and the numbers should read "10 0". The 10 is the length of the collection returned by my function when the test starts. The 0 refers to the length after the test has run it's course and the class has been removed.

Safari 3.1 looks like this:

So the count is 10, even though there are 0 instances of the class in the DOM:

This is the code I'm running:

function testSafari() {
    $("messages").innerHTML = getElementsByClass("sample").length;
    var samples = getElementsByClass("sample");
    for (i=0;i<samples.length;i++) {
	    removeClass(samples[i],"sample");
    }
    $("messages").innerHTML += "    "+getElementsByClass("sample").length;
}

I've approached the problem from a few different angles (not exhaustive) and taking a quick look at the WebKit source it seems to me that Safari might be incorrectly caching the results of the getElementsByClassName call. I haven't had the time I would like to test this to see what might be happening in specific, but that's what it feels like.

Anyone know more about the guts of WebKit? Am I onto something? Or is my nonexistent Apple dev knowledge showing?

For the webdev crowd, anyone else seen anything like this? Is it something stupid that I'm doing that I'm just not seeing (and therefore not actually a bug)?

That's always my first assumption, but the native method works in both Opera and Firefox so I'm more confident than normal that the issue isn't my fault.

*I used to have support for a specific tag. When rewriting it I thought "I never use the tag argument, I'm dropping it." Of course, as soon as I did that one of my co-workers used the tag argument in a script he was writing for a site we were working on. I'll be adding the tag option back in.

Also, this version relies on support for Array.push(). Our little library adds it in with this:

if(!Array.prototype.push) {
    function array_push() {
        for(var i=0;i<arguments.length;i++){
	        this[this.length]=arguments[i]
        };
        return this.length;
    }
    Array.prototype.push = array_push;
}

//height for IE6. Thankfully IE6 messes up height in a useful way
height:350px;
//height for everything else. IE6 looks at this and says "wha?"
height:auto;
//min-height for everything else. IE6 is baffled by this.
min-height:350px;

I can't tell you how many times I've used this exact pattern. It actually works really well, it's just so wrong it bothers me each and every time I type it into a style sheet.

It works because the first height declaration, in pixels, is rendered by Internet Explorer 6 exactly the way the next two rules are rendered by every other browser. Meaning, it starts at 350px and then expands to fill whatever content it contains. Add to that the fact IE6 is baffled by the next two declarations (not understanding auto as a value for height and not supporting min-height in any way, shape or form) and for IE6 height is all you need.

Thing is, every other browser that matters renders the single height declaration (with overflowing content) like this:

Which is where the height:auto and min-height declarations come into play. Add those in and things start acting as expected with the other browsers- the container starts at 350px and expands to fit the overflowing content.

Since there are no "hacks", the above sheet will validate, I just hate the pattern of declaring height once and then immediately redeclaring it- especially to support a seven year old browser.

So… IE6? Are you listening? Can you please give up the ghost so I can put this pattern to bed?

Pretty please?

Check out this class attribute generate by my beloved WordPress' upload feature:

class="alignleft size-medium wp-image-4590"

See anything suspicious? I sure do. wp-image-4590 is a unique identifier being passed off as a class. Why? I actually have no clue as I'm not privy to the thought process behind that particular piece of code What I do know is pretty much demands to be an ID. When I teach this stuff to people, I say "If it's unique, meaning there will ever only be one of them, make it an ID. If there's more than one or it's a general descriptor, make it a class." So I look at that code block every time I upload an image and I frown. Then I blow away the whole class attribute away, since I use none of them.

This is just splitting hairs, I know. Using a class like that is basically harmless. But, truth be told, splitting hairs helps me solidify my ideas about the way these things should work. That, in turn helps me improve the way my crew and I do our thing. So? Hairs I split and everyone is happier.

I'm just doing my small part to make the web a better place one nitpicky, semantic post at a time.