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.
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.
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".
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 myownpostsonthe
matter were all public, as were a
fewothers).
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 richcontrols.)
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.
So Apple started selling music without DRM the other day. I immediately bought some music. Carey commented that she had bought a lot of
music on iTunes in the past and never really understood DRM, so wasn't worried about it.
Later that evening, we were at my flat, where there is no Internet. She wanted to play her music on my Mac Mini, which is basically my
entertainment system. She made her MacBook join my wireless network, grabbed the remote and fired up Front Row on the Mini, and (after I fixed
the firewall settings) tried playing a song she wanted to listen to.
A concise lesson in why DRM is not a "consumer enablement" technology ensued.
I really don't understand why DRM is legal, let alone why it's legally enforceable in many countries. Right now I think it's mostly just the
geeks who understand why DRM is fundamentally stupid, but I hope that as more users get exposed to technology and try to do obvious things like
transferring their media from one device to another, they'll come to demand their fair use rights, and the law will swing back from backing the
modern organised crime rings (like the MPAA) to backing the ordinary citizen. Question copyright.
Everyone should make sure to learn about fair(y) use.
For the recent long weekend, Carey and I went to Monterey to see the aquarium. We joined and visited the fishies four times that weekend.
Some of the exhibits were more art-like than I expected:
We also went down Scenic Highway 1, which has some scenic parts, and where petroleum is even more expensive than in less remote areas.
Before we left we stayed at Carey's, where Max decided to bring me a live bird! What a darling cat. He's so cute.
In other news, I met the TAG for lunch today. It was an interesting experience. I still don't really understand what they're doing. At one
point I asked about one of their documents and pointed out that for most specs things have to be defined in terms of document models, not the
actual byte streams coming over the wire. For example, for HTML you have to define what happens when an author creates a table
element using the DOM APIs and then moves a p element into it — what does that represent. There's no source byte stream, it's all scripted. The
members of the TAG seemed to think that was a little more complicated than they wanted to deal with. That was sort of strange to me, since I
somewhat consider that to be the only interesting case (in the HTML5 spec, the byte stream, if any, is converted to a DOM before any of the
things that they were talking about are examined). Oh well.
June is going to be an interesting month. The HTML working group is supposed to publish something (I suggest the spec); Apple is going to announce their latest stuff, which I'll probably
buy; Pixar are releasing Ratatouille (Holy Pixar Day is June 29th); Wilhelm will be in from out of town so we can play World of Warcraft (the
board game).
