Unfortunately, some people aren’t ready to let go. We have to give them incentive to upgrade (free!) to a better browser. People aren’t going to stop using something until it stops working – so let’s make it happen. If websites start to look like junk in the IE6 browser – maybe people will consider upgrading.

Yes yes, I know, there are many corporate elements / reasons / excuses that companies continue to use IE. So fine, they can keep using IE6 for their ancient intranet applications if they want. They can still download something like Firefox or Opera for everything else. When, or if, it becomes cumbersome to use 2 different browsers to 2 different activities – then maybe it will be worth it to them to consider revamping their software, but there are few solid arguments to keep support and many to drop it.

I stopped supporting IE6 about 6 months ago, but I’m willing to get on board for the whole ‘lets make some waves’ change. Just to make sure it’s clear – when I say ‘stop supporting’ I simply mean that there should be a rollback for visitors coming to a site using less than IE7 [conditional comments a good solution here] to a plain text version. Accessibility is still an issue and since we all have simple text degradable versions of our sites (right?), this is just going to throw the IE6 users into that bunch with the old Netscape versions and plain text browsers. You might even consider adding a warning to your IE6 users that they should consider upgrading to a modern browser.

If you need help convincing someone (or yourself!), take a look at the nicely compiled reasons to upgrade from IE6.

For me, it’s time to throw in the towel, say our goodbyes – and continue moving forward.

~Nicole

For those web developers who have been too busy to check their feed readers lately – here’s the short version of what’s been going on:

Microsoft let us know that they were planning to implement a ‘new’ method of … well, let’s just say they wanted to give the browser an identity crisis. The decision they came to was that IE8, although it would be much more standards compliant than IE7, wouldn’t act like IE8 by default. It was decided that IE8 would act like IE7 unless you specifically told it to act like IE8. This decision was backwards, illogical, potentially a huge issue for developers, and really just a waste of all those new ‘bells and whistles’ the IE8 is supposed to have in terms of how well it renders website code.

The way they had planned to make this work was to have developers add a meta tag to all pages that they wanted IE8 to actually read using IE8, instead of IE7. Aka: Modern browser sniffing comes into IE8.

These aren’t the only issues, but I think that Robert O’Callahan has already summed them up quite nicely for you to read, so I’ll point you his direction for a good summary. If you’d like more information, and responses to how we reacted to this first bit of news, please check out the links compiled over at Digital Web.

Anyway, that was a little over a month ago. Yesterday, we got a pleasant surprise.

Microsoft released notices on their press site and the IEBlog saying that they have reversed their decision.

To quote the IEBlog:

Now, IE8 will show pages requesting “Standards” mode in IE8′s Standards mode. Developers who want their pages shown using IE8′s “IE7 Standards mode” will need to request that explicitly (using the http header/meta tag approach described here).

I think that Eric Meyer sums it up nicely in his post where he indicates that not all issues with the meta tag are gone (which will still exist but not be required to make IE8 work as the new browser), but that this is a huge difference for the better.

There is also some curiosity about whether or not this change was made due to current legal issues affecting Microsoft, as in their press release the following is found:

“While we do not believe there are currently any legal requirements that would dictate which rendering mode must be chosen as the default for a given browser, this step clearly removes this question as a potential legal and regulatory issue,” said Brad Smith, Microsoft senior vice president and general counsel.

In any event, the new IE8 will now act like IE8 by default (what a concept!). It is a sound, logical decision. I do have some concern as to how they will respond if the beta comes out and there are many complaints (as there have been with past browser versions) from web developers who didn’t prepare themselves and their sites for the change. I hope that MS won’t be easily swayed later toward reversing this decision again going back to the previous one just to appease developers who were lazy in their preparation, because this change will help developers who work with modern technologies – and those developers are the ones making the real innovation these days.

~Nicole

If you head over to http://ui.jquery.com/ you can see the new demos online.

Here’s a little comparison of the two for you to look at.

The Accordion

