log_e.hixie.ch

2005-03-08 21:18 UTC XForms myths

I'm getting tired of hearing XForms advocates say things that are either misleading or clearly wrong, so here's a quick list of myths, or misleading truths, about XForms, which I have heard recently (most particularly during the multiple demos of XForms software at the plenary in Boston last week).

XForms is declarative

XForms has declarative aspects, just like HTML. But it isn't exclusively declarative. XForms in fact introduces a primitive XML-based scripting language (called XForms Actions) to perform imperative actions.

For example, you can use the setfocus element to set the focus to another element, or the load element to make the UA follow a link.

Scripting is bad for accessibility

False. Scripting doesn't hurt accessibility. What hurts accessibility is when semantically meaningless elements are given some sort of device-specific behaviour (for example, making a div into a checkbox or a scrollbar, or using the font element for headers).

Script is harder to maintain than XPath expressions

False. It depends entirely on what you're doing. The reason most JavaScript on the Web is a mess is because it is badly written; the same would happen to XPath if the same authors used that instead.

HTML mixes presentation and content — XForms doesn't

False. HTML doesn't mix presentation and content — authors do. XForms doesn't prevent the two from being mixed, in fact one of the big things people are pushing these days is SVG+XForms, which is the ultimate mix of presentation and content.

XForms is better than HTML because it is media-independent

False. Both HTML and XForms are as media-independent as each other. If XForms is better it has nothing to do with one or the other being media-independent.

HTML mainly specifies how the control should look, while XForms specifies what the control should do

False. HTML doesn't specify how the controls should look at all.

HTML has limitations, so it had to be replaced with XForms

False. It's easier to fix HTML than to replace it with an entirely new language.

HTML requires authors to use hacks; XForms doesn't because is cleanly designed

False. HTML doesn't require authors to use hacks, browser bugs do. And there's no reason to believe that XForms UAs will be any less buggy than HTML UAs, if it's the same programmers writing both UAs.

To demonstrate some of these points, I took the XForms Calculator example, which was used as an example of some of XForms' power at the W3C Plenary last week, and made an HTML version.

Note that I didn't fix any of the bugs in the sample — there are a number of ways in which this demo is broken. I just converted the existing XHTML1+XForms+XForms Actions+XPath to the exact equivalent HTML4+JavaScript+DOM to see how it would compare.

<xf:toggle case="add"/>

operation = add;

<xf:action ev:event="DOMActivate">...</xf:action>

onclick="..."

<td>
 <xf:trigger>
  <xf:label>9</xf:label>
  <xf:action ev:event="DOMActivate">
   <xf:setvalue ref="/equation/displaybuffer"
                value="/equation/displaybuffer * 10 + 9"/>
   <xf:setvalue ref="/equation/display"
                value="/equation/displaybuffer"/>
  </xf:action>
 </xf:trigger>
</td>

<td>
 <button onclick="display = displaybuffer
                          = displaybuffer * 10 + 9; update();">
  9
 </button>
</td>

Pingbacks: 1

2005-03-08 16:05 UTC Desperate Measures

It finally got to me. The amount of spam I was receiving finally hit a critical point. I was off the grid for a couple of days, and of the 938 e-mails I had when I got back, half were from automated systems (like Bugzilla), and half were spam, with the remainder (like half a percent or something) being from the three or four dozen mailing lists I'm subscribed to. I think there was one interesting e-mail out of the 938.

So. All my mail now goes through Razor, Spam Assassin (set to a pretty low tolerance level), and GMail's spam filters, before being redirected into my inbox. I don't plan on checking for false positives too much, so if you want me to read your mail, I would encourage:

• Using plain text e-mail; not HTML mail.
• Replying in context, quoting just what needs quoting; not top-posting and including the entire thread in the mail.
• Spelling correctly.

GMail in particular seems to have no compunction about flagging valid mail as spam if it looks even slightly boring.

2005-03-06 12:38 UTC Winter 2005 Travelog: Part 3 (Ugh)

This plenary didn't end quite as ideally as I might have hoped — not for any political or technical reasons, but because I ended up flat out in my hotel room with a fever, a runny nose, alternating hold and cold sweats, headaches, and generally Not Being In A Good Shape. Also, I thought travelling east sucked, but it turns out travelling east while ill is even worse.

The net result of this is I missed the last day of the plenary. Once I've finished recovering from this unexpected flu or whatever it was I'll have to check the minutes to work out what decisions were made during my absence in case I disagree with any of them!

2005-03-02 14:58 UTC Winter 2005 Travelog: Part 2 (Versioning)

One of the early panels at the W3C Plenary was about extensibility and versioning. The moderator asked the room to think about, and write an answer to, this question: How should specs manage error handling?

I thought about it then quickly wrote Define detailed error-handling rules. Then I looked over at what David had written. Define error handling clearly. Then I turned to see what howcome had written. Forward-compatible parsing.

Probably not surprising, given that we're all from the CSS world, which has been addressing this exact issue by defining error handling (under the name "forward-compatible parsing") for many years now.

2005-03-01 04:25 UTC Winter 2005 Travelog: Part 1 (Snow)

It was snowing indoors.

We were in the subway station near the airport and were very baffled because despite the quite obviously air-tight roof, it was snowing indoors.

The universe is apparently not bug-free.