Just a Coder - nickfitz.co.uk

If you’re working with (X)HTML and CSS you’ll be aware - or you need to be aware - that browsers render pages differently depending on whether they are in Strict or Quirks mode. (There are explanations of what these terms mean from Microsoft and Mozilla.) It can be useful to have a way of making certain which mode you’re in when tracking down inconsistencies in browser behaviour.

A quick and easy way to tell is to type the following snippet of JavaScript into the location bar:

javascript:alert(document.compatMode);

which will pop up a box stating either “BackCompat” for Quirks mode, or “CSS1Compat” for Strict mode.

If you’re using Firefox and have the Bookmarks toolbar visible, you can drag the following link on to it to create a handy little button you can use to check which rendering mode the browser is in on any page you visit. In Internet Explorer, right-click on the link and select “Add to Favorites…” to achieve the same thing. (You’ll get a warning that the link “may not be safe”; at that point you have to decide how much you trust me. Believe me, it’s safe.)
Rendering mode

I find this tremendously useful for doing checks on pages, particularly when editing pages by hand, where a simple typo might throw a page into Quirks mode, with resultant frustration as CSS which previously worked suddenly goes completely to pot.

(Note that the “CSS1Compat” actually means “CSS2Compat” in browsers with support for CSS 2.1.)

I wasn’t able to make it to @media, but I did travel down to London for the JavaScript get-together in the Old Thameside Inn on Saturday afternoon. Peter K of Quirksmode had an agenda of three primary items which he anticipated eight or nine JavaScript geeks turning up to discuss; the actual figures were nearer the 30 mark, and a lot of the attendees were from the design community, so the first two parts of the meeting were instead devoted to the primary question that @media had brought up: how to get the message about the correct use of scripting out to the larger community who are already working with standards-based HTML/CSS techniques, and now want to get into the possibilities they’ve perceived through offerings like GMail and Google Maps.

Stuart Langridge and Jeremy Keith have already written up summaries of what was decided, so I won’t bother repeating them, but will move on to the discussion about the original three questions.

By the time we got onto these topics we’d moved outside, and numbers had decreased considerably; perhaps as a result of this, decisions were made fairly quickly (if they were made at all). In short, the results were:

1. Naming: We’ll call it DOM Scripting;
2. The dreaded onload problem: All the things you’d think would work don’t. However Mozilla has an undocumented DOMContentLoaded event (which is probably to be standardised), and Dean Edwards explained that it is possible to provide support for this using IE behaviors (.htc files). I’m planning to do some experimentation on this one to see what the best approach is when working with other browsers, although I’m probably just repeating Dean’s work.
3. We’d all drunk enough by then that the discussion of Design Patterns drifted off into speculation about the noise a bagpipe band would make marching off a cliff and other important topics, but I’ll probably carry on with my advocacy of object oriented tehniques (suitably adapted to JavaScript’s strengths and weaknesses) until others point out how utterly wrong I am.

So to summarise, you should expect to see a lot of writing coming out from this point onwards designed to propagate the meme of DOM Scripting, which can be defined as the process of enhancing web pages by adding a behaviour layer which beefs things up using standards-based techniques, degrades gracefully when JavaScript support is absent, and doesn’t interfere with accessibility when it isn’t absent.

If you’re wondering what that last bit means, consider the revelation brought to us by Derek Featherstone: screen readers may not support JavaScript, but the browsers they read from do. Some of the implications of this are covered by Derek in this follow-up to his @media presentation, and I have no doubt it’s something we’ll hear a lot more discussion about in the future. It means we’ve got to forget about just testing with JavaScript turned off if we want to be accesible, and that means rethinking a lot of things.

Finally, thanks to everybody for making Saturday afternoon such an enjoyable and informative gathering. I hope to catch up with you all again; if not before, there’s always @media 2006.

P.S.: if you’re looking for more info about the presentations at @media, don’t miss Isofarro’s excellent notes and transcripts.

The Web Standards Group presented ten questions to Tommy Olsson, one of which addresses the thorny issue of the abbr and acronym elements in HTML.

Tommy’s discussion of this was informative, and I was particularly entertained by his assertion that

Netscape invented ABBR, while Microsoft invented ACRONYM, and both types meant the same thing. Then the W3C incorporated both in HTML 3, but with subtly different semantics. Microsoft’s meaning of ACRONYM was replaced by something different, which made the people at Microsoft so furious that to this day they still don’t support the ABBR element type!

as I came across a manifestation of this (possibly imaginary) dislike for the abbr element in Internet Explorer quite recently.

Consider the following markup fragment:


<p>An example of an abbreviation might be <abbr title="Limited Liability Company">Ltd.</abbr>, used in the UK to denote a private company with limited liability.</p>


One would expect a browser which supports HTML 4 (which IE is claimed to have done since version 4) to produce a DOM structure as follows:

• Element: p
  • Text: An example of an abbreviation might be
  • Element: abbr
    • Text: Ltd.
  • Text: , used in the UK to denote a private company with limited liability.

Whereas IE actually produces the following:

• Element: p
  • Text: An example of an abbreviation might be
  • Element: abbr
  • Text: Ltd.
  • Element: /abbr
  • Text: , used in the UK to denote a private company with limited liability.

Yes, that’s correct: the initial abbr is parsed into an element, the text within remains as a childNode of the paragraph, and an element with the name /abbr is created.

If you try to use the createElement method of the document to create such an element, you naturally get an exception. But internally, IE manages to create an element whose name begins with a slash.

I don’t have a PC at home, so I can’t check right now whether or not spurious markup like <goat>Hello</goat> produces the same result, but I’ll check at work tomorrow and report back.

Long-delayed update: The <goat> example above does indeed produce the same results.