jQuery:

Mootools:

Codewise they are similar in scope. Both use containing <div>s to manage the accordion feature. Now the demo on the jQuery page uses more <div>s than I would like, but there is another page of demos that shows it’s not actually necessary to suffer from a massive case of <div>’itis in order to make it work. In fact, one of the examples uses HTML that is pretty spartan and that’s great. The Mootools accordion uses less <div>s in their demo, but is a bit heavier on the classes.

However, jQuery tops Mootools on one small (but major) issue in the demos. I’ve always disliked the fact that the Mootools accordion demo shows how to set the default content tab of the accordion by putting the text in the Javascript that will show on load. That’s a HUGE accessibility issue, and isn’t very practical unless there is non-essential content in the first tab to load (but then why would it be your first tab?). jQuery doesn’t do that.

The Javascript call for the accordion is:
jQuery('#myaccordion').Accordion();

<div class="basic" id="myaccordion">
<h3>Tab 1</h3>
<div>
<p>The content to show.</p>
<p>The content to show.</p>
</div>
<h3>Tab 2</h3>
<div>
<p>The content to show.</p>
<p>The content to show.</p>
</div>
<h3>Tab 3</h3>
<div>
<p>The content to show.</p>
<p>The content to show.</p>
</div>
</div> <!-- end the accordion wrapper -->

And it ends up looking similar to this:

jQuery has separated the control of which section shows first by putting a function and parameter set in that handle it separate from the content. You can see those here.

The only catch is that you can’t do this out of the box with jQuery. The function is dependent on the Dimensions library addon, which you can get here.

In the end, I think jQuery just built a better accordion.

~Nicole

There are alot of people out there who tout the power of all these point-and-click, drag-and-drop, bait-and-switch? type of visual editors out there. I’ve yet to find one that I really liked. Beyond that – one that didn’t require me to go back and spend alot of time editing out incorrect code inserted by the visual editor. I’m open to suggestions, and I do try out new software on a regular basis – I’m just incredibly picky. When I create a design for a client, or for an open source release, I want the code to be flawless. The fact that there are ‘popular’ web development software programs out there that still create the font tag bothers me. Even more dumbfounding to me is the fact that some new web development software is being created that does the same thing.

In any event, I’m beginning to feel old in the world of technology. When I talk to some other ‘new’ techs, I realize they are probably seeing me as some sort of relic because I prefer my Linux computer and I code by hand. A teeny part of me wants to laugh and say ‘No no, I just started using Linux a year or two ago and I didn’t always code solely by hand.’ But the rest of me wins and I tend to just ignore the ‘looks’ and keep on with the subject. I think it’s amusing that to some people ‘hand coding’ makes you a relic, and to others it makes you a ‘god’, while to me … it just tells me that you probably have good attention to detail.

But before I close out this brief discussion about coding by hand, I have to mention one of those inevitable questions I get asked when people find out that I code by hand:

What software do you use for that?

You know… I’m never sure whether to laugh or cry when I hear that. Sometimes I just find myself staring in dumbfounded amusement for a moment. When my mind has stopped reeling, I slowly say “Erm… a text editor.”

The subsequent question is typically: “Which one?”

So here’s my answer, for one and all:

When Slumming in Windows: I use PSPad.
When in Linux: I use gedit mostly, and occasionally Bluefish.

Now, don’t get me wrong – I do use content management systems to make my life easier. In fact, I’m a big proponent of them so long as they generate good code (ex: WordPress) . But everything that goes into those systems – that’s coded by hand.

~Nicole

Before I continue ranting about how Microsoft seems to get a thrill out of coming up with one developer-frustrating bit of news each month, I’m going to backtrack a bit and explain what I’m talking about…

In the SitePoint newsletter released on January 10th, there was a rather major article posted. The title of the article was “Microsoft Breaks HTML Email Rendering in Outlook 2007″ and can be viewed online in the archive. The article was republished on the main SitePoint site and incited a slew of comments, as expected. After that, we saw the topic covered over at Campaign Monitor, and Pixel Acres.

