Conversations with Joe Clark
19th December 2002
Jonathan Delacour is three days in to his Conversation with Joe Clark series (see also parts one and two and the introductory book review). I thoroughly recommend reading the whole series, but here are a few points that stood out for me:
In the meantime, firing all the boy-racer HTML programmers who think they’re tough shit would be a good place to start. They’re jumped-up script kiddies; it was quite telling that my submission of well-written, copy-edited text in a valid HTML document was an absolute first for Slashdot. This is a clientele that does not know what the Shift key does or how to debug two nested ordered lists. (The latter is an actual example from a site I worked on. The concept of closing a paired tag had never occurred to them, so they could not find the error in the sequence
<ol><li><ol><li></ol>
.)And of course we’ll also have to fire the boy racers’ clueless Dockers-wearing manager dweebs, who consider themselves old-timers because they got online in 1998 (!) and whose entire experience of the Internet is the commercial Web as rendered through Internet Explorer for Windows. These people cannot even *spell* “W3C” and still think banner ads have not been given a fair shake.
If we could rid the Web-development ecosystem of life-sapping parasites like these—essentially, everyone who is immature and/or has *bad taste*—then we stand a good chance of making valid, standards-compliant Web development the norm rather than the exception
To avoid the risk of misrepresenting Joe’s responses by quoting the above, I should mention that the rest of the series is far less inflammatory.
This note about accessible forms also caught my eye:
People use tables for forms so that online forms look like printed forms—that is, they use as much of the “paper” as possible, because “paper” is expensive. But online we have unlimited screen real estate, at least in the vertical dimension. HTML forms, at root, yearn to be vertical, not horizontal. Do not flout their natural desires. Do not attempt to overlay the design of printed forms onto online forms.
Finally, yet another reason not to spend hundreds of thousands of pounds on an “enterprise” CMS:
The larger CMSs are a kind of protection racket: You buy our system for six figures, and then you keep paying us every year to maintain your license, and also you’ll have to hire a person trained in our ways to keep your system up and running. Fail to do any of that and your entire site crashes. It’s extortion, really, and high-end CMSs are dogs in so many ways—they can’t produce valid code, their URLs are appalling, and they are difficult to use. In essence, big CMSs are mainframe systems, with the same need for constant nursing and non-stop tending by codependent system administrators as those old mainframes.
The comments attached to the various stories are also well worth reading. I particularly liked Mark Pilgrim’s argument as to why Joe’s controversial views on fixed font sizes should be taken with a healthy pinch of salt:
Simply put, I believe that there is a large class of people who would not in any way refer to themselves as “visually impaired” or “disabled” in any way, who nonetheless can not read 9px type on their computer monitor. Reading on-screen is hard enough as it is, and tiny type in stupid fonts only makes a bad situation worse. These affected people are not running screen magnification software as Joe suggests; they are not running any accessibility-related software at all, because they do not view themselves as disabled. At most, they may be running in a display theme with slightly larger fonts, which means that everything on their computer that they read on a regular basis (menus, buttons, toolbars) is readable -- everything except web pages that use absolute font sizes.
My Father certainly falls in to this category of users, and was very impressed when I showed him Mozilla’s text resizing ability (he had not realised text resizing was possible in IE either). I find it extremely annoying that modern browsers consistently hide their basic text resizing options—IE 3 got it right by including an increase/decrease text size button in the main toolbar by default but browsers since then have all conspired to hide the option in a menu where it is far less likely to be found by casual browser users.
More recent articles
- Storing times for human events - 27th November 2024
- Ask questions of SQLite databases and CSV/JSON files in your terminal - 25th November 2024
- Weeknotes: asynchronous LLMs, synchronous embeddings, and I kind of started a podcast - 22nd November 2024