Category Archives: Standards

Standards, protocols, recommendations and guidelines.

Web Developer Quiz

Characters, General, MarkUp, Standards

This quiz is designed to test whether or not web developers have an understanding of the basic technologies used on the web, primarily HTML, HTTP, Media Types (MIME) and character repertoires and encodings. Personally, I expect every single web developer to pass this quiz with flying colours, yet reality tells me that a large proportion will struggle. So, in the interests of finding out exactly how much web developers in general do and do not know, and for your own personal benefit, I decided to publish this quiz (or survey, if you like).

Firstly, a few ground rules. Please don’t cheat. I expect all web developers to know the answers to these questions without the need for reference material or the use of automated tools. That means, please don’t make use of the validator or look up the specifications to answer these questions, they’re designed to be easy enough to answer without such tools, yet still provide enough of a challenge for all but the most knowledgeable authors. Secondly, in order to give everyone a fair go and avoid chance of having all the correct answers given away in the first response, I’ve temporarily enabled comment moderation and no comments will be appearing until I publish the results and answers next week. Ok, so on with the quiz…

This sample document applies to the first 3 questions. You may assume the HTTP headers contain:

Content-Type: text/html;charset=UTF-8

Note: This document uses some special syntax that is not widely supported in existing browsers; it is only designed to test your knowledge of HTML.

1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
2. <html lang="en">
3.   <title/Sample HTML 4.01 Document/
4.   <p align="right">This is a sample HTML 4.01 Strict document.
5.   <>How much do you know about HTML?</>
6.   <!-- -- --> <em>It’s not hard!</em> <!-- -- -->
7.   <p>Created by <a href=http://lachy.id.au/">Lachlan Hunt
8. </html>

Validation

Which lines in the above HTML document contain validation errors, if any? Note: I’m only looking for those errors that will be reported by a conforming SGML based validator.

Elements in the DOM

  1. How many p elements are there within the above document?
  2. Which of these elements, if any, will not be present within the the Document Object Model of the above document?
    • <head>
    • <body>
    • <em>

Semantics

  1. Which markup structure is the most semantically correct for a navigational link menu, regardless of how it will be presented visually? 
    1. <div class="menu">
    <a href="…">Link  1</a> |
    <a href="…">Link 2</a> |
    <a href="…">Link 3</a>
</div>
    2. <div class="menu">
    <a href="…">Link  1</a><br>
    <a href="…">Link  2</a><br>
    <a href="…">Link  3</a><br>
</div>
    3. <ul class="menu">
    <li><a  href="…">Link 1</a></li>
    <li><a  href="…">Link 2</a></li>
    <li><a  href="…">Link 3</a></li>
</div>
  2. Which markup structure is the most semantically correct for a title within the document body that may be horizontally centred in a visual medium (eg. screen) using a large, bold font?
    1. <div class="title">Document Title</div>
    2. <h1>Document Title</h1>
    3. <p align="center"><font size="+3"><b>Document Title</b></font></p>
    4. <h1 style="font-weight:bold;font-size:large;text-align:center;">Document Title</h1>
    5. <h1 class="LargeBoldCenterHeading">Document Title</h1>

Character References

Given these three numeric character references, and two character entity references:

  • &#x2019;
  • &#8217;
  • &#146;
  • &rsquo;
  • &apos;
  1. Which ones are invalid for an HTML 4.01 document?
  2. Which ones are invalid for an XHTML 1.0 document?
  3. Which ones are invalid for a generic XML document? (assume no DTD or Schema)

Media Types (MIME)

  1. Which of these MIME types SHOULD NOT be used for an XHTML 1.1 document?
    • application/xhtml+xml
    • text/html
    • application/xml
    • text/xml
  2. Using the answer from the previous question, under what conditions MAY (according to the recommendation) an XHTML 1.0 document use that MIME type?

Crowne Plaza – Web Site

General, Personal, Standards

Around 3 months ago, I started working for HotHouse – a web development company with a relatively strong focus on standards and accessibility. Well, I’m pleased to announce that the first project I was involved with, for which I primarily wrote the HTML, CSS and some (but not all) JavaScript, launched a few weeks ago: Crowne Plaza – Hunter Valley. (Note: the visual design was done by others at HotHouse, I only converted the design into HTML and CSS)

Overall, I have to say, that I’m quite proud of the site and very pleased with the results, though there are issues I would like to see addressed with future projects. It uses mostly standards compliant HTML 4.01 Strict. Unfortunately, it doesn’t completely validate but it does use fairly well structured, semantic markup and (almost) completely separates the content from the presentation.

The reason is doesn’t validate is due to some custom attributes that are, apparently, required by the form validation script provided by another company, that was outsourced to handle the form processing for the contact forms. In my opinion, they should have used the class attribute instead, but they didn’t and we just had to accept it.

