log e . hixie . c h Hixie's Natural Log

2007-09-26 10:52 UTC A low-bandwidth, high-latency, high-cost, and unreliable data channel I like food, and I'm not really good at the creative art of cooking (though I'm a fine sous-chef), so I eat out at restaurants a lot. I usually pay by credit card. In the US, waiters have a minimum wage below the normal minimum wage, and thus you always have to tip, and so you never pay what the bill says (and I usually tip well, unless the service or food was appalling, even outside the US). The net effect of this is that you basically get to decide how much you pay. Indeed, credit card bills at restaurants have a space where you fill in how much you want to pay. I don't like doing arithmetic, especially not of the kind "$85.47 * 1.17", and so I just approximate. $85.47 is about $90, 15% of $90 is about 15, round to down to cancel out the earlier approximations gives about $100. So I pay $100.00 and go on my merry way. One day I looked at my bank statement and it was something like: POS Trans ZIBIBBO PALO ALTO CAUS $76.00 POS Trans CHEESECAKE PALO ALTO CAUS $40.00 POS Trans OUTBACK #0514 CUPERTINO CAUS $210.00 POS Trans BROOKFIELD'S REST #2 SACRAMENTO CAUS $34.00 Look at all those zero cents... there are data bits there, lying unused! It struck me that with every single restaurant transaction I could set the cents field to some number under my control, thus allowing me to communicate with myself at a later date! This would be really useful as a way of sending ratings information back to myself, so that I could later review the restaurants online or otherwise keep track of where I would want to go back to or where I would want to avoid (since I eat out a lot, restaurants somewhat blend together in my memory). We can set any number from 0 to 99. In binary, that's 0b0000000 to 0b1100011. In other words, we have seven bits to play with, except that if both of the high bits are set, then we lose bits 3, 4, and 5. There are five things I wanted to be able to communicate. The first was the number of guests, so that I can divide the price by how many people I was paying for, to determine the price-per-person. The second was the rating, whether I should go back or not. The last three were whether the restaurant had wifi, whether they were suitable for vegetarians (Carey is vegetarian), and whether they had drinks I liked (I don't drink addictive drinks, drinks containing mind-altering drugs, carbonated drinks, and drinks containing high fructose corn syrup, which basically excludes almost anything you can buy in the US in many cheap restaurants, and even some fancy ones). If we consider the rating to be a four-state flag, with values "avoid", "ok", "good", "awesome", and if we limit ourselves to being able to specify 0, 1, 2, or "more than 2" guests (in addition to me), and if we establish that if we want to avoid the place in future then it really doesn't matter whether the restaurant had Internet, a vegetarian selection, or good drinks, then we can neatly fit this into our contstrained not-quite-7-bit bitfield like this: 64 32 16 8 4 2 1 r d v i g ...where: r The rating, according to the following scale: 0 awesome 32 good 64 ok 96 avoid (and ensure d , v , and i are set to 0) d Whether drinks are good or not (set means they are good) v Whether a vegetarian selection is available (set means there are vegetarian options) i Whether free wifi Internet access is available (set means wifi is available) g How many guests were paid for in the transaction: 0 just me 1 me and one guests 2 me and two guests 3 me and three or more guests I did this, and used it for a while. I quickly discovered that something was wrong. The numbers in my bank statement made no sense, for example dinners with more than 2 guests at locations where I knew that I had been with just one person. I changed to a new scheme. Instead of encoding data in the cents field, I instead just store the last two digits of the dollar amount into the cents field. A checksum, if you will. So if it cost around $34 with tip, then I put $34.34, or if it cost $122, then I put $122.22. I do this reliably now, on all restaurant transactions. What I've found is a shocking number of restaurants don't charge me what I write. For a while I thought I just had bad handwriting, but I then went out of my way to write very clear numbers and that didn't help. For example, Zibibbo's in Palo Alto. I remember very clearly writing $77.77, but was charged $76.95. That's not the original amount without tip (which was probably closer to $65), it's not what I wrote, what the heck is it? On the other hand, the other time I went, they charged me $865.65, exactly what I wrote. A cafe in Monterey (Portola Cafe) charged me $18.28. Either they charged me ¢10 too much, or they gave me a $10 discount. The Melting Pot, San Jose, charged me $70.54. Where did the .54 come from? Why not take the remaining ¢16? Pasta Pomodoro did the same trick as Portola, charging me $37.47. But two months before that, they charged me $34.31, which is probably ¢3 less than I wrote. Why am I getting overcharged sometimes and undercharged others? In Hawaii, the majority of restaurants ignored the tip altogether, just charging me the original amount regardless of what I wrote. Are people in Hawaii so relaxed that they don't need the extra money from tips? My theory is that it is because I don't write an explicit tip, I just give the total. Maybe restaurants need the tip as well as the total, and so to save time they just work out a round dollar tip that is close to what I wrote, and charge me that. My next step, to test this theory, is to start always writing the actual tip amount in. Pingbacks: 1 2 3 4 5