Why all the fuss? If you haven’t read the article, let me summarize the general issue from the standpoint of a very irritated web designer (one of many in this case).

Once upon a time…

…Web developers/designers were finally relieved to see IE7 in some sort of standards compliant form (even if it isn’t up to specs yet, it’s better than it was – even though they completely ignored the usability experts who were warning in beta that the interface was awful, but that’s another story entirely).

… This has a secondary benefit which made developers happy, because IE is used for rendering/display of emails in MS Outlook. With IE7 running with more standards compliance, that would mean that HTML emails would hopefully offer a bit more functionality based on that IE7 rendering. (Note: To any not familiar with HTML emails, it’s tricky business to make them display well on different email programs.)

… IE7 is released and downloaded by many people across the world.

… Whoops. Somehow we missed this article on the Microsoft site in all the excitement.

… So now we’ve found out that, for some unexplained reason, Microsoft has decided to not use IE7 for rendering in the new Outlook 2007.

… "But wait", you ask hesitantly. "What -will- be used for rendering?"

… Microsoft Word.

… No, I’m not joking.

Truly, I have no idea why this took place. Both the products belong to Microsoft, yet the chose to toss out the recently improved and expected solution to replace it with one of the most junk filled word processors ever created.

To cut to the heart of it, let me explain what is making people so upset. Choosing to use MS Word for rendering instead of IE will result in the loss of several options. This list has been repeated in several places online since developers have noticed this, so I’m just going to quote the list used in the SitePoint article rather than reword it minimally to say the same thing:

* no support for background images (HTML or CSS)
* no support for forms
* no support for Flash, or other plugins
* no support for CSS floats
* no support for replacing bullets with images in unordered lists
* no support for CSS positioning
* no support for animated GIFs

I am, honestly, quite annoyed. I publish an email newsletter each week that goes out to several thousands of readers. It is an HTML newsletter with significant CSS use. Now I’m thinking… okay, so, not only do I have to rework the newsletter, but if people upgrade to Outlook 2007, and try to read their old emails, I imagine now they aren’t going to display properly.

I am not the only one who’s annoyed. Annoyed doesn’t fully encompass it though. I’m also simply dumbfounded.

Now, before any plain-text only advocates jump on the bandwagon and start talking about how they don’t care, let me give you a quote from an anonymous poster on the SitePoint post:

HTML vs. plain-text in email:

1) This typical debate comprises progressive people debating the stagnant. “HTML has no place in email.” I’ve heard my grandfather make similar statements like “computers have no place in a library.”

2) Just because email started in plain-text doesn’t mean it has no room for evolution.

3) Anyone with a subscription list that offers a choice between HTML and plain-text can attest to the fact that HTML is preferred infinitely over plain-text. So anyone who says it has no place in email is an elitist who is ignorant of the preferences of the majority.

This article isn’t about HTML vs. plain-text.

This article is about the fact that Microsoft is catering to their own monopolistic goals and placing devastating hurdles in place for the web-design community. They’re taking 200 steps backward while everyone else takes a few steps forward. And they bank on knowing that they have lassos, enabling them to keep us all at bay.

Can anyone lay out a good reason why Microsoft would have made this decision? If your answer is that “they want people to use plain-text formats because HTML emails are stupid,” you’re in the wrong forum.

Now, there is supposedly a way around this. A comment by Oscar Gensmann (on the SitePoint article) had this to say about the options in Outlook 2007:

Outlook 2007 does have a way to render an e-mail using the built in browser (security-zone).

The method is:

1) Open the E-mail in it’s own window (double click)

2) Click the toolbar button called “Other actions” in the ribbon

3) Choose “View in browser”

This doesn’t help the problem with the preview pane and the fact that the user has to do a considerable amount of work to view the e-mail in it’s correct form. It does however change the situation where it’s totally impossible to view an advanced HTML e-mail in using Outlook 2007 as the primary e-mail client, to a situation where people choosing to use 2007 can be taught how to view advanced HTML e-mails with a simple couple of clicks method.

