target.value = target.getAttributeNode(‘value’).nodeValue;

I’m sure I’m about the millionth person to discover this, but I couldn’t find it anywhere using standard searches, so I thought I’d try to emphasize it here so others could find it. (Hopefully it’s not so common that everyone else knows it!)

At first, I used the following:

target.value =  target.attributes.getNamedItem(‘value’).nodeValue;

Then I looked at Flanagan’s Javascript: The Definitive Guide (using his amazon associates link),  where he states that IE implementation of the attributes array,”makes it impossible to use this feature portably.”  He doesn’t mention which version of IE (this specific line of code worked in IE6, IE7, and IE8a), but I figured I’d go with the more general version.

If you read this, I hope I could save you a bit of time.

P.S. – I used IE8a’s Debugger to help.  Here’s hoping they develop it further before the standard release.  It’s MUCH better than flying blind, but I can’t imagine a less helpful message than specifying an object in the console, and seeing “{…}”.

First, the biggest. IE8 has been released in initial beta. The release was also included a general overview of IE8’s new features and fixes. It’s actually quite a lot of information to absorb all at once. I’ve skimmed a number of the IE8 whitepapers, and feel the biggest changes are W3C’s WIA-ARIA support, Acid2 compliance, the javascript selectors api, and their assertion of achieving CSS 2.1 compliance. Of course, the devil is in the details, and there is no company for which that statement is more true. They have a lot of work ahead, and we know they talk a good game. The big upside, however, is that they are actually talking about it. Out in the open. Big step, and I applaud them for that.

The other biggest buzz of the day was from Yahoo, in announcing the beta of their Fire Eagle service, an API for broadcasting your physical location to the web. I wouldn’t call it earth-shattering, but I think that there’s a good chance a number of cool things are built with it. Watch the video of it’s introduction, and then take a look here to quickly get an idea of the details. It would appear from the details that it was written in a highly usable way.

Of more direct importance to me, Google has announced their Contacts API. I despise when sites ask me to enter my username/password for other sites. The most offensive request is for Gmail. I don’t have any interesting emails, let me tell you… but I certainly don’t want to let others read them. The Contacts API is a safe way for distribution and use of your Gmail contacts, without threatening the security of your Gmail account or your other Google-stored information. With this, I should be able to sync my Gmail contacts with my desktop mail contacts. I’m very happy about that.

Heading up the long-since-overdue category, AOL has announced they’ve opened their Instant Messenger Protocol, OpenAIM. Finally. I remember ages ago when… well, it’s all in the past now. That’s one big wall that has been broken down between protocols, and hopefully Yahoo and Microsoft will fall in line. It will be great if other apps can finally use the features that have been limited to the AIM client for all this time. I use Adium and Pidgin most of the time (Adium, I believe uses Pidgin’s core), and look forward to seeing what they do with the new open protocol. (On a personal note, hopefully this doesn’t spell any negative news for my friends who work on AIM.)

And to round things off, here’s two smaller releases today (one based on IE8’s Activities):

• The Firefox Operator plugin (for Microformats) has already given a go at implementing Activities, which were announced at today’s IE8 overview.
• The New York Times has contributed a perl module to CPAN. Looks like a useful profiling tool, especially since it profiles line-by-line.

Seriously, thank you Microsoft.  Here’s to the continued spreading of good will.

Jeremy Keith, my favorite famous-web-developer-that-I-watch-from-afar-via-his-blog (sorry, didn’t have a better term for that… he seems like a fun guy) has written a follow up post about the IE8 doctype meta mess. As I’ve come to expect, he has eloquently suggested a rational and positive approach to the proposal. As I mentioned in my last post, the meta isn’t really that terrible, while the default behavior is. Jeremy, along with others, suggest we need to politely and intelligently urge Microsoft, hoping they re-consider. This of course, is the correct course of action. Insults, and things of that nature are just a waste… life’s too short.

The problem, is that life is short. The list of things that we’re waiting on from Microsoft is long. And there is very little crossed off! We’re still waiting on correct handling of CSS. We’re still waiting on correct javascript behavior. I worry that it will be forever before Microsoft takes it’s turn in this game.

I’m all for civil discourse. This IE8 hub-bub made me instantly think of an online petition. But while I will be cheering Microsoft on, excuse me if I keep my fingers crossed behind my back. Will Microsoft make the next move? Will they pause the game and get back to it? Hopefully. My father always told me that we had a relative who would pretend to sneeze while kicking the checker board. That wouldn’t be nice, but it would be swift. A game ended by neglect may be far more painful.

First, I don’t really care about the meta.  It’s fine… it is just one more trick to add to the pile. Generally, I agree with Eric Meyer’s points, that it’s better than browser switching.  And it is.  It’s also better than conditional CSS comments.

