I don’t think I mentioned this before, but there’s an aural-CSS supporter besides Emacspeak out there. It’s called Fonix SpeakThis, and while its aural CSS support is pretty limited, it does exist. (A tip of the hat to The Literary Moose, by the way, for passing along the information.) I find the existence of another aural-CSS browser, however limited, to be interesting in light of the aural style sheets appendix of CSS2.1, which says in part:
We expect that in a future level of CSS there will be new properties and values defined for speech output. Therefore CSS 2.1 reserves the ‘speech’ media type… but does not yet define which properties do or do not apply to it. The properties in this appendix apply to a media type ‘aural’, that was introduced in CSS2. The type ‘aural’ is now deprecated.
In other words,
aural is a dead end, and
speech will be used in the future. At some point. Really.
Raffi Krikorian raises some long-term problems arising from URL-shortening services that are worth pondering. It isn’t the case that absolutely everything has to be preserved for all time, but how many links would suddenly break if a popular shortening service disappeared? I already don’t like such services because they hide the ultimate destination, which robs me of an important piece of information in my quest to decide whether or not I should follow a given link. How many times have you seen a post that says, basically, “This is interesting!” followed by a shortened link? It could be a political story from the BBC, a collection of Battlestar: Galactica fan fiction, the official site of the Malaysian legislature, or an outrageously disgusting fringe-porn site. How can you tell? By following the link. It’s like Web roulette. Place your bets!
I guess it’s also true that shortening services irk me because they should be utterly unnecessary. In the first place, there’s almost no excuse for URLs to be so long that they need some kind of shortening service. Okay, maybe mapping programs have some excuse, but that’s about it. The kind of enormous cryptic URLs that most database-driven sites generate is just sloppy and wrong. In the second place, as for putting URLs in e-mail and newsposts, you can contain the URL in angle brackets—
<http://like.this/>—and any client worth running will understand that the whole string is a single URL, and ignore any line-wrapping that might occur within the brackets. If your program can’t handle that, especially if it tries to interpret the bracketed text as an HTML tag, then it’s time to get another one.
Incidentally, the title of today’s entry is a hand-shortened form of “Speech, Shells, and Shortening.” Which is better? Granted, it’s kind of cool having an entry title that sounds like a door on Star Trek, but it isn’t what I’d call particularly useful for determining the contents of the entry before you actually read it. See what I mean?