While that may be possible, how many of your average users are going to know to do that? As most developers/designers know, the average user cannot be expected to know how to alter settings. It should be assumed that many of them will leave their software in it’s default form. Besides, while it is a partial fix, it doesn’t solve the issue of the email preview (which tons of people use).

Obviously the user doesn’t care what is rendering their emails. They won’t know if it’s IE7, MS Word, or ‘that Google thing’. All they need is for it to work the way they expect it. Which is why this is a developer problem.

If developers didn’t scramble to find work-arounds every time Microsoft threw another curveball, it would become as obvious to customers (as it is to many developers) exactly how little they care about inconveniencing people.

~Nicole

I think that far too many people see this as a huge problem, when it’s not. I also think this is the whole reason that so many people got started developing this plethora of CSS hacks we are left with today.

So… let me say this loud and clear:

Your site -does not- have to look identical in all browsers. Your site -does- need to be functional (and hopefully attractive) in all browsers.

If your footer is 2 pixels taller in another browser.. so what? Does the text still look fine? Alignment is still okay? Did the design completely lose it’s quality because of 2 pixels? If it’s built well, I rather doubt it made a huge difference. Who cares if your font of choice isn’t rendering on the operating system of your viewer… does an equally nice one render? If not, specify better alternative font families, don’t turn to dynamic font graphic generation to solve something like that unless it is -really- vital to the design. And I mean -really- vital. Something would have to be darn important to waste precious load time rendering and loading extra graphics when you know you have only a few seconds to capture a viewer in the first place.

So many people stress about because IE cannot handle so many of the nifty little CSS things like the :after and :before. So what? Use them on non-vital things. The important thing about making your site accessible to all people isn’t that it be exactly the same to everyone visually. It’s that you need to ensure that your design is close enough to the same, but even more importantly… that all the -content- is available to everyone regardless of the method they use to access your site.

Now, don’t get me wrong. Some things that happen in different browsers can have ugly results. No designer wants their pages to be ugly. But they don’t have to be identical. I have watched people tweak a design for hours and hours just to get it all perfectly the same in several different browsers. I’ve done it myself many times, until I realized that the little things (small, insignificant non-content things) … really don’t matter in the long run.

Overall, I think that a non-hacked CSS is better than a hacked one. If you can avoid using hacks just to solve minimal issues, then do it. I’m not talking about major things like a div that is floating around aimlessly and overlapping your content. I’m talking about minor differences in rendering. Hopefully, people will start seeing these differences as less of a stumbling block, and more of an opportunity to use varying technology while still providing a good user experience.

~Nicole

What browser do you use to check your web pages when you’re developing your sites (or when your webmaster asks for your approval on a new layout)? If it’s Internet Explorer, you’re among the majority – around 60% of users are still using Microsoft’s browser.

But a growing number of users are moving over to other, more flexible browsers with less security problems, such as Mozilla’s Firefox (which offers a number of advantages, not least of which is tabbed browsing, making it easier to keep a number of sites running and switch from one to another quickly). Firefox’s market share has been increasing steadily every month for over a year.

When you look at your web pages in IE, you will be seeing what most other browsers see. But as usage of other, arguably better browsers increases, you need to at least double-check what these ‘renegade’ surfers are seeing as well.

One problem I spotted when I made the switch was that the ‘alt’ parameter on image tags doesn’t work. I found this annoying, but I didn’t realise that the problem is that the authors of Internet Explorer made an error in their implementation of the HTML specification (HTML was not invented by Microsoft, but by a completely independent entity).

The ‘alt’ parameter is not meant to be used in the way almost everybody uses it. And because of this it will not work this way in many other browsers.

This is a serious problem for webmasters like myself who are based in the UK, because we have a legal obligation to provide tool tips for images, to help blind users to use the internet.