If you look closely at the markup on some pages, you’ll also notice some small layout tables used. I know I’m a hypocrite, but when the client demands pixel perfection from obsolete browsers (read: IE6), you really are left with little choice but to make some sacrifices. I tried absolutely every other method I could think of to have an image on one side and a column of text on the other, that did not flow around like it would if the image were floated and that worked in well in at least IE, Firefox and Opera. In the end, with time running out, I made the small sacrifice to include a relatively harmless table for the purpose.

For the stylesheet, I decided to make use of Tantek’s high-pass filter to ensure that IE5 users were given the Netscape 4 treatment: no style whatsoever. This is actually a way to be nice to such users, as the result with the stylesheet applied was disastrous. At least, this way, the content of the site remains accessible fully accessible, even if doesn’t look as great.

As I mentioned above, I also wrote some JavaScript for this page. The purpose of the script, despite my objections, was to provide popup windows for some links (For anyone that doesn’t know: I despise popup windows!). This included the Hotel Gallery, with links to a few photos of the hotel, the map and the weather. So, I did it in the most accessible way I could, which wouldn’t affect users with JS disabled/unsupported and still allow them to access the images, nor interfere with users that indiscriminately prevent popup windows of all kinds, like me. For such users, the link simply points to the image itself. For users with JS enabled (and popups not blocked completely), the image is loaded into a popup window.

The weather link is a little different. The reason is apparently because it’s a link to an external site – a very common misconception about usability, looked at from a marketing perspective. Jakob Nielson has a good rant about this. Remarkably, the script for the weather link is similar to that recently published by Bruce Lawson, in that it applies a target attribute dynamically to the link. I chose this approach for several reasons:

  1. It separates the behaviour of opening a new window from the markup
  2. It’s one less validation error to worry about (yes, I know using script to hide validation errors is, at best, a pointless exercise)
  3. It behaves nicely for users with JS disabled (i.e. no popup window).

Naturally, this method is also considered harmful for the same reasons as Bruce’s script and I really would like to see the use of popup windows abolished in sites developed by HotHouse (and, in fact, all web development companies), I just need to become more involved in the earlier phases of development and be able to present better alternatives.

Lastly, one more thing I was able to achieve correctly, was to set the correct HTTP Content-Type header and include the charset parameter, since I was given access to the PHP prior to launch. The headers now correctly include: Content-Type: text/html; charset=UTF-8, and avoids using the superfluous meta element.

DOM 2 Events

Projects, Script, Standards

The Document Object Model Level 2 defines several interfaces for an event handling model, called DOM 2 Events, that is far superior to the traditional model used by most web developers around the world. In the traditional model, you assign an event handler to an object using the onevent properties. e.g. window.onload = fn;. This has many limitations, with the most annoying being that it only accepts one event handler.

In the past, many attempts have been made to work around these issues, with one of the most widely known being Scott Andrew LePera’s Crossbrowser DOM Scripting: Event Handlers. Recently, Peter-Paul Koch wrote an article entitled addEvent() Considered Harmful. Following this, he launched a competition for someone to rewrite the addEvent() function and write a new removeEvent() function to address the issues with the original.

A few days ago, after I heard about addEvent(), I began work on a new script to address many of the issues with it. The result is beyond anything that was expected for the competition. In fact, I’m pretty sure it’s beyond what most mere mortals even considered possible: I implemented much of the DOM 2 Events interfaces in IE!

What does that mean exactly? Well, it means that you can now use the W3C’s superior DOM2 model across browsers without any of the mess. For example, a script that used to be written like this:

var foo = document.getElementById("foo");
foo.onclick = go;

function go(evt) {
    evt = evt || window.event;
    target = evt.target || evt.srcElement;
    // Handle other cross-browser issues
    doSomething(target);
    ...
}

That can now be reduced to this much more sane method from the DOM2 interfaces:

var foo = document.getElementById("foo");
foo.addEventListener("click", go, false);

function go(evt) {
    doSomething(evt.target);
    ...
}

There’s no need to check for evt || window.event, nor any need to check for evt.target || evt.srcElement. Much of that cross-browser incompatibility mess is taken care of by my script. All that you, the authors, have to do is work with the standard DOM 2 interfaces! You can take a look at the heavily commented script and also my entry for PPK’s competition, which nicely demonstrates the script in action.

The following interfaces, properties and functions are supported from DOM 2 events:

Interface EventTarget
addEventListener
dispatchEvent
removeEventListener
Interface EventListener
handleEvent
Interface Event
PhaseType Constants (CAPTURE_PHASE, AT_TARGET and BUBBLE_PHASE)
bubbles
cancelable
currentTarget
eventPhase
target
timeStamp
type
initEvent() (not supported)
preventDefault()
stopPropagation()

Along with these event interfaces, there are a number of other interfaces I implemented including a fully conforming .getElementsByClassName() function, as defined in the Web Apps 1 for both the Document and Element interfaces, a prototype implementation of DOMTokenString() and many more, all availble in my DOM example script repositiory.