Once every now and then you come across code that is so ghastly, so terrible, that it almost makes you go blind! While fighting the pain, you (think) you can be almost sure of one thing: this must have been done on purpose!
In November last year, Aleksandar Vacić wrote his post Insert HTML page into another HTML page (found through No more iframes?). Basically, what it is about is finding a way to use an object element instead of an iframe to get the correct behavior in Internet Explorer.
Right about now, I guess your questions are why, how and is it necessary?
So, 2006 is almost over and it’s time to look ahead at 2007. Will it be an exciting year? No doubt, we have to wait to see just how riveting it can get! I thought I’d go through some notable things that happened in 2006, not just web-related, and scribble down some words about them…
I think that in (almost) every project I work in, when a web page contains one or more form elements, the most common question is: should we set initial focus to the first element in the form when the page has loaded? Heated debates follow, where people argue very convincingly for their view on it.
However, to me it isn’t an easy black or white-question.
This might sound condemning, but I’m thinking of establishing a weekly award: Web Site Most Likely To Have Been Built By An Intern. It is about large companies targeting a lot of users who, in this day and age, still don’t have any clue about web standards, accessibility or semantics. If, for instance, a web site only works in one web browser (guess which one…) on one platform, something is fundamentally wrong!
Without further ado, let me probably announce this week’s winner: MSN Music.
PS. A little tip: first try it in Internet Explorer on a PC, and then in any other web browser on any platform. DS.
Just before I started blogging I got to know Tommy Olsson, through his now resting blog Autistic Cuckoo. I was impressed with his technical expertise and inspired by his respectful comments and discussions with his readers, and it was something I set up as a goal and role model for my relations with the readers of my web site.
Unfortunately, Tommy doesn’t write anymore on his blog, but he has now made an interesting contribution to SitePoint about HTML.
When I wrote Looking for a good interface developer? Here’s what to ask to make sure you’ve got the right person, I wasn’t sure if I should reveal the answers to you or just let you do the research yourselves. However, I came to the conclusion that this web site is really about sharing knowledge, and also that some of you might have some good extra input on my answers.
So, here are some answers and links to more information about the questions:
Are you perhaps looking for a talented interface developer? You’ve heard that web standards and perhaps accessibility is good to have experience with, but you don’t know how to determine the applicants’ experience.
Don’t worry anymore, I’ve put together a check list of what to ask to make sure they’re suitable and in the loop with proper and modern web interface development.
When developing a web site, amongst the initial questions is what level of accessibility one wants for it and what eventual extra measures are needed to achieve that. Sure, if you’re an experienced interface developer, you naturally write semantic HTML, use alt texts and try to avoid making the web site in question JavaScript dependant, and so on.
But, let me tell you something: you can be the best damned interface developer in the world and then still, in the end, you stand there with an inaccessible web site. What happened?
First, let me sincerely tell you that I’ve thoroughly read every motivation, and many of them were outstanding! You are really smart and funny people, and you all deserve one iPod Shuffle each (no, it’s not going to happen :-)! Thank you for all your wonderful contributions!
In the end, I went for something simple and a bit philosophical, and would proudly like to announce Barry Allison and his motivation the winner of this contest. Congratulations Barry!
Ok, here’s the deal. For the next couple of days I will be very busy, so I don’t find it likely that I will be able to find the time to write. But don’t worry, I think I’ve found a way to make it up to you: a contest!
Apparently Opera’s claim to support document.all in conjunction with not mimicking it exactly like IE led to some problems in Opera 9 when I use my getElementsByAttribute function. Thanks to Ash Searle who tipped me about this and also explained what the problem was. The code in the JavaScript file to download has been updated.
Also, Harmen asked an interesting question about nested elements with the title attribute. It didn’t work initially, but now I’ve updated the GLT JavaScript file with support for that as well.
I did some thinking how to address the faulty technical implementation in IE to display values in the alt attribute as a tooltip, and if I should suppress it on images that have a title attribute as well. I decided to implement a setting for it and then it’s up to you to choose. The GLT JavaScript file now contains one more setting: suppressAltTooltipsInIE : true.
I’ve done a very minor change to the event handling to cover up for a bug in IE’s garbage collector (something I hear will be addressed automatically in IE 7). In 99,9% of the cases you won’t notice any difference, but if you use it in a very advanced web site/web application it might make things better and less resource intensive.
Just as Chris commented, the script didn’t consider if the custom tooltip would disappear if it was positioned too far to the right. It is now updated with a fix for this.
A side-effect happened in Firefox when using GLT for any link; the status text wasn’t shown in the web browser status field. This issue has now been addressed.
Just as Jordan Ambra pointed out to me, there were cases when you could mouse out from the element just when the GLT element was shown, and making it stick and not fade out. This was just because of a tiny typo by me in the code, but it has now been fixed.
Bob pointed out a typo of me in the code, where the result was that you couldn’t turn off the fading in through the fadeInTitle property. The code has been updated and can be downloaded in the GLT web page.
Added an extra check to prevent any eventual error that occurred when hovering a GLT element in the middle of the loading of the page.
As of lately it seems like I’m giving you a new JavaScript library every second day. But don’t worry, I will be fairly busy in the upcoming months so this one is probably the last one for a while. 🙂
Anyway, tooltips in a web page, maybe more commonly known as what will be displayed when using the title attribute on an element, have some shortcomings that I wanted to address.
I could just stack argument after argument why using frames when designing a web page is a bad idea, but frankly, I’m too lazy to do it once again. Let’s turn this around:
Why would anyone see the need to use frames nowadays?
Lately, and especially evident in the beginning of the summer after the @media conference, people proclaimed that the war of web standards is won and that we should move on to focus on other things. Let me please say that the war is so far from over.
Have you ever had the need/wish for WordPress to deliver HTML instead of XHTML in your blog? And if yes, then having no idea how to control the default XHTML tags generated in comments and its likes? Fret no more!
After doing some extensive testing, due to some error reports that the overlay layer didn’t cover all parts of the web page if it had a scroll, I’ve now updated the script to take that into consideration as well. A positive effect of this is that, during a slideshow, it will automatically adapt the overlay size if the user resizes the web browser window or scrolls within it.
Also, one of the biggest upsides to this is that I’ve eliminated the need to add CSS specifically for Internet Explorer to handle overflow scenarios. The CSS code below has been updated accordingly.
So, I sincerely ask of you to download the example package (ZIP file link) to get this important fix, or if you already have your own custom CSS, to re-download the JaS JavaScript file and simply replace your current one.
Looking at nice features like Lightbox JS and what my friends at Particletree did with Lightbox Gone Wild!, I found it to be a given to add this functionality to JaS – JavaScript Slides. Now the image view, as well as the slideshow feature, supports it in different combinations.
Remember something called Geek Meet? People with a sincere interest in web development, always up for learning more and hanging out with like-minded? Well, fret no more! It’s time again! 🙂
<div class="left-col">Content here...</div>
<div class="navigation">Content here...</div>
(Note: I’ve used my fair share of left-cols, so this is no way meant to be elitistic.)
As most of you probably know, the target attribute isn’t allowed on links in strict HTML or strict XHTML. The thinking behind this, as I’ve understood the reasons behind this decision, and as I also see it, is that there are too many web browsers out there, be it in computers, PDAs or cell phones, and there are a number of factors that applies then. The most important ones seem to be:
While all this is good and respectful and sounds great in theory, it’s not that easy in the real world. Let me take a case in question: in one of the projects I work in, they had a demand that a link should be opened in a new window. I came up with the usual counter-arguments why we shouldn’t do that, but to no avail. However, the thing is, I partly agree with the customer and Project Manager in this specific situation; why a new window was actually somewhat motivational to use:
In the end, I went with using the target attribute. Sure, I could have used an unobtrusive JavaScript to add an onclick event and used window.open, and at the same time get perfectly valid code, but then it wouldn’t be as accessible and also dependant on scripts to function properly,
So, I feel a little perplexed about this: is target really a justifiable approach in some cases (though it has been terribly misused), or is my example just the exception that justifies the rule? Should we take some responsibility in educating end users, or just deliver what they ask for?
With the humble title of this post, I guess I really need to add that these ways mentioned below are the ones I’ve experienced to be very reliable to get a good search engine ranking. Naturally it varies a lot, but I get somewhere between 28 – 45% of my visitors from pure Google searches, out of just having a high ranking (and sometimes for terms that amaze me :-)). These are my advices:
Make sure you have URLs with a good descriptive value, as opposed to one being made up of just a lot of parameters. There are different tools and settings to achieve this in most, if not all, web development environments. For instance, these two links both lead to the same web page:
This is a good URL:
http://www.robertnyman.com/2005/11/07/the-ultimate-getelementsbyclassname/
and this is a bad one:
These are the only tips I can give you; basically, it’s just about good web development practises and maintaining good relations with other web site owners.
I’m sure there are good SEO companies out there, but the ones I’ve come across have all been unprofessional and/or been using very suspicious methods. And as soon Google update their algorithms, there’s a big chaos when some SEO’s dubious work fail, since some of their tricks have been found out and taken care of. Then, naturally, it backfires so their customers get a very bad search engine ranking.
Just do as I suggest above; code properly and you will be safe. Look around to see how good search engine ranking most web developing blogs get, just because they know how to implement a web site in a correct manner.
Sure, but only since you asked for it. Recently the web site http://www.larmdirekt.se/ 
was brought to my attention. If you navigate to their web site and disable CSS in your web browser (Ctrl/Command + Shift + s is one way to do it if you use the Web Developer extension in Firefox), alternatively view the source code of the page.
In the footer, you will then find a link with the text “y”, which leads to the page http://www.larmdirekt.se/laarm/ . Make sure to turn off JavaScript in your web browser and navigate to that page and you will not believe your eyes: a little link farm. If you surf around those links you will, amongst others, find the names of some fairly large Swedish companies, and the best thing of it all: the name of the SEO company in the title bar.
So, go check out the code of your own web site right now, or ask your SEO what methods they use.
Apparently Opera’s claim to support document.all in conjunction with not mimicking it exactly like IE led to some problems in Opera 9. Thanks to Ash Searle who tipped me about this and also explained what the problem was. The code below and the JavaScript file to download are updated.
Since we all have to face a new hard tough week now, I thought I’d brighten your day by giving you some code that might be useful.
Ever run into a situation where you want to get an array of all elements with a specific attribute? Or even want elements with a certain value for that chosen attribute, as well? That’s not a problem anymore; let me present getElementsByAttribute.
/*
Copyright Robert Nyman, http://www.robertnyman.com
Free to use if this text is included
*/
function getElementsByAttribute(oElm, strTagName, strAttributeName, strAttributeValue){
var arrElements = (strTagName == "*" && oElm.all)? oElm.all : oElm.getElementsByTagName(strTagName);
var arrReturnElements = new Array();
var oAttributeValue = (typeof strAttributeValue != "undefined")? new RegExp("(^|\\s)" + strAttributeValue + "(\\s|$)") : null;
var oCurrent;
var oAttribute;
for(var i=0; i<arrElements.length; i++){
oCurrent = arrElements[i];
oAttribute = oCurrent.getAttribute && oCurrent.getAttribute(strAttributeName);
if(typeof oAttribute == "string" && oAttribute.length > 0){
if(typeof strAttributeValue == "undefined" || (oAttributeValue && oAttributeValue.test(oAttribute))){
arrReturnElements.push(oCurrent);
}
}
}
return arrReturnElements;
}
*) if you want to look in all elements.
getElementsByAttribute(document.body, "*", "id");
getElementsByAttribute(document.getElementById("the-form"), "input", "type", "text");
The code has been tested and verified to work in:
To use it, just copy and paste above code or download the getElementsByAttribute.js file.
This post is mostly applicable for Swedish readers, but I believe most of you in other countries stumble across this fairly frequently too.
Here in Sweden we have a publication called Internetworld , whose target group is mostly private users and small businesses. Their articles mostly deal with business gain, short press releases what has happened in the field of technology with things like new services on the web, Firefox increasing its user base etc. Out of general interest I read it, amongst a lot of other publications, just to stay on top of what’s going on and what people are talking about.
When I had worked a while in the internet business, I soon realized that they aren’t always exactly spot on with their articles, especially when it comes to technology choices, coding tips and its likes. However, what they’ve written has mostly been harmless and can at least be of some help to amateurs starting to code.
However, I just browsed through the latest issue with an article entitled “Web standards part 1 – Adapt the web site for different web browsers”. Just reading the headline, I realized it probably wasn’t going to be good. After going through it I came to the conclusion that it isn’t as bad as I first thought, they do, at least partly, try to convey the message that there actually is something out there called web standards and it is there for the device “Code once, run everywhere” kind of equivalent for web code.
Unfortunately, though, they have some parts and quotes that I sincerely think will hurt new web developers’ attitude towards web developing and that’s the reason for me writing this. They briefly touch on the fact that there are different interpretations by web browser vendors how web standards should be implemented. While that is to some degree true, it’s seldom knowledge that beginners need to know, it’s usually only interesting on a pretty high level, as long as you start out the correct way when you build your web sites. And it’s rarely a problem when you write HTML/XHTML, it’s usually when you code CSS that this will be more evident (which will, as I understand, be touched on in an upcoming part in this series).
The conclusion of the article is to follow web standards if you have no idea about your target group; otherwise, offer them an enhanced and web browser-specific version that only works under certain circumstances. Another conclusions is that web standards is an “advanced technique” and question if it’s worth to require that out the users to have such modern web browsers to be able to use your web site; talk about not understanding web standards.
I don’t know where to begin with to describe how damage such an attitude will do. Sure, naturally most if not every web site out there will work better in a later version in, say, Internet Explorer or Firefox than in Netscape 4 but that doesn’t give you the right to shut out users with an older web browser. It’s all about progressive enhancement.
Another thing is that even if you do know a lot about your visitors and the statistics, that situation can almost change overnight. Build an Internet Explorer-version on proprietary code just to realize a month later that many of them have started using any other web browser out there. Also, does anyone really know how many web browsers there are out there? Hundreds and hundreds, let me tell you that. Different web browsers on different operating systems, PDAs, cell phones, digital TV boxes et cetera. The only way to make sure that your code will work is to follow web standards. No, web standards will not solve your every problem, but that’s the closest you can get and definitely your best bet if you’re serious in what you do.
Let me quote some pieces in the article:
There are a number of reasons where you gain from following web standards, but here are also occasions when you don’t, which we will explain in some of the following tips.
After that, I never find any tip where the difference is proved. Also, that’s just the mindset that’s so dangerous and there has to be a realization that while web standards maybe won’t save the day automatically, they will never hold you back either.
In modern HTML, that is often referred to as XHTML…
What kind of crap is that? There’s HTML and there’s XHTML; they are two different things and none of them are really more modern that the other. Something that really bothers me is that that isn’t even mentioned and doctypes are totally left out. No wonder you think there are differences out there if you don’t know how to choose a doctype and what effects that choice will have on the rest of the code.
Usually the unit px (pixels) is the one unit that gets interpreted most alike amongst the web browsers
While I kind of get what he’s going for, like percentage rounding errors in some web browsers and its likes, talk about killing the accessibility factor. You can’t make such a statement that will give such repercussions without explaining it in a more detailed way. And what about ems? Ever heard of those?
Conclusively, maybe I’m way too hard on this guy. After all, I do sincerely believe that he meant well with the article and tried to help people, but my fear is just that he did as much harming as helping; hence this post.
Most web sites I look at seem to have no idea how to create structured and valid layout when it comes to form elements. One of the things I get most annoyed at, both as a coder and a normal user, is when they’ve missed out on the wonderful and easy label element.
The label element is used together with form elements and it makes it accessible to screen readers, while also making the text clickable to set focus to the element in question. Point in question:
You have a radio button, but since they’re pretty small, it might be difficult to click it. You then add a label around the text next to it and make it reference the desired radio button: VoÃÂla! You can now click the text as well to make a selection.
A simple example:
<input type="radio" id="gender-male" name="gender">
<label for="gender-male">Male</label>
However, the example above demands that you know the id of the radio button. If you have dynamically generated forms meaning a moving number of elements, you need to do some trickery to generate dynamic ids and then have the same value for their respective label element.
There is one way around this, but unfortunately it doesn’t work in Internet Explorer. I do showcase it below, though, just so you’re aware of it.
<label>
<input type="radio" name="gender"> Male
</label>
You thought this was all funky and want to know more about improving your form coding, but you have no idea where to go? Fear not, take a look at
10 Tips To A Better Form
After the feedback I got on my initial AJAX-S release, I’ve compiled it and added new functionality and fixes. In release 2 you will find these beauties:
Sure, the print design isn’t exactly ground-breaking, but that’s where you come in! Download AJAX-S and test it out with your presentation material and needs, and style it up with your own design. Let me know how it goes!
Go view the updated demo now, ok? 🙂
Last week I bought the November issue of Treehouse magazine, coming from the people of Particletree, and I have to say it was the best spent three bucks in a long time! I instantly had to read it from cover to cover.
It starts off with two very interesting things: An addEvent article by Ryan Campbell explaining the need for such a function and the difference between the different solutions out there, and then goes straight into an interview with Peter-Paul Koch. Peter-Paul has had a tremendous impact on the web developing community, and especially the JavaScript part. However, I’ve never gotten the chance to meet him in person, and I’ve only gotten one e-mail reply from him (this was a number of years ago). So, Peter-Paul, if you read this, let’s make sure we meet. Who knows, I might even have something good to say too! 🙂
The magazine goes on with some other interesting interviews and articles, where I really liked the Dead Poets Society feeling I got from the interview with, amongst many other things, teacher Lisa McMillan. Alex McClung also had an interesting article about writing accessible HTML code in his piece Understanding Section 508 (although he manages to call the alt attribute for alt tag once… :-)).
Basically, a very recommended read altogether. I think the magazine will appeal to people of all kinds of experience and interest working with the web. Go read now!
The demo and the zip file are updated with a small fix to avoid generating invalid nodes while still offering the possibility to use custom HTML in any page, and the ability to display escaped code for presentations.
Updated the drop down to support pressing the spacebar and enter keys when it has got focus, to navigate directly to that certain page.
By popular request, AJAX-S now supports XHTML code in the XML file as well. No escaping, no nothing, just write as you usually do! I think now that it is a real contender to Eric Meyer’s S5!
For some reason unknown to me, the XSLT files failed to work in some Mozilla web browsers on some computers when they had an .xslt extension. I’ve changed the zip file so it now points to XSLT files with an .xml extension. If you’ve downloaded a previous version that didn’t work, please try the new one. Big thanks to Karl and especially Henrik Box for doing some extensive testing for me (Henrik wants to meet the girls behind girlspoke as a thanks… :-))!
After listening to the feedback I got, I’ve now done some major updates to AJAX-S. It now supports incremental rendering, non-JavaScript users and also offers a printable version. Go check the updated demo.
Changed the JavaScript detect for support for the XSLTProcessor object so it asks users that lack that support if they want to go to the printable page instead.
Added check to scroll the current incremental step into view if it wasn’t visible.
Updated with a different look for active increment, past increment and coming increment, and a setting if one wants the first or last increment to be selected when backing from an upcoming page.
Updated with a different look for active increment, past increment and coming increment, and a setting if one wants the first or last increment to be selected when backing from an upcoming page.
Updated with a fix for two glitches in the keyboard navigation.
An add-on for AJAX-S has been developed, to automatically show/hide the footer of the slides.
I’ve been thinking about creating an AJAX-based slideshow for a while, and today it happened! Today I wrote my first line of code in this project (probably not the last one), but for the moment I feel very content with the results. The code is probably not perfect, but I’m going more for the concept here. The tweaking options are endless.
The idea came to me because I wanted a lightweight slideshow based on HTML, CSS and JavaScript, but I also wanted to separate the data of each page from the actual code that presents it. Therefore, I decided to move the data into an XML file and then use AJAX to retrieve it. The name AJAX-S is short for AJAX-Slides (or Asynchronous JavaScript and XML Slides, if you want to).
Naturally, one of my inspirations for creating a HTML-based slideshow are from Eric Meyer and his S5. However, I wanted to take it one notch further, to make it more flexible and also usable for people with no HTML knowledge whatsoever. Another motivating factor was to just transform the data for the current page, as opposed to creating all the HTML needed for all the pages when the page is initially loaded. A leaner end user experience, basically.
It only works in IE 6 and Mozilla-based web browsers as of now. This is because of the need to do on the fly transformations on the client, which means the necessary support for ActiveXObject or XSLTProcessor has to be there. I think Opera 9 will support XSLTProcessor and probably some upcoming version of Safari too, so more widespread support in the future is very likely.
A freaky thing, which I hope is only a very unimportant detail, is that when I run it here at my host provider, I have to use the xml instead of the xslt one. However, most likely a hosting issue only.
But enough of that now. Download AJAX-S or view the demo of AJAX-S. Please let me know what you think, and if there’s any major error in the code. Not a requirement at all, but if you use it and like it, I would appreciate getting credit for it. 🙂
In Spanish/En Español
På Svenska/In Swedish
It seems like the eternal question amongst web developers: HTML or XHTML? Wherever I look there seems to be posts in forums raising the question, web developers asking me or other people write blog posts about what they believe is the right way to go. I’m not writing this post to tell you what the ultimate choice is, but rather to inform you about the consequences of what you choose. So, let’s take it from the top:
Definitely strict. Transitional doctypes are exactly what the name implies: a doctype for a phase of transition, not meant to be used permanently. If you write HTML and choose Transitional, you will get the Quirks Mode rendering, which results in web browsers just trying to mimic old and incorrect behavior; this means that rendering will be very different from web browser to web browser. If you choose XHTML Transitional, you will get the strict (or rather, strictest) mode available in IE (Note: from version 6) but you will trigger the Almost Standards Mode in Mozilla-based web browsers.
However, if you use a strict doctype, you will get full standards correct rendering and the most consistent and forward compatible interpretation of your pages.
A XHTML document is a document that has to be well-formed according to the rules of XML. Every tag has be closed and correctly nested, and for tags like img, input, link etc, a quick close slash should be added at the end of the tag, like this: <input type="text" />. If you’re writing code that should be accessible for people with Netscape 4 and some other web browsers, then make sure to have a space before the slash (Note: not to make it look good in Netscape 4, but to make it work at all).
You’re supposed to be able to save a page written in XHTML and use it as XML right away.
It totally depends on your needs. Some people believe it to be very easy and consistent to code in its XML fashion, where everything has to be well-formed and every element has to be closed. Some people choose it to extend its functionality with namespaces, to use it in conjunction with MathML and so on. Other people might work with XHTML, not out of their own choice, but because the products they/their company use deliver XHTML.
application/xhtml+xml?Yes, it’s all about what MIME type goes with your code. For HTML, the media type is text/html. According to W3C, the organization behind many recommendations such as HTML, XHTML etc (albeit mostly known as web standards), state in their XHTML Media Types document:
‘application/xhtml+xml’ SHOULD be used for serving XHTML documents to XHTML user agents. Authors who wish to support both XHTML and HTML user agents MAY utilize content negotiation by serving HTML documents as ‘text/html’ and XHTML documents as ‘application/xhtml+xml’. Also note that it is not necessary for XHTML documents served as ‘application/xhtml+xml’ to follow the HTML Compatibility Guidelines.
What this translates to is that web browsers who can handle application/xhtml+xml should get it served that way. However, IE doesn’t support that media type, thus requiring you send the code as text/html to it, basically resulting in you having to deliver the pages with different media types to different web browsers, using something called content negotiation. By now, you probably think it all sounds like too much of a hassle, and choose to go with text/html all over. I mean, after all, the Appendix C. HTML Compatibility Guidelines presents the validity of serving XHTML as text/html.
However, then you read this:
XHTML documents served as ‘text/html’ will not be processed as XML [XML10], e.g. well-formedness errors may not be detected by user agents. Also be aware that HTML rules will be applied for DOM and style sheets…
Which means that web browsers will not render your pages as XHTML, but rather as HTML and fall back on error handling and trying to guess how it was meant to be. Then you’re most likely back at square one, because you probably don’t want it this way.
Also, something else that is utterly important to know is that certain scripting will not work when sent as application/xhtml+xml. For instance, if you use document.write or have ads on your page through an ad content provider using it (such as Google AdSense), it will stop working. If you implement an AJAX application using the innerHTML property on an element, that won’t work either.
My personal opinion is that the most important thing is that you choose a strict doctype, be it HTML or XHTML. If you want to use XHTML and serve it as text/html, make sure that you don’t intentionally have code that would break when served as application/xhtml+xml. Do not use scripting like the one above mentioned in an XHTML page, and go the extra mile to make sure it is indeed well-formed. Be also very aware that a page that isn’t well-formed sent as application/xhtml+xml will not render at all, but will instead only display an error message to the end user.
Anne used me as a bat for HTML, but I’d rather be seen as a spokesman for making a thought-through decision, no matter which one it is. I sometimes work with HTML in may daily job and sometimes XHTML, depending on a lot of factors.
So, choose what you think suits your needs best, and choose wisely. And make sure it’s a deliberate decision.
I’m sitting here; just sipping some nice red wine and eating chocolate, celebrating that the last seven days are over now. I’ve been working double shifts for about a week, doing my hours as a consultant daytime, and working on redesigning this web site nighttime.
So finally: redesign! And I wanted to get done with it as fast as possible, I couldn’t stand making a live redesign spread over a longer amount of time, like one of my friends does. There have been a number of reasons I wanted to create and implement a new design for this web site, and the factors and choices have mainly been these:
When I launched robertnyman.com, I installed WordPress and looked around for themes written for it. My previous design was a theme designed by Shawn Grimes, that I tweaked a bit to personalize it. But with me ranting about how web sites should be developed, I ought to live up to what I preach at my own web site. You know, the shoemaker’s children and all…
Also, someone (in a jokingly way) teased me saying that I couldn’t create my own design. 🙂
I wanted something that was really easy on the eyes, something that looked good and also being original to get some attention for that as well. All image material used here is from pictures I’ve taken myself. And since it’s an Easter Island theme, naturally there has to be an Easter egg; if you find and hold down a certain key combination, you will get to see a freaky picture of me! 🙂
I want this web site to be an example of being accessible to everyone:
Since I work full-time with web development and also have it as a hobby, this web site should be a showcase of how I think a web site should be. Therefore, the layout is elastic and works in most web browser window sizes. I also use AJAX for the search functionality, thus not requiring a post back of the whole page to see the search results.
But naturally, everything should downgrade well too. The search has a fall back that works without JavaScript and all JavaScripts used are unobtrusive, meaning that all events are applied externally from a JavaScript meaning. The effect of this is that no elements have any inline event handlers whatsoever.
It’s possible to easily navigate through the web site just using the keyboard, leaving out the dependency on using a mouse.
Something that will interest certain people out there, and definitely Anne van Kesteren, is that this web site is using strict HTML, not XHTML. The reasons? First, I’m tired of everyone using XHTML without knowing the reasons why. They just do it because their tool/-s deliver it, they’ve heard it’s cool etc.
Second, XHTML should be served as application/xhtml+xml. In my previous design, that was the case first, but since WordPress wasn’t fool-proof and I still wanted it to be user-friendly to write comments on my posts, this ended up in me having to check the web site all the time just to make sure that nothing bad had gotten through. I then went to using text/html with XHTML for that design, according to Appendix C, but knowing that my code should be valid so I could switch to application/xhtml whenever I wanted to, I hadn’t used anything intentionally that should break.
However, now I use innerHTML in my AJAX script and Google’s ads use document write; two things that don’t work with application/xhtml+xml. So, my decision to use plain old HTML is definitely thought through and a very deliberate one. Maybe some day this web site will use XHTML again, but only the future can tell.
I’ve haven’t had access to an Apple computer during this whole design face. It has been coded using web standards code, well-tested CSS approaches and object detection in JavaScript. My testing in Firefox and Opera 8, two of the most standards-compliant web browsers out there, leads me to believe that it should work automatically in Safari too. Apple user? Please let me know!
So, get going now! Resize your web browser window, increase/decrease your text size setting, turn off using any CSS, try navigating using only your keyboard, turn off JavaScript and test it!
When that’s done, and your eyes have feasted on the new layout, please let me know what you think of it! 🙂
PS. Don’t miss the two new cool map functionalities; they can be found at the bottom of the left column. DS.
PS 2. A big thank you to Henrik Box for helping me evalute my design sketches. DS.
To start with, if this is not your first visit here, you know I’m all for web standards. But from time to time, I feel that things get exaggerated. There’s a validation frenzy and way too much work, time and focus put into the wrong details.
IT projects are almost always under a tight deadline and compromising is usually a way of web development life. So, my pet peeve is invalid attributes on elements. When I write code, of course I refrain from using them, hence making it valid. But in my case, I work in a lot .NET-based projects and Web Forms and such in it produces invalid code, especially when using a strict HTML or XHTML doctype. Examples can be attributes like language=JavaScript and the name attribute on the form tag. There are ways to take care of this, but they might affect performance, especially for a web site with a lot of visitors.
While these attributes render the page invalid, to me it doesn’t really matter. I regard it as much more important to focus on writing accessible and semantic code, and where the presentation is a 100% controlled from CSS. And, as Peter-Paul Koch writes in Why QuirksMode, there are a lot of cases where using custom attributes whould make the code a lot cleaner and understandable. Having an attribute named “mandatory” on a form element would make a lot more sense that adding a class for it. Especially if the class attribute then weren’t used for any presentational purpose whatsoever, but only for hooking it up with JavaScript.
So, my advice is: Make sure your code is well-formed, but after that, focus on the important parts instead of unsignificant things like an invalid attribute. Then, if you have time, take care of the attribute too.
Personally, I’ve always disliked uppercase tags in the code. Uppercase characters in digital format is often perceived as screaming, and if that’s true, boy, have I’ve been screamed at by a lot of code I’ve seen. It looks bulky and feels like working with skyscrapers when doing a cut-and-paste operation, one expects the computer to start screaming from the effort.
Estethics aside, there’s also a good technical reason for not using uppercase tags: it’s not allowed in any flavor of XHTML. To quote the XHTML 1.0 specification:
XHTML documents must use lower case for all HTML element and attribute names
As a follow-up to this, if your XHTML/HTML is indeed lowercase, make sure that your tag-specific rules in your CSS is lowercase too. Otherwise, you might not get the behavior you expect (you will not get it to work with lowercase XHTML tags and uppercase references in your CSS, if it’s sent with the MIME type application/xhtml+xml).
So, if you like and use uppercase tags, please lowercase your darlings. For me, and for the future.
What I want to touch with this post is how errors are handled when XHTML is served the way it should be. Let’s, for the sake of argument, say that we want to write and deliver XHTML (not wanting to turn this into a discussion whether we should write HTML or XHTML).
First, some general background information about how to send documents to the requesting web browser. It’s all about the media type type, described in XHTML Media Types:
text/html MIME type.strict, transitional and frameset, should be sent with the application/xhtml+xml MIME type, but may be sent as text/html when it conforms to Appendix C of the XHTML specification.application/xhtml+xml MIME type; Should not be sent with the text/html MIME type.So, what’s the difference? It’s that web pages sent as text/html is interpreted as HTML while those sent as application/xhtml+xml is received as a form of XML. However, this does not apply to IE, because it doesn’t even understand the application/xhtml+xml MIME type to begin with, but instead tries do download it as a file. So, no application/xhtml+xml for IE.
Aside from IE‘s lack of support for it, and for what you need to consider described by Mark Pilgrim in his The Road to XHTML 2.0: MIME Types article, it means that when a web page is sent as application/xhtml+xml while containing an well-formedness error, the page won’t render at all.
The only thing displayed will be an error message when such an error occurs. This is usually referred to as draconian error handling, and its history is told in The history of draconian error handling in XML.
My thoughts about this started partly by seeing many web developers writing XHTML 1.1 web pages and then send them as text/html, and they were only using it because it was the latest thing, not for any features that XHTML 1.1 offers (this also goes for some CMS companies that have invalid XHTML 1.1 sent as text/html as default in their page templates for customers to take after). Sigh…
It is also partly inspired by an e-mail that I got a couple of months ago, when Anne was kind enough to bring an error on my web site to my attention, with the hilarious subject line:
dude, someone fucked up your XHTML
What had happened was that Faruk Ates had a entered a comment to one of my posts where his XHTML had been messed up (probably because of some misinterpretation by my WordPress system), hence ending up breaking the well-formedness of my web site so it didn’t render at all.
Because of that, and when using it for major public web sites, I really wonder if that’s the optimal way to handle an error. Such a small thing as an unencoded ampersand (example: & instead of &) in a link’s href attribute will result in the page not being well-formed, thus not rendered. Given the low quality of the CMSs out there, terrible output from many WYSIWYG editors, the “risk” (read:chance) of the code being valid and well-formed is smaller than of the code being incorrect. Many, many web sites out there don’t deliver well-formed code.
Personally, I agree with what Ben de Groot writes in his Markup in the Real World post. I prefer the advantages of XHTML when it comes to its syntax and what will be correct within it. However, Tommy once said to me that if you can’t guarantee valid XHTML you shouldn’t use. Generally, I see his point and think he’s right, but to strike the note Ben does, I can guarantee my part of it but there will always be factors like third party content providers, such as ad providers, sub-par tools for the web site’s administrator and so on. And for the reasons Ben mention, I’d still go for XHTML.
So, conclusively, I have to ask: do you think XHTML sent as text/html is ok, when it follows the Appendix C of the XHTML specification? Do you agree with me that having a web site break and show nothing but an error if something’s not well-formed isn’t good business practice?
A common problem is that the Web Forms and Web Controls in ASP.NET generate invalid XHTML. Amongst these errors are invalid attributes and inline elements without a correct block element container, as well as good ol’ HTML comments in a script block, which prevents you from sending your XHTML with the application/xhtml+xml MIME type.
All these errors are automatically created when the page in question is being rendered in the web browser, meaning that even if you write flawless code you will still fail to get it valid.
To the rescue, some solutions to take care of this:
Another option can be to write your own fix and customize it after your specific needs. This should take something from a day and up, depending on where you set the bar.
Or maybe you’re one of the people that hope ASP.NET 2.0 will take care of all this? In that case, I recommend you reading Charl van Niekerk’s posts ASP.NET 2.0 – Part 1 and particularly ASP.NET 2.0 – Part 2.
ASP.NET 2.0 outputs lovely (*irony*) things like:
<form onsubmit="javascript:return WebForm _ OnSubmit();">and
document.all ?
document.all["Login1_UserNameRequired"] :
document.getElementById("Login1_UserNameRequired")(for the vast IE 4 support required?) and still HTML comments in scripts block.
And when it comes to semantics, structure and unobtrusive JavaScript, it’s a mess.
Don’t get me wrong, I think it’s great that it validates, but only validating doesn’t necessarily make it good code. Validation is just one of the components necessary for a good web page; there’s, for instance, also semantics, accessibility and unobtrusive JavaScript (or, as important, offering a way for it working without JavaScript as well; kind of connects back to accessibility).
My advice to you: some way or another, make the extra effort to make sure your XHTML from .NET is valid. It’s not that big of a deal, and it’s totally reusable in your next .NET-based project.
Do you have experience of above techniques to make it valid, or some other way to accomplish it? Please feel free to share!
Today is the launch of my lab web site, RobLab (yes, it’s a corny name), where I will have code, tips and tricks for anyone to use. For the moment, it only has a few things and I don’t know with what frequency I’ll be adding stuff, but that totally depends on the reception it gets. I hope the web site will act as a resource to you, and will be of use.
Now, take a look, why don’t you?
Tommy has been asked the famous Ten questions by the WSG. Although I don’t necessarily agree a 100% with all of what Tommy says (for instance, about the benefits of, or lack of, using XHTML), he’s full of knowledge and it is a very good read.
Regarding coding semantically correct and using a strict doctype, be it HTML or XHTML, we’re definitely on the same page.
But when it comes to using the ABBR or the ACRONYM element for abbreviations, I think the discussion about different layers of presentation is far more important.
Personally, I use the ACRONYM element because I want the IE users to able to see it as well.
All in all, I recommend reading the interview.
Just as a short follow-up to Why XHTML?, I thought I’d give you some read-worthy links to posts about it, and also bring up companies’ attitude towards it.
Lachy muses about the future and how it might be, and Tommy has written a very good piece in Doctype Declarations and Content-Type Headers, where he explains what really matters.
What I wonder is if companies really care about the level and quality of interface code they deliver, no matter if it’s HTML or XHTML.
As long as it doesn’t break miserably, it doesn’t matter. I used the Blogger service before swithcing to WordPress, and Blogger were always very quick to answer support mails, and during outages they seemed to work hard and efficiently to fix it.
With that said, I got a little saddened by something they wrote in a reply to my question about that the comment interface didn’t generate valid XHTML. The thing is, their templates (at least the ones I used) were coded using XHTML 1.0 Strict, so naturally I wanted my pages containing comments to be well-formed too.
Their reply:
However, unless it
is actually breaking functionality somewhere in Blogger or causing true
accessibility issues, it will likely be treated with a low-priority.
I think this symbolizes the general attitude of many companies: if it doesn’t break, it isn’t really that important if it is correct.
Let’s fall back on forgiving web browsers instead. But this might turn into a problem if browsers in the future will demand correct code to render it correctly.
What do you think? Are the companies right when it comes to this prioritizing, or is this exactly the attitude that holds the web back from evolving?
This is a well-discussed and very important topic. Personally, presently I write XHTML for my web interface code, but lately I’ve started to stagger in my standpoint. For normal general web page design, what’s the gain? If you don’t extend the code with namespaces, use MathML, have your own DTDs and so on, why would you want to use XHTML?
Many people answer that question with: “It makes me write leaner code, code that has to validate and be more semantic correct”. Martin wrote a post recently why he uses XHTML (unfortunately, it’s in Swedish).
But I don’t agree with the argument that it has to be XHTML to achieve that particular goal. I think it’s more of a developer standpoint than using XHTML. If you’re really dedicated to what you do, you use the correct tags for the correct purposes (H1 for headings etc), you write as lean and minimal code as possible and you close all optional tags like LI, P and so on.
Basically, you can live up to that with using the HTML 4 Strict Doctype, and separating content (HTML) from layout/look (CSS) and interactivity (JavaScript).
Another reason people use it is that they might think it makes them better programmers, that they code ‘the real deal’. It might also be as a selling point, for the project manager or his/her like, to tell the customer that: “Yes, we know what we do, we code XHTML”.
But, unfortunately, very few do it all the way. As mentioned in Anne‘s Quick quide to XHTML about Evan Goer’s test, 89% of the web sites tested didn’t validate and 99% used the incorrect MIME type!
Which leads to the MIME type issue. In a very talked-about piece, Ian Hickson writes that if you use XHTML it should be delivered as application/xhtml+xml (which, surprise, Internet Explorer doesn’t support) to the web browser, otherwise it will be perceived as ‘tag soup’ (however, not everyone agrees that it should be called ‘tag soup’). But what has happened is that people have gone to such length that they use something called content negotiation, which basically boils down to serving XHTML as application/xhtml+xml to those web browsers who support it, and HTML 4 as text/html to those who don’t.
When you deliver XHTML as application/xhtml+xml to a browser that supports it, it won’t even render the page if it’s incorrect, but instead throw an error. Generally, I think this is a good thing that forces the developer to write correct code. Alas, speaking from my point of view, working in projects where Content Management Systems don’t deliver correct XHTML, where the .NET Framework doesn’t deliver correct XHTML etc, serving it as application/xhtml+xml is impossible for me.
Yes, Content Management System manufacturers are getting more aware of this, ASP.NET 2.0 is supposed to deliver XHTML the way it should be delivered, but it’s still a long way ahead in the future.
So what are my (and many other developers’) options? To deliver XHTML that doesn’t validate (although the errors might be minor/make no difference to how it will be rendered) as text/html, or should we deliver plain old HTML?
One point is also that this will not affect the end users, as long as you write valid code in its context, be it XHTML or HTML.
An interesting sidenote to this is that MSN Search serves valid XHTML 1.0 Strict which validates, while Google serves a non-Doctype page which generates 242 errors…
Conclusively, to go back to my initial question: why use XHTML if I only use it for standard HTML? Why go through the hassle if I don’t use any of the XHTML-specific features?
Anne brought up an interesting thing from Mozilla’s Web Author FAQ about how to serve HTML (and the thing that Mozilla, nor any other browser, loads XHTML incrementally, as opposed to HTML), and he comes to the conclusion that one should switch to HTML.
Also, Tommy made the statement a couple of weeks ago that XHTML Is Dead.
And these are two very talented persons that just don’t believe in XHTML anymore, and that saddens me and makes me think:
Are they right? Should I go back to writing HTML?
PS. Let me know what you think! Is XHTML or HTML the way to go? Write a comment and I’ll send you an invitation to use Google’s Gmail service (2 GB inbox(!), POP3 access etc). DS.
Personally,
I’m of the opinion that frames should never be used (iframes is a
totally different question, they’re just part of a “normal” page).
There’s a number of reasons why you shouldn’t use frames:
A couple of examples for the developer:
A couple of examples for the user:
You can read more at, for example, Why you Shouldn’t use Frames and even Jakob Nielsen, who maybe isn’t always on the right track, realized already back in 1996 that frames aren’t good (Jakob that, by the way, offers an AMAZING gallery of pictures of himself…).
I read an interesting post by Henrik Torstensson in Internetworld 
, which was encouraging just to see that someone within e-commerce really thinks.
When
it comes to the technical aspect, there exists such good possibilities
to cache prats of the page for reloading purposes, so server load
shouldn’t be a factor to use frames.
Another
argument people use to have pro frames is that the menu frame is always
ther (for instance, to the left) and doesn’t “blink”, but this is more
of a browser thing than the technical solution. If one, fonr example,
uses a Gecko-based web browser (such as Firefox)
it chooses to get the page one has navigated to, while keeping the
current page visible until the next page is fully loaded, so one
doesn’t experience a white in-between page or a jump, as opposed to how
it’s being handled in Internet Explorer.
From
a web user interface perspective there are a numder of alternatives of
how to emulate frames if one wants to, and the day Internet Explorer
supports the CSS property fixed it will be a piece of cake.
So why do people still use frames? Lack of competence, or are there cases where it is motivated?
The
problem I ran into the other day is that .NET doesn’t generate valid
XHTML. There exists a number of hacks to get around this, and then one
can set what HTML is delivered to different web browsers (basically, high-level HTML to Internet Explorer and old HTML to all other web browsers).
The version of HTML/XHTML being rendered is however customizable in Visual Studio 2005.
Naturally, one wants to write valid code that validates
with its DOCTYPE. However, a colleague of mine recently asked a very
good question, whether there’s any relation between if the page
validates and if it’s being rendered correctly. And basically, the
answer is no.
Of course,
if you have som major erros in your code it won’t look ok, in those
cases the validation can be a hint how to solve the problem.
But
in the big picture it made me wonder if we’re just chasing valid pages
just for the sake of it, not for the ultimate purpose: that it looks
and works the same in all web browsers and behaves consistenly. In the
case of major errors, they should be removed, but if the FORM element
has an extra, invalid, NAME attribute or not doesn’t really matter.
I’m starting to wonder if W3C have gone overboard with the recommendations,
that they’re not alwaws justified. I mean, they’ve given up on the
fabulous IFRAME element to give room for using the OBJECT tag and
setting parameters for it.
This
is, of course, not properly supported by Internet Explorer, so I guess
we can estimate about five years (at least) before we can use that.
Principally,
it’s then impossible to have valid XHTML Strict and IFRAME
functionality and to target all major web browsers, but of course it
works in all of them.
What’s the point of being valid then?