To illustrate what I’m talking about, you will need to have both IE and Firefox available (If you’re developing pages to put online, this is a good idea in any case). If you don’t have Firefox already on your system, you can download it completely free here. Why not try it (no, I am not making anything out of this in any way). You will never need to pay a licence fee and you don’t need to put up with advertising banners either.

OK, so I’m assuming you now have both browsers installed on your computer. Load up this page in both of them and take a look at the picture on the left in each:

Hover over it with the mouse.

In IE, you should see a message (or tool tip), but in Firefox you will not see anything new.

Tool tips without Alt

Now, hover over the righthand picture. This time you should see the tool tip in both browsers.

So… How did I do that?

It’s really pretty easy, although depending on how many tags you need to change, it could take a while. (I have hundreds, which I am in the process of swapping over just now, as soon as I have finished this article).

All you need to do is to double up your alt tags, substituting ‘title’ for ‘alt’ the second time, in all your <img> tags like this: where you have alt=”fred”, you now need alt=”fred” title=”fred”.

ALL?! I hear you say. (I just hope you have a good quality HTML editor that will do batch find and replace.) Depending on how many pages you have, yes, it could be a longish job. But it’s something you can do over a period of time, as you work on a particular site. At the moment, less than half of the browsers in use are affected by this problem. But the numbers are growing every day.

PS. While we’re on the subject of ‘title’ as a parameter in <img> tags, there’s another little known use for this: you can also add a tool tip to your links in the same way!

I don’t know whether you noticed earlier on, when I recommended downloading Firefox, but there was a tool tip on that link (of course, this only works in html, so if you’re reading this in a plain email, you won’t have seen this). I’ve also put the same link at the bottom of the demo-pictures page. Take a look now at the tool tip that comes up when you hover over the link.

What I did there was to add the title parameter to the link (in the line below the angle brackets are replaced with curly brackets):

