i·me·michael

Lets play a little game I like to call Senseless Acts of Political Correctness.

LOS ANGELES, California (Reuters) — Los Angeles officials have asked that manufacturers, suppliers and contractors stop using the terms “master” and “slave” on computer equipment, saying such terms are unacceptable and offensive.

Now you try.

In a scathing article, ppk criticizes both ALA and Christian Heilmann for the ALA article JavaScript Image Replacement.

On a lighter note, in case you haven’t seen it—Amazing 3D sidewalk paintings [via mefi via 37signals].

Everything that has a beginning has an end. Well, this ending was deeply disappointing.

I was prepared to see the best of the trilogy. What I saw was filler that didn’t answer my questions, didn’t tie up what I saw as loose ends, and didn’t serve the storyline of the main characters, which were the ones I had a vested interest in.

Minor spoilage ahead

Morpheus needn’t have bothered showing up for Revolutions. This character, this main character was about as useful to the story as the woman in the red dress from the first picture. He was there because he had to be. Because it wouldn’t have been the Matrix without Morpheus.

As for Neo and Trinity—I didn’t care for where their stories went either. To my mind it was an injustice to who these characters are, and the paths that brought them here. Actually, that goes for all the main characters. It was a travesty what Revolutions did with all the main characters. There was more screen-time and plot devoted to minor and newly-introduced characters than there was to the main four.

There’s even a scene in Revolutions that’s right out of The Perfect Storm. I was flabbergasted.

Unless you’re a die-hard, and really need to see this movie, expatriate yourself from the Matrix.

God, I’m so disappointed.

We likey the new Quirksmode. Thank you PPK.

Just a little DOM experiment in pulling a section of text out of a paragraph and making it a pull quote. What it does is use the EM element with a particular class to flag the section of text you want pulled, and then it formats it within a BLOCKQUOTE and inserts it before the paragraph it was pulled from.

So there I was staring the FIR method in the face and asking, “Why Ziploc^® the image in the CSS?”

It didn’t seem like reusable code to me. For every piece of content or text you wanted to use the technique on, you needed to add another declaration in your CSS. It becomes sort of impractical to use on dynamic sites, where content changes frequently. Don’t get me wrong, I love the idea from the standpoint of the issues it addresses, and the cleverness with which it does it, but the appeal wears off if I can only use it statically. I mean, I can’t really set this up for all H2 elements on a page, and I can’t apply it to a whole class of elements. Even the Revised Image Replacement techniques, culled at mezzoblue, don’t allow for dynamically achieving this effect. So what’s a codemonkey to do? Well, recode of course!

I went back to the beginning and asked, “What is the goal here? What points are we looking to address?” Well, we’re looking to achieve the following:

1. Enhance the graphic presentation of pages through the use of images
2. Keep the content of pages accessible to assistive browsing software, text-only browsers, as well as browsers with images disabled
3. Promote the proper indexing of content by search robots, and other such data aggregators
4. Keep the code/markup to a minimum, and avoid adding semantically ambiguous markup

I kept thinking, “Why not use an IMG element for an image?” After all, we’re trying to establish a technique for adding images to a page, while allowing the actual content, the text, to remain accessible. Why remove the IMG element from the document, only to code the image in elsewhere? Why not start with both, and then pseudo-eliminate the text? Since the code for placing images in pages already exists in (X)HTML, why not use it, and just think differently about its purpose for being there?

The purpose, in this case, is largely decorative. It conveys information to those that can view it, but it is supported by textual content, for those that can’t, or don’t wish to view images. It’s no longer the sole responsibility of the image to convey all the information. It now does so jointly, and doesn’t need to be defined in the same way a separate image might. By this, I mean alt or title text. The image needn’t be accessible, since it is there as a decorative enhancement, and is backed up by text, so treat it like any other decorative image and leave the alt attribute empty.

Point of fact, eventually, we are all going to be coding accessible image alternatives in a very similar fashion when we switch from using the IMG element, to the OBJECT element. [ed note—Yes, we know this is the second Mark Pilgrim document we’ve linked to. It couldn’t be helped.]

So instead of adding SPAN elements, and display:none to hide the text, I opted to simply cover it up with the image; similar to the Gilder/Levin method. [ed—We swear we only just noticed the similarity!]

There are two main flaws with the cover-up method. The first problem arises when using transparent images. It’s sort of difficult to hide something behind a pane of glass isn’t it? While I believe it’s possible to work around this in many situations, there will be those times when it simply won’t be workable.

Second, the possibility exists that the text you are trying to hide is longer than the image you are trying to hide it with. Again, this is a situation that can be worked around, but there is always that exception where it will be impractical. The caveat to using any method is to first make sure the implementation fits the needs of the project.

I sent my little mock-up to Dave Shea, just to see what he thought, and though he thought it was interesting, he didn’t feel it added much over using just an image. The reality is that’s true, but it’s true of the entire concept. However the basis here is still the text, not the image. And, this method uses a semantically correct element to insert an image into the document, still uses CSS to alter the presentation, and allows you to use it on any element or class of elements.

