Jeremy Keith's Blog, page 149
February 7, 2011
Erase and rewind
In the 1960s and '70s, it was common practice at the BBC to reuse video tapes. Old recordings were taped over with new shows. Some Doctor Who episodes have been lost forever. Jimi Hendrix's unruly performance on Happening for Lulu would have also been lost if a music-loving engineer hadn't sequestered the tapes away, preventing them from being over-written.
Except - a VT engineer called Bob Pratt, who really ought to get a medal, was in the habit of saving stuff he liked. Even then, the BBC policy of wiping practically everything was notorious amongst those who'd made it. Bob had the job of changing the heads on 2" VT machines. He'd be in at 0600 before everyone else and have two hours to sort the equipment before anyone else came in. Rock music was his passion, and knowing everything would soon disappear, would spend some of that time dubbing off the thing he liked onto junk tapes, which would disappear under the VT department floor.
To be fair to the BBC, the tape-wiping policy wasn't entirely down to crazy internal politics—there were convoluted rights issues involving the actors' union, Equity.
Those issues have since been cleared up. I'm sure the BBC has learned from the past. I'm sure they wouldn't think of mindlessly throwing away content, when they have such an impressive archive.
And yet, when it comes to the web, the BBC is employing a slash-and-burn policy regarding online content. 172 websites are going to disappear down the memory hole.
Just to be clear, these sites aren't going to be archived. They are going to be deleted. Server space is the new magnetic tape.
This callous attitude appears to be based entirely on the fact that these sites occupy URLs in top-level directories—repeatedly referred to incorrectly as top level domains on the BBC internet blog—a space that the decision-makers at the BBC are obsessed with.
Instead of moving the sites to, say, bbc.co.uk/archive and employing a little bit of .htaccess redirection, the BBC (and their technology partner, Siemens) would rather just delete the lot.
Martin Belam is suitably flabbergasted by the vandalism of the BBC's online history:
I'm really not sure who benefits from deleting the Politics 97 site from the BBC's servers in 2011. It seems astonishing that for all the BBC's resources, it may well be my blog posts from 5 years ago that provide a more accurate picture of the BBC's early internet days than the Corporation does itself - and that it will have done so by choice.
Many of the 172 sites scheduled for deletion are currently labelled with a banner across the top indicating that the site hasn't been updated for a while. There's a link to a help page with the following questions and answers:
Why don't you just delete these pages when the programme has ended?
Our view is that these pages often contain a lot of information about the programme or event which may be of interest in the future. We don't want to delete pages which users may have bookmarked or linked to in other ways.
When do you delete pages from bbc.co.uk?
In general our policy is only to remove pages where the information provided has become so outdated that it may lead to actual harm or damage.
It'll be interesting to see how those answers will be updated to reflect change in policy. Presumably, the new answers will read something along the lines of "Fuck 'em."
The website commemorating the 200th anniversary of the abolition of the slave act,
The website for the summer of British film,
The website chronicling composers of the year,
The website documenting wildlife explorers on location,
The website of last year's Electric Dreams, a programme all about the changes in technology over time…
Kiss them all goodbye. And perhaps most egregious of all, you can also kiss goodbye to WW2 People's War:
The BBC asked the public to contribute their memories of World War Two to a website between June 2003 and January 2006. This archive of 47,000 stories and 15,000 images is the result.
I'm very saddened to see the BBC join the ranks of online services that don't give a damn for posterity. That attitude might be understandable, if not forgivable, from a corporation like Yahoo or AOL, driven by short-term profits for shareholders, as summarised by Connor O'Brien in his superb piece on link rot:
We push our lives into the internet, expecting the web to function as a permanent and ever-expanding collective memory, only to discover the web exists only as a series of present moments, every one erasing the last. If your only photo album is Facebook, ask yourself: since when did a gratis web service ever demonstrate giving a flying fuck about holding onto the past?
I was naive enough to think that the BBC was above that kind of short-sighted approach. Looks like I was wrong.
Sad face.
Tagged with
bbc
archive
digital
preservation
linkrot
January 29, 2011
A dark star is born
At Clearleft towers, we've been having semi-regular movie nights, based around a connecting theme. Previous themes include car chases (The French Connection, Bullitt and Ronin) and films set at Christmas that aren't about Christmas (Gremlins and Die Hard).
Last week's movie night's theme was near-future science fiction. We didn't get around to watching Minority Report but we did watch Children of Men and Sunshine.
Danny Boyle's Sunshine is one of those films that gets better with each viewing. Little by little, it's edging up my list of all-time favourites. It has a sense of awe, wonder and humility in the face of science that's genuinely Clarkeian.
It also has plenty of loving references to those other films featuring the trifecta of sci-fi elements: a ship, a crew, a signal. The nods to 2001 and Alien are clear, but something I didn't catch until just the other day was that the character of Pinbacker was named for Sergeant Pinback from John Carpenter's Dark Star.
I know this because, instead of our usual Thursday evening pub gathering and book swapping, the Brighton Speculative Fiction Group this week hosted a puppet show. Paul and Richard recreated all of Dark Star using cardboard, some string, a few dolls and some strategic lighting.
It was one of the best things I've ever seen. Here's the highlight reel.
January 25, 2011
Three questions
Craig Grannell from .Net magazine got in touch to ask me a few short questions about last week's events around HTML5. I thought I'd share my answers here rather than wait for the tortuously long print release cycle.
What are your thoughts on the logo?
The logo is nice. Looks pretty sharp to me.
Why were you unhappy with W3C's original stance ("general purpose visual identity")? What do you think now they've changed this?
I was unhappy with the W3C's original definition of HTML5 in the logo's accompanying FAQ, where they lumped CSS, SVG and WOFF under the "HTML5" banner. I'm happy they changed that.
What's your thinking on the current state of the HTML5 situation, given that WHATWG is dropping the 5 and just going with HTML?
I think the current situation makes things much clearer. The WHATWG are working on a continuous, iterative document called simply HTML. The W3C use that as a starting pointing for nailing down an official specification which will be the fifth official iteration of the HTML language called, sensibly enough, HTML5.
The WHATWG spec is the place to look for what's new and evolving. The W3C spec, once it goes into Last Call, is the place to look for the official milestone that is HTML5. In practice, the two specs will be pretty much identical for quite a while yet.
But the truth is that authors shouldn't be looking at specs to decide what to use—look at what browsers support in order to decide if you should use a particular feature—look at the spec to understand how to use features of HTML5.
For authors, it probably makes more sense to talk about HTML rather than HTML5. Remember that most of HTML5 is the same as HTML 4.01, HTML 3.2, etc. Answering yourself a question like "When can I use HTML5?" is a lot easier to answer if you rephrase it as "When can I use HTML?"
Most of the time, it makes a lot more sense to talk about specific features rather than referring to an entire specification. For example, asking "Does this browser support HTML5?" is fairly pointless, but asking "Does this browser support canvas?" is much more sensible.
January 24, 2011
The Huffduffer Hotline
After seeing (and hearing) what Brian was doing at History Hack Day, I decided I'd have to have a play with Tropo. Like Twilio, it's a service that allows you to build voice-activated apps that you call up and talk to.
The API is pretty straightforward and it seems like there's quite a lot that you can do a developer before upgrading to a paid account. They'll also host your code for you, and you have a choice of scripting languages.
At the most basic level, you can send text-to-voice messages:
say("Hello world")
But you can also give it audio files to play:
say(http://example.com/helloworld.mp3)
Huffduffer has the locations of thousands of audio files, so I thought a voice interface onto Huffduffer's collection would be fun.
Call +1 202 600 8751 in the US, +44 2035 142722 in the UK, or use Skype. When the nice digital man on the other end picks up the phone and asks you want you want to hear, you can respond with "what's new", "what's popular", or say a tag like music, science, history, politics, technology, etc.
The script then fetches the latest files with that tag and will go through them with you one by one, asking "Would you like to hear… ?" followed by the title. If you don't like the sound of it, just say no. When you find something you do want to hear, say yes. It will then start playing and you will be listening to a podcast down a telephone line.
Audioboo / searching huffduffer.com audio by phone on Huffduffer
I call it the Huffduffer Hotline. The code is on Github. If you fancy playing around with the Tropo API and want to use Huffduffer's links to audio files, go ahead. You should find everything you need through the Huffduffer API.
If people find the Huffduffer Hotline useful or just plain fun, I'll upgrade from the developer account to get better performance. Let me know your thoughts on Get Satisfaction.
Tagged with
huffduffer
tropo
phone
voice
Hacking History
I spent the weekend at The Guardian offices in London at History Hack Day. It was rather excellent. You'd think I'd get used to the wonderful nature of these kinds of events, but I once again I experienced the same level of amazement that I experienced the first time I went to hack day.
The weekend kicked off in the traditional way with some quickfire talks. Some lovely people from The British Museum, The British Library and The National Archives talked about their datasets, evangelists from Yahoo and Google talked about YQL and Fusion Tables, and Max Gadney and Matthew Sheret got us thinking in the right directions.
Matthew Sheret was particularly inspiring, equating hackers with time travellers, and encouraging us to find and explore the stories within the data of history. The assembled geeks certainly took that message to heart.
Ben Griffiths told the story of his great-uncle, who died returning from a bomber raid on Bremen in 1941. Using data to put the death in context, Ben approached the story of the lost bomber with sensitivity.
Simon created geStation, a timeline of when railway stations opened in the UK. On the face of it, it sounds like just another mashup of datetimes and lat-long coordinates. But when you run it, you can see the story of the industrial revolution emerge on the map.
Similarly, Gareth Lloyd and Tom Martin used Wikipedia data to show the emerging shape of the world over time in their video A History of the World in 100 Seconds, a reference to the BBC's History of the World in 100 Objects for which Cristiano built a thoroughly excellent mobile app to help you explore the collection at British Museum.
Brian used the Tropo API to make a telephone service that will find a passenger on the Titanic who was the same age and sex as you, and then tell you if they made it onto a lifeboat or not. Hearing this over the phone makes the story more personal somehow. Call +1 (804) 316-9215 in the US, +44 2035 142721 in the UK, or +990009369991481398 on Skype to try it for yourself.
Audioboo / did you die on the Titanic? on Huffduffer
I was so impressed with the Tropo API that I spent most of History Hack Day working on a little something for Huffduffer …more on that later.
My contribution to the hack day was very modest, but it was one of the few to involve something non-digital. It's called London On A Stick.
A pile of USB sticks had been donated to History Hack Day, but nobody was making much use of them so I thought they could be used as fodder for Dead Drops. I took five USB sticks and placed a picture from The National Archives on Flickr Commons on each one. Each picture was taken somewhere in London and has been geotagged.
I slapped sticky notes on the USB sticks with the location of the picture. Then I asked for volunteers to go out and place the sticks at the locations of the pictures: Paddington, Trafalgar Square, Upper Lambeth, St. Paul's and Tower Bridge. Not being a Londoner myself, I'm relying on the natives to take up the challenge. You can find the locations at icanhaz.com/londononastick. I ducked out of History Hack Day a bit early to get back to Brighton so I have no idea if the five sticks were claimed.
Although my contribution to History Hack Day was very modest, I had a really good time. Matt did a great job putting on an excellent event.
It was an eye-opening weekend. This hack day put the "story" back into history.
January 21, 2011
Clarity
Two good things have happened.
WHATWG
Firstly, as I hoped, the WHATWG have updated the name of their work to simply be HTML. This is something they tried to do a year ago, and I kicked up a stink. I was wrong. Having a version number attached to an always-evolving standard just doesn't make sense. As Hixie put it:
…the technology is not versioned and instead we just have a living document that defines the technology as it evolves.
This change means that the whole confusing 2022 business that was misunderstood by so many people is now history:
Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.
The spec is currently labeled as a "Living Standard". Personally, I find the "Living Standard" strapline a bit cheesy. I'd much rather the document title was simply "HTML" followed by the date of the last update.
Note that this change only applies to the WHATWG. The W3C will continue to pursue the "snapshot" model of development so the spec there definitely retains the number 5 and will follow the usual path of Working Draft, Last Call, Proposed Recommendation, and so on.
I think this difference makes it clearer what each group is doing. It was a pretty confusing situation to have two groups working on two specs, both called HTML5. Now it's clear that the WHATWG is working more like how browsers do: constantly evolving and implementing features rather than entire specifications. Meanwhile the W3C are working on having a development milestone of those features set in stone and labelled as the fifth revision to the HTML language …and I think that is also an important and worthy goal.
W3C
The second piece of good news is that the W3C have backtracked on their "embrace and extend" attitude towards buzzwordism. When they launched the new HTML5 logo a few days ago, the W3C Communications Team initially said that HTML5 included CSS, SVG and WOFF‽ As Tantek said:
Fire the W3C Communications person that led this new messaging around HTML5 because it is one of the worst messages (if not the worst) about a technology to ever come out of W3C.
Following the unsurprising outbreak of confusion and disappointment that this falsehood caused, the W3C have now backtracked. HTML5 means HTML5. The updated FAQ makes it very clear that CSS3 is not part of HTML5.
Hallelujah!
I really wasn't looking forward to starting every HTML5 workshop, presentation or article with the words, "Despite what the W3C says, HTML5 is not a meaningless buzzword…" Now I can safely say that the term "HTML5" refers to a technical specification, published at the W3C, called HTML5. Also, I can use that nice logo with a clear conscience.
Over time though, I'll probably follow the WHATWG's lead and simply talk about "what's new in HTML." As Remy points out, there are pedagogical advantages to untethering version numbers:
I don't have to answer "Is HTML ready to be used?" 'cos that's a really daft question!
January 19, 2011
Marklar Malkovich Smurf
Webmonkey: HTML5 Gains Logo, Loses Meaning
It doesn't really matter if the New York Times thinks CSS 3 or SVG are HTML5, but we'd like to think that at least the organization in charge of describing what is, and is not, HTML5 would make some effort to distinguish between tools. Lumping everything together is as silly as a carpenter referring to every tool in their toolkit as "a hammer."
CNET News: W3C's new logo promotes HTML5—and more
Curiously, though, the standards group—the very people one might expect to have the narrowest interpretation of what exactly HTML5 means—instead say it stands for a swath of new Web technologies extending well beyond the next version of Hypertext Markup Language.
GigaOM: The Truth Behind HTML5′s New Logo Fiasco
It's as if the government suddenly announced that from today, all vegetables will be called potatoes, just because some vegetables are potatoes.
The Register: W3C tackles HTML5 confusion with, um, more confusion
And much like Apple, Google, and Microsoft before it, the organization that oversees HTML5 has confused it with all sorts of other web standards.
The Web Standards Project: HTML5 logo: be proud, but don't muddy the waters!
Now the W3C has come out and essentially condoned the branding of everything from CSS to actual HTML5 to WOFF as "HTML5". We can't imagine a single action that will cause more confusion than this misguided decision (and the W3C has produced some pretty impenetrable specs in its time)
Roger Johansson: HTML5 now includes CSS3, SVG and WOFF?
This move from the W3C will not help people differentiate between very different technologies.
CSS Squirrel: HTML5 Super Friends Assemble!
The logo is pretty, but the intentional use of HTML5 as a blanket term for other modern web technologies is a crock. Newspapers making merry with the term is one thing, but a web standards organization?
January 18, 2011
Bye, bye 5
One year ago, I objected strenuously when the WHAT WG temporarily changed the name of their spec from "HTML5" to plain ol' "HTML":
Accurate as that designation may be, I became very concerned about the potential confusion it would cause.
I understand why the WHATWG need to transition from using the term HTML5 to simply using the term HTML to describe their all-encompassing ongoing work, but flipping that switch too soon could cause a lot pain and confusion.
Now that term the "HTML5" has become completely meaningless—even according to the WC3—I think it's time to rip off the bandaid and flip that switch.
I was wrong. Hixie was right. The spec should be called HTML.
If you need an all-encompassing term for every front-end technology under the sun, go ahead and use the term "HTML5." Although personally, I quite like "the Web."
Badge of shame
The W3C have unveiled a logo for HTML5. I'm not sure the world needs such a logo, but I think it looks pretty good. It reminds me of some of the promotional materials used by the Web Standards Project back in the day—simple bold lines that work well at small sizes, with a whiff of Russian constructivism.
But I take issue with the scope of what this logo is supposed to represent. From the Frequently Asked Questions:
The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.
What. A. Crock.
What we have here is a deliberate attempt to further blur the lines between separate technologies that have already become intertwingled in media reports.
Don't get me wrong; I don't mind if marketers and journalists use HTML5 to mean everything under the sun, but I expect working web developers to be able to keep specs separate in their mind. If Apple or Google were pushing this kind of fuzziness, I wouldn't mind …but this is coming straight from the horse's mouth (or, in this case, straight from the horse's ass).
"But," cry the cheerleaders of ambiguity, "we need some kind of term to refer to HTML5 plus CSS3!"
Citation needed.
We never needed a term to refer to "XHTML 1.0 plus CSS2.1" or "HTML4.01 plus JavaScript" or "any combination of front-end technologies." Why this sudden all-conquering need for a term that covers so many different technologies as to be completely meaningless? As I said before:
Clarifying what is and isn't in HTML5 isn't pedantry for pedantry's sake. It's about communication and clarity, the cornerstones of language.
But I guess I've lost that battle. Now even the W3C are intent on blurring the distinction between different technologies to the extent that using a particular font file format qualifies as HTML5.
So now what do I do when I want to give a description of a workshop, or a talk, or a book that's actually about HTML5? If I just say "It's about HTML5," that will soon be as meaningful as saying "It's about Web 2.0," or "It's about leveraging the synergies of disruptive transmedia paradigms." The term HTML5 has, with the support of the W3C, been pushed into the linguistic sewer of buzzwordland. Instead, I will try using phrases:
"HTML5, no really",
"The parts of HTML5 that are documented in the specification labelled HTML5",
"Actual HTML5"
But I think the term that's going to be most accurate is:
"HTML"
January 11, 2011
The design of datalist
One of the many form enhancements provided by HTML5 is the datalist element. It allows you to turn a regular input field into a combo-box.
Using the list attribute on an input, you can connect it to a datalist with the corresponding ID. The datalist itself contains a series of option elements.
I can imagine a number of use cases for this:
"Share this" forms, like the one on Last.fm, that allow you to either select from your contacts on the site, or enter email addresses, separated by commas. Using input type="email" with a multiple attribute, in combination with a datalist would work nicely.
Entering the details for an event, where you can either select from a list of venues or, if the venue is not listed, create a new one.
Just about any form that has a selection of choices, of which the last choice is "other", followed by "If other, please specify…"
You can take something like this:
How did you hear about us?
please choose...
Television
Radio
Newspaper
Other
If other, please specify:
And replace it with this:
How did you hear about us?
The datalist element has been designed according to one of the design principles driving HTML5—Degrade Gracefully:
On the World Wide Web, authors are often reluctant to use new language features that cause problems in older user agents, or that do not provide some sort of graceful fallback. HTML 5 document conformance requirements should be designed so that Web content can degrade gracefully in older or less capable user agents, even when making use of new elements, attributes, APIs and content models.
Because the datalist element contains a series of option elements with value attributes, it is effectively invisible to user-agents that don't support the datalist element. That means you can use the datalist element without worrying it "breaking" in older browsers.
If you wanted, you could include a message for non-supporting browsers:
Your browser doesn't support datalist!
That message—"Your browser doesn't support datalist!"—will be visible in older browsers, but browsers that support datalist know not to show anything that's not an option. But displaying a message like this for older browsers is fairly pointless; I certainly wouldn't consider it graceful degradation.
In my opinion, one of the best aspects of the design of the datalist element is that you can continue to do things the old-fashioned way—using a select and an input—and at the same time start using datalist. There's no violation of the DRY principle either; you can use the same option elements for the select and the datalist:
How did you hear about us?
please choose...
Television
Radio
Newspaper
Other
If other, please specify:
Browsers that support datalist will display the label "How did you hear about us?" followed by a combo-box text field that allows the user to select an option, or enter some free text.
Browsers that don't support datalist will display the the label "How did you hear about us?" followed by a drop-down list of of options (the last of which is "other"), followed by the text "If other, please specifiy", followed by a text field.
Take a look at this example in Opera to see datalist in operation. Take a look at it in any other browser to see the fallback. The source is on Github if you'd like to play around with it.
WebKit's mistake
If you try that example in any browser, you'll get something that works; either through datalist support or through the select fallback …unless the browser is using WebKit.
It took me a while to figure out why this would be the case. I didn't think that Safari or Chrome supported datalist and a little digging around with object detection in JavaScript confirmed this. So why don't those browsers follow the standard behaviour and simply ignore the element they don't understand and render what's inside it instead.
Here's the problem: line 539 of WebKit's default CSS:
datalist {
display: none;
}
This is pretty much the worst possible behaviour for a browser to implement. An element should either be recognised—like p, h1 or img—and parsed accordingly, or an element is unrecognised—like foo or bar—and ignored. WebKit does not support the datalist element (even in the current nightly build), so the element should be ignored.
Fortunately the problem is easily rectified by adding something like this to your own stylesheet:
datalist {
display: inline-block;
}
I've submitted a bug report on the WebKit Bugzilla.
Jeremy Keith's Blog
- Jeremy Keith's profile
- 55 followers
