IE6 and input type changes: short answer, ie6 sucks, long answer:
The Problem
I ran into another problem the other day native to ie6 (well ie7 and ie8 too, to be fair) where by I was trying to dynamically change a text input field from type=”text” to type=”password”. Safari, chrome and firefox had no issues. It was a simple as node.type = ‘password’, or since I was using mootools, node.set(’type’,'password’). Resolved. But wait…
Then I ran into IE6, whereby I got a nice “This command is not supported.”. It took me a while to figure this out. At first I thought the node didn’t have mootools ’set’ method for some reason (didn’t access it right?), but once I found out the reason, I looked for workarounds. None really. Other resolutions that attempted completely different code, but no workaround for IE6 specific to change the type. It seemed microsoft had decided that an input field’s type should not be able to change after it’d been loaded. I’ll get to that in a second
My Resolution
Spit out password fields on the page for when it gets sent back to the client. When the DOM has loaded, iterate over the input[type=password] fields (I did this via the mootools selector node.getElements(’input[type=password’)), make them hidden (via add a class or adjusting it’s style property), and make a new node that has an input type with the text value. I added the same classes to it as the password node had. When a user focused on the field (the text one that was originally a password field), I destroyed it, and removed the hidden class.
What really bothered me
“This is an expected behavior. One can’t change the type of an INPUT element once it is already created and became part of the DOM. The behavior is documented below in the Remarsk Section:”
That was microsoft’s response in their developer forums. That was last year, and instead of addressing it as an issue and complying with a standard, they were stubborn and basically refuted the claim as a bug. I’m not sure how I feel about the standard. I understand why an input type is set after the DOM has been loaded. I can’t change a tag type from div to span after the fact (or at least I shouldn’t be able to). Ideally, in my own head that is, every input type should have a separate tag value. <button />, <select />, <file />, <text />, <textarea /> and <password />. I think that’d be ideal, and save a lot of confusion.
Either way, that’s my resolution. M$ response is kind of sucky, but what can ya do.
Weird discovery: firefox converts $_SERVER, SF doesn’t?
This is definitely up there for me; a very weird discovery about how firefox and safari differ in the way the _SERVER array is returned.
print_r($_SERVER);
exit();
Run that code in a php script; then check the source in both safari and in firefox. For the path, try something like index.php?name=what’sup
The weird thing comes in with the fact that in Safari, the apostrophe isn’t converted/encoded, where as in Firefox, it is. I’m not really sure how I can explain this, and if I’m missing something, but it’s caused me a great deal of frustration and debugging. The only thing I can think of is that safari sends along different headers in the request than Firefox does, and therefore gets different results. I’ll look into it and update this post, but thought it was worth mentioning incase anyone else runs into the same type of problem.
Flexibility: Server side vs Client side
I’ve been told by many people, veterans in their respective industries such as family friends, family members, etc., that when you’re in a technical field, the best type of job security is to specialize. I imagine this would extend to a lot of different areas (entertainment, finance, management, etc.) but especially in the technical/programming arena, I find it’s very true and productive.
What I mean by this is, be very very very good in a very very very specific field/discipline. Be the best out of all the people you know. If you’re a server side developer, don’t try and learn all the server side languages; rather be the best object-oriented php5 developer who knows the ins and outs of PECL and PEAR extensions. Or be the best db admin who can optimize an InnoDB mysql engine better than anyone you’ve met. That way, when anyone is looking for something specific, you’ll be the first person to come to mind.
I’m too obsessive to follow this though. I would hate being really good at one thing, and then just having to depend on someone else to help me out with the other. Because of that, I’m not very very very good in one area, rather I’m pretty good in a bunch of them. But this is actually still making me fall into a very specific niche; namely, if someone is looking for one guy who can configure a linux/apache box, set up and admin a db, set up a server side dev env., do designs in photoshop, turn them into html/css/js, and add in ajax/js techniques to make a more interactive application/website, I’m that guy. If I were to work in a company with other developers, I probably wouldn’t be better than anyone in any specific area. I wouldn’t be the best JS guy, or CSS guy, or DB guy, and because of that I’m probably not suited for a lot of companies, but for my current contract, they needed one guy who can wear 5 or 6 different hats.
So ironically, the fact that I don’t specialize in one specific area, rather 5 or 6 of them, makes me specialized. It makes me the specific person to go to when you need one person who is pretty good in a bunch of areas.
If you read the title, you might wonder what this has to do with it; it’s a segway into my point. On my current project, I’m having to do both client and server side dev., and it’s making me realize something. The server is way more flexible than the client.
—
Here’s why.
—
The server is usually a linux/unix box. It’s role in a web application/site is to fulfill client side requests, push out data, yadda yadda. It normally doesn’t do anything visual. The client, however, is intrinsically visual. It’s supposed to represent a server architecture in a cohesive, logical way. Now when doing client side dev., you have to normally worry about ie6, ie7, ie8, ff3, sf, opera and chrome (not always this, but thats the goal). At times you’ll run into things you can’t do in the others (CSS3, certain types of ajax callbacks, etc.); sometimes they’ll be things that aren’t worth the time, but other times, it just can’t be done. There is no hack or way around it, it just can’t be done. It’s frustrating to say the least, but it’s making me really value and respect the entire web paradigm and the server’s role in it all.
—
How does this relate to my introduction?
—
I find that there is a lot of ego involved in the web industry. A lot of butting heads in terms of how important people/disciplines are in the grand schemes of things. There are the executives/bus.dev. guys, marketing dudes/gals, client side developers, server side developers, operations/db dudes, and creative/design people. That’s generally how I break it down, and with some exceptions, everyone thinks their role is one of the most important ones. They’ll pretend and put on a face that they don’t believe it, but at their core, there is a lot of pretense about their own positions. I suppose that’s normal considering that’s their professional role.
I’ve always maintained (and have a post that should be coming soon) that one of the most important roles, which I’m terrible at and in no way consider myself part of, is in fact the creative/design ones. I’ll leave my reasoning here for another post. My understanding of the flexibility of client vs server side therefore comes from the fact that I don’t specialize in any one area. If I were a operations/db guy, I’d think the db was the most flexible. If I was a pure server side guy, I’d think it was the most flexible, and the same for the client side.
The point I tried to make with my introduction and the conclusion of the server side being the most flexible is that because of my lack of specialization (and therefore abstract specialization) in the full life cycle of a web application, I think I’m in a unique situation to make that judgment. It’s not right or infallible or anything, but I come at it from a unique perspective. My career/financial stability doesn’t hinge on any one area of the cycle. I could find a job doing client side, or server side, or db/operations, maybe even some mild graphic/creative design stuff. Even as far as more on the management and marketing stance, I think I’d be alright. And because of this, I think I’m in a convenient location to sit back, analyze where any bottle necks are in flexibility, and make a call on what makes the most sense and is most accommodating.
And my conclusion? The server side is way more flexible. There is never a point/time when I can’t do something. It might take more time than I’d hope, require more resources (memory, developers, etc.), but at no point do I have to create ‘hacks’. It’s logical and follows procedures and standards. I think this is mainly because it’s been around longer. The server side env. is really just a programming environment. It’s been around, and perfected, since the 50’s. The web client-side has been around, for the most part, for less than 15 years.
That being said, the client side is getting better. With Flash, Adobe Air, Google Gears, and some really cool plugins (Rhino, for one) the client side is trying real hard, and milding succeeding, in become less of a bottle neck for an application. I think with time it will succeed, but as it stands right now, the server side is where it’s at. Fewer headaches, and more logic, make it one of the most time-satisfying parts of the projects I’m doing lately.
Why I use Safari.
There are many browsers out there: IE6, IE7, IE8, FF, Opera, Safari, Chrome
Then there are tons of mods for each of those. On the mac, a few lesser options (FF, Opera, Safari, soon to be Chrome). I used to scoff at Safari users when it was around the 2.0 release (even 3.0 seemed crap to me). When I adopted the Mac, however, Safari fell into a different light for me. The number one reason it did was because of it’s speed.
In the 4.0 release, the first thing you realize about Safari is how fast it is. While non-web developers would often remark that there isn’t much of a difference, it’s something you pick up very noticeably when you spend 10 hours in a browser. It’s not that every second counts, it’s just that you notice it and lean towards the one that will save you any time at all.
As a developer, it misses many things like Firebug, plugins (has a few, but not comparable), web developer toolbar, and while Safari has it’s own web-kit based inspector, in my opinion, it’s terrible. You can view the DOM, but not do much with it.
I find that the only time I’m not using Safari is when I need to do some post-render editing using firebug, or test out a plugin in FF; any other time, Safari and it’s speed an UI dominate for me. My only hope that it gets a little more plugin compliant to make it more useful more of the time.