I know it’s just a cheesy little mock-up, but it may be a springboard to some other ideas. I may add some other examples and documentation to that page over the weekend.

Update!—Turns out I spoke too soon. This problem occurred in version 7.20 build 3087. After finding this little problem last Thursday, I submitted a bug report to Opera. The latest version 7.20 build 3144 does not experience this problem. I’d rather see them rev the version rather than silently change the build number, since they do not specify the build number on their download page. Anyway, this pretty much negates anything I subsequently had to say in this entry, so feel free to skip over it.

At least that’s the way I see it.

With the release of version 7.20, Opera has made a fundamental change in the way that their browser treats XHTML documents, and in my opinion the changes they have made are incorrect, and are ultimately changes that will hurt them, rather than help them.

I first noticed something was weird, after my recent upgrade at work. A script I had been working on for a website suddenly stopped working. I was pretty sure it worked prior to the upgrade, and after checking it on my home PC, I confirmed that it had. Now the trick was figuring out why it stopped working in this latest version of Opera. Was there something wrong with the code? I’m no JavaScript expert, but I was pretty sure that the code was valid. The script was based in the DOM, but wasn’t doing anything extensive, or highly manipulative. [ed—High levels of programming are out of our league.]

Validation is always a first check, and after confirming that, since I was working with XHTML, I decided to remove the XHTML headers to see if there was something about jumping into strict mode that was messing things up. Sure enough, the minute I removed the XHTML headers, the script worked again. I then even managed to narrow the problem down to the URI declared in the xmlns attribute of the head element. If I removed the URI, the script still worked. Now I was off to Opera’s website to see what changed.

Referring to their specs page, if you scroll down to the section titled XML namespaces you will see the following:

The XHTML namespace (http://www.w3.org/1999/xhtml) triggers XHTML handling in Opera.

Well what the hell does that mean? If they already support DOCTYPE switching, why do they need to trigger XHTML handling by way of the namespace? Especially since according to the XHTML spec, a namespace declaration in the form of the xmlns attribute is required for strict XHTML document conformance. It’s not as though I can leave that out. That aside, what does Opera mean when they say XHTML handling?

Again, referring to their specs, their support for XHTML is extensive, although for some odd reason they state that they don’t support the script element. Was I asleep when they deprecated the script element in XHTML? As far as I can tell, the script element is part of the XHTML specification, and Opera should support it. But I digress.

All in all I didn’t really find anything at the Opera website that told me specifically what had changed. I just came away with the general sense that they were treating XHTML pages very strictly, and like XML, so it was back to my script to see if I could debug what Opera was doing.

Where I found my script was failing was when I was looking for nodeNames. I was doing a pretty standard evaluation against a nodeName and I was getting nothing. In reality, it wasn’t that I was getting nothing, it was that Opera wasn’t finding a match.

In this example page, Opera (v7.20) fails to evaluate to true for the five P elements on the page. The piece of code that no longer works is the following:

if (obj.childNodes[j].nodeName.toLowerCase() == ‘p’)
{
	//Do Something
}

Why? Because Opera is no longer returning just the nodeName in XHTML. It is returning the nodeName plus its namespace prefix (example page 2, ). So instead of returning just p it returns html:p. Now for the first mistake. I’ll grant you that technically speaking, treating the document as XML, returning the namespace prefix is probably correct, however, HTML is not the namespace of the document or the element in question. XHTML would have been the proper prefix to return. Under XHTML, these elements are not HTML elements, they are XHTML elements. XHTML is a reformulation of HTML in XML. XHTML is not XML with HTML elements in it. So right there, Opera is wrong.

Next, returning the prefix is basically incorrect for XHTML, since it currently does not support multiple namespaces. And is this DOM 2, or are we only talking about DOM 1 here?

Lastly, with the vast move to XHTML, unless designers and developers are aware of this change, Opera is going to be breaking scripts all over the web, and designers/developers are not going to be too happy about rewriting their code just to support Opera.

Am I incorrect in my assessment? Is Opera approaching this correctly, and is it the thinking behind the scripting that’s wrong? How about some of the DOM gurus chiming in. By all means, somebody correct me if I’m wrong, ’cause otherwise I’m just going to dismiss Opera as a viable browser again.

So to make up for lost time I thought I’d share another little thing I’ve been playing with. [ed—No, it’s not that!] It’s a CSS/DOM enhanced form.

The form is basically styled with CSS, and then I use the DOM for couple of subtle enhancements. What the DOM script does is look for all INPUT and TEXTAREA elements on the page, and then set the default background color, as well as a background color for when the element has focus. It filters for text input fields and leaves button types alone. It will also set the initial value for the field, assuming you have a value in the title attribute. For accessibility reasons it’s best to set the initial value anyway, and if you do, the title attribute should match. When the element has focus, the value of the field will clear, and unless you change the value, it will reset to its default (the title attribute).

It’s just a little DOM fun, and it could probably be cleaned up some, and actually made a bit more modular, but hey, I never promised you a rose garden. Feel free to play, tweak, use, whatever. Usual disclaimer applies; meaning it works on all my Win browsers. Mac users are on your own.

So I was trying to work out a CSS version of some information that was previously formatted in a table. This CSS formatted list is what I came up with so far. [Ed note—Although coded using fixed widths, it can be modified to be variable width. And don’t think we don’t know how to do it!]

The CSS works in all my Win browsers (IE, Moz, Op, Fb, NN4.x excluded), which means it probably fails miserably on Mac. I had originally coded the CSS slightly differently, but it failed in IE5.5, so a couple of tweaks and boom one more browser nobody uses anymore.

It doesn’t look like much less code to me than the table version, but I do think it’s more semantic, has more going for it from an accessibility standpoint, and I hope y’all can make some use of it.

Update! So I re-checked the page in Opera on my home PC and everything looked fine. It’s virtually identical to my work PC as far as OS and browser versions, so I can’t understand why I saw a difference at work.

In any case, I didn’t update the page, so by way of compensation I added the variable width version. [ed—Like that was hard!] I wouldn’t necessarily say that it stays crispy in milk, but it’s good down to a width of about 400px.

Update 2! It turns out that my work PC had Opera v7.11 installed, while my home PC had v7.03. Opera 7.11 showed a little glitch in the presentation, but an upgrade to 7.20 fixed it. Yay for Opera, and yay for my browser addled brain.

About a year or so ago, I did some host shopping, and after a bit of research, I was pretty confident about my switch to a new host. I knew it was a small, two-man operation, and apart from a few glitches, and slow response to support requests, I was happy with the cost/features. I had even made a point of recommending them to anyone I knew requiring hosting [ed—Something we don’t do often. Good hosting is subjective/relative.]

So this past July was a surprise, when I started to run into problems. The first clue that there was a problem was my site went offline for a few days, though email was still working. After contacting the host, I found out that they were in the midst of a server move, something I hadn’t been notified about, and something I wasn’t completely prepared for as far as backups were concerned. I also found out that they were having a problem, and were working with their new server company, (recently aquired by Hostway), to find a quick solution. The site came back online not long after, so I made a couple of quick backups (not everything), and assumed all was well. Wrong assumption.

In August the site went offline again. This time email was down as well. One day turned into two, into three, and so I contacted them again. This time there was no response. A week passed. Nothing. I waited patiently. I emailed them. I opened a support ticket. Still nothing. I checked the host’s website. Their homepage was changed to a note that they had received hundereds of emails and couldn’t get back to everyone, but that it “should be sorted out in a matter of days”.

By the second week I was signed up with a new host, and getting ready to put things back together. Near the end of the month I’d gotten a message from one of the people I’d recommended the now funked up host to that there were some new people answering questions in the forum, so I poked my head in to see if I could get some answers about the status of my site/data.

First, it was, “We have no record of you on our servers”, then it was, “Sorry, but you should have backed up your data”, and although it was a bit frustrating, the most frustrating part was that this info wasn’t coming from the site owners/admins Aron Nimani, and Jorge Catena, but from Brandon Rivers and Martyn (last name witheld by request) of Southeast Creations, who had recently merged with the troubled HostCulture, and although they were now partnered with HostCulture, were acting as though they were just good samaritans, doing a thankless job by posting DNS settings, and fielding questions from customers wondering what the hell happened to their websites. Their lack of professionalism and experience in customer relations quickly showed, and I became increasingly irate with their detached attitude, and the pretense that they’re only involvment with HostCulture was in a support capacity.

I mean, here’s a company (Southeast Creations), who although they weren’t defending him, had decided it was a good idea to go into business with a kid (Aron) who shirked his responsibility to his customers, and then ditched them when things went bad. You think they’re helping out of the goodness of their heart? Please.

So instead of addressing the concerns of those that lost websites, they simply adopted an attitude of, “Your site’s gone. It’s your fault for not backing it up. What more do you want us to say?” Then when they had enough dealings with irate customers, they closed the thread, directed all support questions to the Southeast Creations forum, and then closed the HostCulture forum. Now they’re having fun playing at being a multi-national corporation complete with a board of directors, which you’ll notice Aron is on. All the pretty Dreamweaving and Photoshopping on the site aside, you’d think a company that professes to be a “global leader in Web Solutions” would know how to to prevent directory indexing on their site.

At the end of it all, I was left extremely upset, most especially over the fact that someone can set up a business, throw up some bogus TOS, forgoing any responsibility or liability, and leaving the consumer without any expectation of warranty for services rendered. What are you supposed to do when faced with entering into a non-negotiable service agreement with an online business? Grin and bear it?