{a href=”http://www.download.com/Mozilla-Firefox/3000-2356_4-10208565.html?tag=pao” title=”Download Mozilla Firefox from Download.com”}here

Simple, huh? So, if you’d like to, you can add extra information to your links – or perhaps an extra ‘puff’ to encourage clicking… the possibilities are endless.

Well, I’ll sign off now, with the hope that I haven’t involved you in too much work. ;D

Catch yer later,
Frann

Written by: Frann Leach
About the Author: Frann Leach is webmaster of InformationZone.biz: Internet Marketing resources and lives in Edinburgh, Scotland.

In fact, I would take that a step further and say that if you have to fill your code with a million hacks for it to work well in IE, Opera, Safari, and FF … then you are not coding it well to begin with. There are a few hacks that have true use and purpose, but as so many people have seen with the advent of IE7, there is always the concern that many hacks will later be rendered useless by browser versioning and require a replacement (free of charge from the web developer, of course).

Is it truly worth that to developers to hack their sites? To watch their websites stumble and break upon the creation of a new browser version, only to have to go back later and make changes for all their old client websites at no cost? Or is it just easier to code it right the first time and avoid doing things that would even need a hack? There is always more than one way to do something.

I’m certainly an advocate of standard coding methodologies, but it defeats the purpose of using standard code if you have to hack your own code constantly. I can absolutely say without question that I have made websites that are perfectly functional in various browsers without using hacks. I have made sites fully backward compatible that only involved hacks for browsers no longer being changed – and that is what I would suggest to anyone else.

Mantra: Only use hacks for things what will never change.

Well, what will never change? Netscape 4, and IE 5 for Mac’s, and IE 5.5 for instance. Microsoft has completely dropped support and development for them, so you are safe using hacks for those browsers – they will never change. According to Microsoft they will still maintain updates occasionally for IE 5 on Windows because it was packaged with Windows 2000.

Things like the common @import hack to hide things from Netscape 4 are fine, but there really is no reason to (and plenty of reasons not to) use hacks for browsers that are still updated. On the other hand, using conditional comments is not something I’d consider a hack because it is an accepted feature. In fact, if you are going to use hacks on a website for IE, your best bet is to use conditional comments (ex: <!–[if IE 6]>).

Overall, the most important thing to keep in mind is that you do not want your website hacks to break just because a new browser comes out. Therefore, keep your hacks only in the realm of browsers that are no longer supported and developed. It will save you a lot of stress in the long run.

~Nicole

Essentially, I’m creating an online code parser that will skim out and replace old tags with the appropriate standards compliant ones. I’m starting slow, primarily because my knowledge of advanced string manipulation in PHP is rather minimal. Eventually, I’d like to be able to really expand this project into a lot more, but those are ideas for another discussion.

What I have done so far is this:

• Replaces MS Word Smartquotes with normal entities.
• <b> = <strong>
• <i> = <em>
• <u> = <span style=”text-decoration:underline”>
• <br> = <br />
• <hr> = <hr />
• <dir> and <menu> = <ul>
• <s> and <strike> = <del>
• <xmp> = <pre>

I have quite a few things on my list of what I would like to do, and it will get done as soon as I figure out how to use PHP to manipulate the data entered and create what I’m looking for. For now, this is a rather quick and dirty little online form that will solve a lot of the most basic validating errors for old web pages.

I’m keeping the project here:
http://www.websitestyle.com/code_cleaner/ if you want to try it out.

~Nicole

So many of the course outlines talk about how to ‘properly’ organize your site using tables. Test outlines that include things like the <font> tag and how to properly embed sound and video into a website, or even worse… the web animation courses touting how to make a fully flash website. I cringe every time I think about how many people take these courses each semester, not knowing that it is actually going to put them at a job disadvantage. For those students who plan on being able to come out and get a job, for example, working on a government site – they’ll have a rude awakening when they realize that there are standards compliance rules they need to know how to follow and that they’ve not been prepared for it… and are not qualified for the job, no matter what their degree says.

Of course, who knows. One of the seminars I’m doing on accessibilty laws involved organizing invites to lots of government offices. I remember one day, going through their sites and checking their main pages. Of the 40+ I checked that day – only 2 were able to meet the generic 508 requirement. We have a long way to go.

For those few who know the general subject matter of the book I’m working on, they know it is to address this sort of problem. Having been very old-school myself, I know exactly how hard it is to un-learn what you think you know. Harder still, is finding some of that information. If you are friends with any techies, you’ll find that it’s often the case that they won’t even consider picking up a ‘beginners book’ (visualize their disdainful sneer) when they know it already. So many of them consider it ‘below them’ to go back to basics. In some ways, I have to agree that it is.

It’s not at all the same to teach a web developer standards, versus teaching a beginner. It’s ten times harder to teach someone who is experienced because they have to be willing to un-learn bad habits, and if you’ve never taught experienced developers, you’ll find that they are the ones most prone to argue and question nearly every thing you say. It’s never a bad thing to question – but many of those questions are rooted in a feeling of being attacked and getting defensive. You are telling them that they are (and have been) doing things wrong. So, many people don’t learn, don’t try to learn, and worse – too many web developers don’t even know about CSS and XHTML.

When talking about web developer teachers, it’s exactly the same, but even moreso. These are people who teach the subject, and therefore, often feel they are experts on their subject. That is what they are used to. They are often even -more- resistant to change or discovering that they may have been teaching it wrong. It’s a hard pill to swallow. The problem is that it becomes a vicious cycle, wherein we have new students coming out with the ill-formed idea that they make good websites.

All that does is give the web standards community more people that they have to educate otherwise. I try very hard to target people who are old-school web developers and teach them how to code to standards. I write, predominantly, for the people who develop sites already – but that’s not enough. In the end, it’s about whether or not a person can move past the fear of finding out they may have been wrong, and choose to learn more. It’s sad, but I’ve seen far too many educators choose to remain uneducated instead.

~Nicole