There are a few problems that I see, however. The first one was actually thrown into my lap as a twitter discussion between Jeremy Keith (down-to-earth web guy) and Chris Wilson (works on IE). Following the twitter-timeline, first, second, third. Apparently the default behavior for rendering a document with a HTML 4.01 doctype will be IE7. That’s right, it doesn’t fall through, it will be stuck on IE7. That is just wrong. Hopefully, both Jeremy and Chris and the other powers that be work that detail out further before Microsoft proceeds.

My second worry is the case of “edge.” Edge, as far as I am concerned, stands for <i>bleeding edge</i>, and that implies an experimental version, where results will be unpredictable.  (I infer that definition based on every other software release that I’ve heard of.) Hopefully that’s not the case, but there sure as heck better be a concrete definition of what they consider “edge”.  Hopefully they’ll throw a “current major version” in there as well.  Who knows.

The third, and probably largest concern that I have, is that we are now relying on Microsoft to include past browser rendering attributes into current browsers. So IE8 should be able to render all of IE7’s quirks, as well as IE6’s quirks. Based on the fact that Microsoft had a hard time fully flushing out all of the CSS standards for so long, whats to say that that they’ll accomplish this in full. Additionally, there are the worries that including past rendering attribues will yeild the “bloatware” that Eric mentioned.

And finally (at least for today) there’s the mess of doctype and meta.  Now you get to define things in both places.  It’s just sortof kludgy.  One more thing that I have to memorize, and I hate memorizing things.

Anyway, it’s Day one of this stuff, and there will be much discussion to come, and I’m guessing a lot of other stuff as well.

[that, or they stole the screenshot from some place!]

While all of the other browsers that I tested… for both Windows and Mac display the default font (serif) set to .8em as glyphs that are 9 pixels tall, Firefox for Mac displays glyphs that are 8 pixels tall, but with 1 pixel of anti-aliasing on top. The difference of one pixel usually doesn’t mean much, but when dealing with font-sizes that small, it makes a big visual difference.

I submitted a Mozilla bug report which has not yet been picked up, but I’m not sure if there’s anything to be done, especially if the rendering engine is at all based on the system software (doubtful, since none of the other browsers work the same way). I wonder if the release of MacOSX Leopard is going to affect this.

Gotta love the Mozilla people, though. It’s such a relief that you can even submit a bug report for something like this. A chance for actual interaction, and a chance to better the product. I only wish Microsoft would pay a little attention.

It is surprisingly hard to make the new act like the old. I am pretty good with my CSS, but when you have different parts that can expand to huge sizes, both horizontally and vertically, it is quite the challenge. Also, when certain expections have been set by use of tables, it is hard to design around them. There is only one widely supported html tag which can resize a collection of block-level elements similarly, and that would be a table. And yes, I have had to revert to a few tables (with some crazy CSS trickery on top).

I have found myself longing for Microsoft to catch up to other browsers, specifically regarding support of display: table* attributes, but I’m not really sure why I even looked.

Aside from the technical difficulties, my main problem as of late has been focus. I have focused so long and intensely on this one project, it is beginning to blur together. Today I was making mistakes in my code that I would have never normally made. And I had to think…for a rather long time about a conceptual problem concerning whether a certain piece of code should be put in an include, or in the calling source.

I guess I don’t really know how “long” is “long” to be working on a project. Something I will have to figure out gradually, I assume. I am glad to be able to recognize the problem, as I can now see if I can work on de-bluring my vision of the project. Maybe it simply requires a different perspective. That being said, one approach that I will take before anything else is to get a good long night’s sleep tonight.

However, there were requirements for its behavior. The tabs were not allowed to wrap around to the next line. They also could not just drift off the right side of the page. Everything had to be shown. And it was alright for the individual tabs to wrap and grow taller. Basically, I was told the nav had to act like a table, just not in so many words.

Because I am likely more standards-driven than most doing similar work, I wanted to stick with the list. Doesn’t make any sense to have non-tabular data in a table, I thought. Within a few minutes, I had found a semi-solution. W3C recommends the display attribute having a “table-cell” property, which was just what I was looking for. Threw it in my code, hit reload in Firefox, and wham, there it was. Needed a slight bit of tweaking, but it was working for the most part. Then I alt-tab’bed over to IE7….

Nothing.

Low and behold, Microsoft hasn’t added that to IE. Of course not. Why would they? It’s only been in the recommendation since… you know, May 1998. At least! (I don’t have the heart to look any further back).

I am not “new” as my sister would say… I know how it is. I hadn’t expected it to be there, but the more work I had to do on an alternate table-based solution, the more it annoyed me. I keep hearing more and more about the CSS3 recommendation, adding more elements to HTML 5, and all of these other grand documents, which all currently amount to little-to-nothing. Maybe I am missing the point, but if 1998 is going to be ignored, why should 2008 be any different?

I am going to keep this rant short, the rant wasn’t really the point. The greater point is that was enough of a call-to-action for me. That’s what it took to realize I should start looking into what I can do about giving certain browsers a push in the right direction.  They seem to be lost.