2007-09-04 08:48 UTC Fire, a two-hour weekend, accessibility, and other rants Somewhere over the rainbow,

Way up high,

There's a land that I heard of

Once in a lullaby. The explosion during the man's burn was quite the surprise, but I'm glad they delayed the derrick's burn until after the man because otherwise the man would have been a non-event in comparison. Holy Hannah. This year wasn't quite as enjoyable as last year, but mostly that was just because of the weather: I didn't get to go around the deep playa and jump on art cars as much as I'd have liked. Somewhere over the rainbow

Skies are blue

And the dreams that you dare to dream

Really do come true. While I was away, late last week, while nobody was looking at the #whatwg channel, and in stark contrast to the Burning Man atmosphere, someone visited and asked a question which went unanswered. The log went like this: --> Nicklas18 (i=Nicklas1@c-f54ce155.28-2-64736c13.cust.bredbandsbolaget.se) has joined #whatwg <Nicklas18> Why leave the sense of logic at the door? <Nicklas18> Does that mean that you are not logical? <Nicklas18> Shouldn't people in charge of making a standard have common sense? <Nicklas18> Hello? <Nicklas18> Fucking retards. <Nicklas18> Suck my huge cock. <-- Nicklas18 has left #whatwg (The /topic in the #whatwg channel says "Please leave your sense of logic at the door, thanks!", for reasons that should be obvious to anyone who has tried working with Web browsers for more than about 5 minutes.) The sun is shining,

It's a lovely day,

A perfect morning

For a kid to play, Carey and I have now seen Avenue Q twice, once on Broadway and once in San Francisco. I love this show. Everyone should see it. The internet is really really great.

I’ve got a fast connection so i don’t have to wait.

There's always some new site;

I browse all day and night;

It's like i’m surfing at the speed of light. Work on HTML5 progresses at a measurable pace — literally, now, since I'm measuring the number of e-mails I have outstanding on a regular basis to determine how well I'm hitting my quarterly targets. (Answer: Not as well as I'd like, but not as badly as I'd feared.) As a side-effect of writing the code to trawl my IMAP folders to count the outstanding e-mails, I wrote a tool that also exposes the folders on the Web (after having filtered out the confidential feedback I get, of course). I was hoping this would address some of the complaints about lack of transparency, and indeed a number of WHATWG contributors were interested, gave helpful feedback, and even wrote their own frontends using the tool's APIs. However, from the W3C corner of the HTML5 communities I only got complaints. The most notable complaint was that the tool didn't work in IE, which was apparently a problem not because it actually stopped anyone from accessing the page (I haven't received any complaints from anyone who actually couldn't get to the page) but because it might potentially stop users of old accessibility tools that only work with IE from accessing the page. When you help others,

You can’t help helping yourself!

Every time you

Do good deeds

You’re also serving

Your own needs. I've actually been using the latest version of JAWS (the popular Windows screen reader software for blind people) recently, as part of my work on HTML5. From a usability point of view it is possibly the worst software I have ever used. I'm still horrified at how bad the accessibility situation is. All this time I've been hearing people worried about whether or not Web pages have longdesc attributes specified or whatnot, when in fact the biggest problems facing blind users are so much more fundamental as to make image-related issues seem almost trivial in comparison. For example, JAWS will happily take the last sentence of a paragraph, and the first sentence of the next paragraph, and run them into each other as one sentence, if there's no full stop at the end of the first paragraph. If you really want to make your Web pages more readable to blind users, forget longdesc or even alt , or even markup of any kind, just make sure you're using full punctuation! And that's just one example. Browsing the Web with JAWS is a horrifying experience not because of the poor state of the Web, which is admittedly very poor indeed from the point of view of semantic and accessible markup, but because of the terrifyingly poor state of the screen reader software. What might make my experiences with JAWS even more worrying is that I'm told JAWS is amongst the best of the available screen reader software. It certainly isn't worth its ridiculous $895 price tag (let alone the $1095 price tag for the "professional" version I got). There is a big market opportunity here for someone to make a usable and affordable native speech Web browser or screen reader. Accessibility advocates could do more for accessibility by writing test suites for screen readers to check their basic HTML support (like supporting the p element) than they ever will by trying to educate Web authors. What do you do with a B.A. in English?

