Re: Does the W3C have anything useful left to say?

One of the issues raised in course of the discussion titled "Does the W3C have anything useful left to say?" was the silliness of having escape & as & in URLs. But there is actually a reason why this is required and why the validator complain about it:

Escaping ampersands is necessary to avoid accidental ambiquity. There are plenty of named entities in HTML and you'll often see people wondering why <a href="http://example.com/?something&alpha=something"> doesn't work as expected. And anyway, the W3C knows this and nowadays recommends ; as the parameter separator.

I sometimes wonder why programmers seem perfectly happy working with compilers that give up at the first misplaced comma, yet complain loudly when asked to follow the HTML specification. (Not a rhetoric question, actually.)

Incidentally, this isn't really a defense of W3C. If you want a sobering tale of dysfunctional spec and process, look no further than WCAG 2.0:

http://alistapart.com/articles/tohellwithwcag2

Originally posted on 2006-07-21

Re: Crawlers and Ajax

Will browsers see pages generated with Ajax? This question was posed in the topic "Crawlers and Ajaz" at Joel's The Design of Software forum.

They don't. There have been rumors about crawlers based on headless browsers being developed and tested, but apparently they aren't ready for the prime time yet.

To get search engines index your content, it has to be reachable without JavaScript and there must be pointers (well, links, really) to it that don't need JavaScript either.

You might want to rethink your approach in any case, since being reliant on JavaScript usually means not supporting deep linking. And not supporting deep linking means making people less likely to link to you. Not to mention potentially compromising browser compatibility and accessibility unless implemented carefully.

Try looking up graceful degradation and progressive enhancement on Google. These are development approaches that allow you to increase compatibility in less than optimal circumstances without downscaling the best available user experience.

Originally posted on 2006-07-12.

Re: Handling Refresh F5 in Ajax Apps

Correcting a common misunderstanding regarding the support of onbeforeunload in Safari in the topic "Handling Refresh F5 in Ajax Apps" at Joel's The Design of Software forum:

Actually, Safari 2.0 supports onbeforeunload but there are two gotchas:

1) You must use "return" instead of setting "event.returnValue".

2) If you click the back button, answer Cancel to the onbeforeunload question, click back again and answer OK, you'll go back two steps instead of one.

Problem #2 has already been fixed in the WebKit nightlies and the fix will probably ship with the next Safari release.

I also posted an example of how to use onbeforeunload:

No, it's "onbeforeunload" alright. "Onunload" is called at a later phase and can't be used to cancel leaving the page.

window.onbeforeunload = function() {
  return 'You have unsaved changes. You will lose them if you continue.';
}

I don't like how it overloads the meaning of return value in event handlers, but the provided functionality is great.

Originally posted on 2006-06-27 and 2006-06-28.

Re: Web designers are not idiots

Something I wrote in response to a subthread in part of a topic "Web designers are not idiots" at The Joel on Software Discussion Group.

I fail to see the point of arguing that "people who work with HTML are programmers" if that means stretching the definition of programming beyond any descriptiveness and usefulness.

In the case of tomato being a fruit or a vegetable, both defitions of fruit have merit. One is botanical, useful to scientists, and the other is culinary, useful to cooks and ordinary people.

Saying that writing HTML is programming is akin to saying fungi are animals: you can make a reasonable argument to that effect, but the arguments for the opposite view are stronger. I see the point about demystifying programming, and I too have sometimes told people how things they already do are in a sense programming while explaining what programming is. However, I also think that a proper explanation of programming requires explaining how "programming" is different from the "programming in a sense".

Anyway, if you read web designer and developer blogs and forums, there's a clear consensus about the terms. Working with HTML is "coding", and the people who do that are "HTML coders". Programming is "coding" too. I know from first-hand experience what coding HTML and CSS is like (and how hard work it is), and I see no disrespect in saying it's different from programming which is something I also do.

Originally posted 2006-07-01.