Hixie's Natural Log

2007-03-08 20:32 UTC How YOU can join the W3C HTML5 Working Group in six easy steps

So the W3C announced that they are restarting an HTML specification effort.

Anyone can actually join the W3C HTML Working Group. I encourage everyone interested in the development of HTML5 to take part. If you don't take part, and the language develops in a way you don't like, then you have but yourself to blame.

Taking part in the group is not a big commitment. You can spend as much or as little time contributing; you don't need to read every e-mail on subjects you don't care about, you don't need to call in or attend face-to-face meetings. In fact, the W3C has stated in the group's charter that no binding decisions will be made at meetings; you are guaranteed equal say whether you are present or not.

To join, you have to go through the following steps.

  1. Fill in the Public Access Request Form; in the "Reason" field, put: "To apply for participation in the HTML Working Group as an Invited Expert."
  2. Within about five minutes you'll receive a confirmation code by e-mail. Follow the instructions in that e-mail.
  3. You should get a reply back from that within two days, giving you a username and password. Fill in the W3C Invited Expert Application form. Under "Financial Support", if you're not going to attend any meetings or if you're going to attend meetings on your own dime, just put "Self-supported". Under "Possible W3C Membership", if you're employed but your employer doesn't know you're doing this, or doesn't care, just pick "My employer does not intend to join".
  4. E-mail Dan Connolly and Karl Dubost (connolly@w3.org, karl@w3.org) asking for approval. (Just say "Hi, I'd like to join the HTML working group. Thanks.")
  5. You should get a reply back within about ten days, at which point you can fill in the Joining the HTML Working Group form.
  6. You will get a reply back from that within about five minutes, at which point you're a bone fide HTML working group member!

Note: if you work for a W3C member company, the steps above don't apply to you. Instead, you have to follow these instructions.

I would encourage everyone interested in working with the HTML working group to go through these steps as soon as possible, so that you will be a member of the group before the work starts.

While you're at it, you can also join the WHATWG effort. We've been working on HTML5 since 2004, and have an active community with IRC channels, a help mailing list, forums, an open blog, and so forth. To join all you have to do is take part in one of those, or join our main specification development mailing list. All input is welcome.

Pingbacks: 1 2 3 4 5 6

2007-02-28 09:00 UTC Fixing the "usemap" attribute

Back in 2001, the XHTML working group published XHTML 1.1, a set of XML DTDs to allow people to use HTML4's semantics together with XHTML Ruby in XML.

That document contained a very minor mistake. In HTML4, the usemap attribute of img elements is defined to take a URI, but in the XHTML 1.1 specification, it's defined as taking an IDREF. The working group actually had already known about it in 2000, but had decided it wasn't a big deal to break compatibility here. (Sorry, that's a W3C member-only link — the XHTML working group is not an open working group; it does all its work in secret.)

In late 2001, the group discussed the issue and decided to reopen it (secret link again).

In early 2002, Jukka K. Korpela reported the issue to the working group. The XHTML working group replied saying they'd discussed this and agreed to fix it (secret link again, sorry). They even actually did agree (secret) to fix it, a few weeks after announcing they had so agreed.

It was reported in passing in mid-2002 in the HTML validator mailing list, where it was reiterated by the HTML working group that this was a mistake that would be fixed.

Tantek then proposed to the HTML working group (secret) that the real solution would be to allow the "#" character but not make it a URI.

The issue was once again reported in 2004 by Bjoern Hoehrmann. This time, the working group replied (in secret) that they had decided that it wasn't in fact an error, but that it would be changed in future versions of XHTML, just not in the XHTML 1.1 version. (No trace of Tantek's proposal remaining.)

At the end of 2004, it was again reported on the validator mailing list. The HTML working group did not reply.

It was once again reported in 2006 by Anne van Kesteren. There, the working group said they agreed "in principle" (and in secret) but that they would do the change in a later version, rather than fixing the XHTML 1.1 specification. Anne made it clear that this wasn't satisfactory, but the working group dismissed (secretely) his concerns saying it was the group's explicit goal not to fix problems while they updated the specification.

While all that was happening: in 2004 a group of people including myself formed an open working group known as the WHAT working group and started working on a specification for HTML5. As of today, that specification is mostly complete; I'm now going through the thousands of e-mails of feedback we received over the past few years. One of the things that spec does is specify exactly how usemap should work, both for HTML and XHTML: it's really neither a URI nor an IDREF, it's what we're calling a hashed ID reference, and it has very specific parsing rules and processing models, which are detailed carefully and completely.

Meanwhile, the XHTML working group has published a new draft of XHTML 1.1, which still has the IDREF problem.

In fact, the only change I can see is that they added XML Schema support, along with a boatload of new boilerplate text to put at the top of the document. Your XHTML 1.1 conformant documents now start with (the emphasised parts are the required bits, the rest can thankfully still be skipped):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"

In contrast, an HTML5 conformant documents start with:


So. To recap. In the time it took the closed and secretive XHTML working group to release a new version of this specification which did not fix one of its simplest problems despite that problem being reported multiple times, the open and transparent WHAT working group wrote an entire HTML specification, more detailed than any previous such effort, and fixed the problem in the process.

Pingbacks: 1

2007-02-23 09:02 UTC The Station-Names-Inspired-By-San-Diego Railway: Power

I got some 6017 boosters for our layout and started plugging them in. While doing so I noticed that the DIP switches on my 6021 control unit were set to ON/ON/ON/OFF.

I was curious about this, because the DIP switches on the boosters, according to the booster manual, for our layout, have to be set to OFF/OFF/OFF/OFF. So I looked at the 6021 manual, and it says that ON/ON/ON/OFF is the setting for when you want to use the "new" (well, "new" as of 1993, I guess) protocol, which is compatible with almost all the "old" stuff, except the 7651 rotary crane (which, despite what little evidence Google has, does exist).

This wasn't a problem back when I first set up my control unit, but it turns out that I have since aquired a 7651 digital rotary crane. (Long story. The moral is: don't impulse buy something in the three-digit price range when you're waiting for a train on your way to leave the country.) But the crane works fine! How is it not compatible? I'm baffled. Can anyone explain why the 7651 wouldn't be compatible with the 6021 ON/ON/ON/OFF state?

What's even more baffling is that the documentation I am holding in my hands — the official manual for the 6021 unit — contradicts the 6021's official page to which I linked above, the latter of which says that ON/ON/ON/OFF is only to be used with the 1 Gauge track, and that it must absolutely not be used with HO (our layout is HO). That page says that for HO you want OFF/OFF/OFF/OFF, a combination which the manual says will enable a legacy mode in which the f1-f4 functions don't work. The unofficial reverse engineered wire-level Motorola/Märklin protocol documentation actually seems more useful and precise on this front than any of the official documentation. Except it also says "the former type of extended function decoder was mounted in some Digital coaches and in the Digital crane from Märklin. It works ONLY if the new Control Unit has Dip switch No.1 OFF", which is clearly untrue, since I have exactly that situation and it works fine!

That page also points out a couple of bugs with the 6051 interface that explain why certain things are flaky. I'll have to see if I can work around some of those bugs.

On another note, something that I hadn't done yet is estimated power consumption on the layout. We have a dozen or so trains, but about 4 of them are moving at a time, usually, sometimes maybe 6 or 8. So let's say 8 trains moving simultanesouly; the manual says that's about 80VA. There's always some accessory being activated, an additional 10VA. We only have one additional controller (the 6051), which the manual says would use 2VA. We also have a turntable, which is 10VA, and two cranes, another 10VA. So that adds up to about 112VA. Each transformer does 42VA, and we now have two boosters, so that adds up to 126VA. Talk about cutting it close. We probably need another few boosters really. That doesn't bode well, given how scarce they are these days.

However, having now tested the new setup (and then fixed the various electrical faults I caused), I have to say it is looking good! Trippling the power available to the layout has made significant improvements to the track.

2007-01-29 21:06 UTC Writing specifications: Knowing when to stop

When you're writing a specification, it's important to define the terms you use. For example, if you use a term like "browsing context", or "application window", or "pointing device", you should make sure you have a definition of that term. It's important, because you are really inventing a new word for yourself, for your specification, to help you write the requirements concisely. It's a bit like defining macros, constants, or functions in a programming language.

However, you do not need to define words that are plain English words (or whatever language you are writing in). For example, you don't need to define the word "is". You don't need to define the term "purely advisory". However, you might well be asked to define terms that to you seem quite clear. The way to tell if you need to define the term after all is to look at the dictionary definition. If the dictionary definition seems to you to be pretty close to what you were saying, then you don't need to define the word — you're using it appropriately. If the dictionary definition doesn't cover what you mean, e.g. because you're using it in a metaphoric way (e.g. "window", "desktop"), then you'll need to define it.

Don't fall into the temptation of discussing the meaning of the word "meaning".

2006-11-10 01:30 UTC Investing in the Fruit Company

How times have changed. Years ago, I teased Hyatt for his decision to work for Apple (on what people later found out was Safari). Today, I have a Mac Mini as my alarm clock (and as the back end for my model railway control panel), an Apple Cinema Display as my entertainment center, a Powerbook as my main laptop, and I pour tons of cash down mouth of the iTunes Store every month in order to stay up to date with all my favourite TV shows. When I'm in San Francisco, I feel compelled to visit the Apple store. Of all the stores I went to in Zurich, the first one was an Apple store. I watch Apple keynotes like a cult member. My presentations are done using iWork.

Today, I added to my collection; FedEx delivered me my new shiny black 80GB portable hard disk (with colour screen). I believe the term used for these hard disks is "iPod".

I've long been skeptical of the idea of watching TV on the tiny iPod screen, but I have to say, it's not that bad, especially for watching things like Strong Bad's e-mails. I'm not saying I'd watch Stargate on my iPod, but still.