What is my life going to be?

Four years of college and plenty of knowledge

Have earned me this useless degree. Going back to my earlier comment, though, I'm a little confused as to why several people who have joined the HTML5 community from the W3C HTML WG side are so hostile, while those who joined the community through the WHATWG side are so much more friendly and constructive. A couple of weeks ago I had to temporarily ban someone from the WHATWG list after they repeatedly cross-posted an off-topic flamewar to four mailing lists including the WHATWG list. (They didn't get banned from the other three lists as far as I know.) I was really sad about having to do this, but the health of the community is important, and sometimes extreme measures have to be taken. This is the first time I've had to do that to someone on the WHATWG list, and the list has existed since 2004. (I've set up personal mail filters for people on the WHATWG list before, to ensure that I read certain people's suggestions only once I've read all the other mail, but I've never had to actually ban someone.) The HTML working group is having a meeting in November. I don't really see the point, but as I told Dan (the chair of the working group), if we do have a meeting, I'd like us to use the unconference style, as that's probably the only useful thing we could do. Hopefully we'll have the agenda this week, that way I can know whether I can justify going or not. I can't really justify spending Google's money on travel, let alone justify the carbon emissions and the time away from editing the spec, without knowing what exactly the meeting will consist of. If the meeting just consists of us going through open issues and discussing them, then I won't go, since in my experience that's a huge waste of everyone's time unless the issue has already failed to be addressed by more asynchronous methods like e-mail. For technical work like this you really need to be able to sit down and think about issues, and ponder them with a whiteboard; it is very hard to make sure all the applicable research has been done when there is pressure to discuss and reach a decision on a topic in 60 minutes or less. This is especially true since for almost all issues, the first time you look at it you'll find many things you need to research, and it can take days to get all the data you want to make an educated decision. Using actual data to make decisions about technical issues isn't a very common practice in W3C working groups, which is probably why a lot of the people in the HTML working group who come from a W3C background think a face-to-face meeting is a useful thing to have. I want you to know

The time that we've spent

How great it's been

How much it's meant. In July we went to Oslo, Bergen, Geneva, Lourtier, Mamaroneck, Staatsburg, and Hillsdale, to see friends, family, and folk music. The Falcon Ridge Folk Festival has a sign language interpreter on every stage. Now mind you, this is a music festival, a specifically sound-orientated event. Yet it is highly accessible; all the songs have alternative fallback content for those who cannot hear them. There are several things about this that I noticed. First: The visual version of the song (lyrics in sign language, and the emotional content of the voice, expressed in the facial expressions and style of the sign language interpreter) doesn't convey the same thing as the original audio version (the melody, the harmony, the percussion, the lyrics, and the emotion in all of those). It is merely a translation of the parts of the audio stream that aren't intrinsically audio-only. Alternative content doesn't necessarily convey everything in the primary medium, nor does it have to to be useful and enjoyed by the target audience. Second: The sign language interpretation is actually quite fun to watch even if you can hear the music, it's like a kind of interpretative dance. Alternative content is useful to those who don't need it as well. This isn't just my opinion. It was clear at the festival that the sizeable deaf community present there was fully enjoying the music. The presence of sign language interpreters made them feel part of the event, and conveyed everything that they wanted conveyed. Meanwhile, the hearing patrons enjoyed the music and the sign language — I heard comments from several people to the effect that the sign language interpreters were effectively an intrinsic part of the act. (To the point where even people who didn't necessarily understand sign language had opinions on which interpreter was better.) It's interesting how the prevailing opinion of Web accessibility experts is so far removed from the existing and successful accessibility practices in the non-tech world. Pingbacks: 1

2007-06-15 07:39 UTC Notes for drivers: The meaning of Red Lights It came to my attention while I was cycling to Bab5 tonight that not all drivers of big cars may be fully aware of the meaning of this device sometimes found near intersections: For the purposes of making sure drivers in the area are well educated, I would like to clarify the meaning of this device. It means "stop". That is to say, "do not turn left onto oncoming traffic". Thank you for your attention.

2007-06-06 08:21 UTC The CSS working group is irrelevant Back in March, Google hosted the CSS working group for a three day meeting. At the time, we were just starting with the HTML working group, and the openness of the WHATWG over the past few years was just starting to be adopted by the HTML working group, after several months of pushing for it in the W3C (mostly in secret, though my own posts on the matter were all public, as were a few others). One of the things I brought up in the CSS face-to-face meeting was the problem of the CSS working group not being open. Many of the members of the CSS working group have a mentality that view the Web community (such as those who e-mail the www-style mailing list) as a resource, not as potentially equal members of the community. Of the forty or so members of the working group (those subscribed to the secret internal mailing list), only a dozen subscribe to the public list. This actually makes it harder for members of the group to try to be more open — when someone posts a proposal to the public list, there's a good chance that the majority of the members of the working group will miss it. During the meeting, I opined that if the group continued along in this direction, the group ran the risk of becoming irrelevant; two of the other members suggested that the group was already irrelevant. Sadly we were in the minority. The CSS working group right now is chronically dysfunctional, as most close observers have noticed. A great example of this is the difference in how the WHATWG got a blog and how the CSS working group set one up. In the WHATWG, the idea was floated for a while, and then one day someone volunteered to run it, and the blog was up and running within hours. Anyone (literally anyone) can post to the WHATWG blog (there's a moderation step that we added to deal with the spammers, but all it takes now is to get onto IRC and ask for the post you wrote to be published). The CSS working group, on the other hand, has been discussing how to set up a blog, and what the first entry should say, and what tool to use, for over two months! Nearly every phone call (the group has weekly teleconferences) for the past nine weeks has had the blog discussed at some point. The blog was finally made available last week. To post, you have to be a group member. The first post can be summarised as follows: the CSS working group members don't want to bother going out of their way to get feedback on their specs; instead, people should post their comments on CSS to the public CSS mailing list (despite the fact that most CSS working group members aren't subscribed to this list). The blog post then goes on to apologise for the blog's existence, and claims that the blog's aim is to reach the people who won't subscribe to the public mailing list (the working group itself, maybe?). The post doesn't make it clear how the blog is expected to reach this wider audience, since the blog has no comment feature. Another example of the problems of the CSS group is visible on the W3C's Technical Reports page. The group's primary deliverables are specifications. The last candidate recommendation published by the group was published in 2004. That was the Basic UI module, which was Tantek's baby (he has since left the group). Meanwhile, drafts like the Backgrounds and Borders draft, which has had big parts implemented by Safari for months, and small parts implemented by Mozilla for years, have iterated several times but make no public process (the backgrounds and borders draft was published in 2005, but the internal draft was last modified in February of this year). Meanwhile, CSS2.1, the working group's most important deliverable, keeps getting tied up, with the group discussing irrelevant details and some members repeatedly reopening old resolved issues. The W3C process doesn't help much here either; the group actually tried taking CSS 2.1 to Candidate Recommendation stage recently, but was blocked by the W3C management over an issue which was already present in CSS2. (In all fairness to Tim, the issue he raised is one which was already raised by several other people, but which the group had dismissed. I actually agree with him that it should be resolved. The group has since resolved to change the spec in a way that continues to leave the issue undefined, but at least it no longer contradicts what Web browsers do.) The group is also supposed to work on test suites. I had volunteered to work on the CSS 2.1 test suite, but due to lack of time, I bailed on that last year (Google mainly employs me to work on HTML5; any test work that I do is done in my free time, which is mostly spent near aquariums now). Since then basically nothing has happened. Being public would expose a lot of these problems, forcing the working group to act more responsibly. It would also allow people to contribute — as specification editors, as test suite editors, as reviewers, as community leaders, and in other roles. But to be honest, the problems go even further than what I've described above. The CSS specs show their age; they come from a time where specifications were much vaguer than those of the modern day. Someone really needs to do to CSS what the WHATWG has been doing to HTML, defining everything in detail, explicitly, with strict and clear normative conformance criteria, taking implementations into account, defining things like quirks mode. (The WHATWG community refers to such a hypothetical project as "CSS 5", as a reference to the way the current WHATWG specs define HTML5, XHTML5, and DOM5 HTML.) The CSS working group also doesn't really have the nimbleness needed to respond to threats to the Web platform like Silverlight. We need things like flowing-to-shapes, automatic declarative transition animations, gradients, filters, styling of form controls, and so on. (The WHATWG is already handling some related, non-presentational, things, like client-side SQL databases, video, and rich controls.) We need these things this year, in enough detail that they can be implemented. An open group can iterate much faster than a closed group. With an open group we can get test implementations, feedback, tests, and discussion straight away, instead of waiting months and then pulling back the curtain and presenting a fait accompli, at which points comments are perceived more as a pain than a help. One way to address this would be for the WHATWG to start a "subproject" to address CSS, while we wait for the W3C CSS group to learn from the W3C HTML group and become open. The biggest problem would be finding editors who would be willing and capable of doing the incredible work of rewriting CSS from scratch. Pingbacks: 1 2 3