2006-08-10 18:40 UTC
SVG Tiny 1.2 in Candidate Wreckommendation stage
Today the W3C announced that SVG Tiny 1.2 entered the Candidate Recommendation stage.
To do this they had to violate the W3C process: they skipped straight from Working Draft to Candidate Recommendation, skipping the required Last Call stage. Oh and they didn't even wait the requisite minimum three week period between drafts. Nor did they respond to all the comments on their last draft.
But those are mere minor problems compared to this:
The SVG group received three hundred or so technical comments (according to their numbers). This is a very small number (CSS 2.1 has received something in the region of a thousand comments). But the shocking thing is, according to their own numbers, they dismissed over 10% of all comments!
This is huge! It's even more frightening when you consider that SVG Tiny 1.2 had a huge number of grammar errors, and so a big fraction of the comments were simply saying that there was a typo here or there.
They had fifteen objections that were so important to the commenters that they were reported as "formal objections" (and that doesn't even include any of the things that I objected to, because apparently I didn't use the right magic phrase when objecting).
I'll let you draw your own conclusions.
Pingbacks:
1
2006-08-07 11:27 UTC
The sacrifice of pragmatism over theoretical purity
A while back I mentioned that the HTTP Content-Type header was effectively dead on the Web, with Web browsers being forced by market demand to ignore authoritative metadata regarding data formats, in favour of having Web browsers automatically determine the type of the content the user is viewing.
In particular, this is required for video on the Web — millions of videos are served as text/plain and a Web browser that displays garbage instead of showing the video is one that will get very few happy users — and for feeds (RSS, Atom, etc), which are more often than not served as text/html despite being XML. (As a side note, a little over two years ago Mark Pilgrim pointed out that XML on the Web was dead too, also because of feeds. Seems these popular feeds could be responsible for the destruction of the Web!) It's also needed for images — many images are sent using the completely wrong MIME type, e.g. GIFs as image/png, or PNGs as text/plain, or JPEGs as application/octet-stream, and browsers uniformly ignore the MIME type when it comes to <img> elements. Same with scripts — it doesn't matter what you label your JavaScript files as, at all; when it comes to <script> elements, browsers uniformly ignore the HTTP Content-Type header and rely exclusively on the attributes on the element.
However, it seems that these real world concerns are not a factor in the TAG's findings, since the day after I posted the aforementioned blog post, they published a document describing how browsers must always follow Content-Type headers, how specifications must never require browsers to ignore such headers, and how authors must all go and correct their mis-configured servers. (I only recently became aware of this document, I don't normally follow the W3C TAG.)
I'm curious as to how they're going to go about making people follow their recommendations. Until the servers are fixed, browsers can't fix their behaviour, because users would consider the spec-compliant behaviour to be a regression ("the previous version showed the video, the new version just shows garbage"). So that means that they presumably are going to get all the servers fixed.
But how?
Until then, HTML5 is going to continue the pragmatic route, and will be requiring UAs to ignore Content-Type in certain situations (mostly those I mentioned above). It sucks, but I'd rather have the spec be implementable in the face of real world content than have it be uniformly ignored.
Pingbacks:
1
2
Well if you-
ever pla-n
to motor west,
Jack; take my way;
it's the highway
that's the best!
Get your kicks
on route
sixty six.
A few weeks ago I ordered Stargate SG-1 Season 9 from Amazon. The package soon arrived, but contained Stargate SG-1 Season 8. Season 9 hasn't been released yet. Amazon refunded my credit card and apologised for the mislabelling on the site. I didn't want a chargeback. I wanted Season 9! After all, Season 10 is being broadcast on the networks, how long do I have to wait? Could they at least put the episodes up on Google Video or the iTunes Music Store or something (side note: while looking up the syntax of iTunes Music Store URIs I came across the most romantic blog post I've ever read) so I could buy them before the DVDs come out? Don't they understand that they have fans who don't have a TV? Still, that's not Amazon's fault. I was impressed that Amazon volunteered to do a chargeback without the slightest reluctance between 6pm on Friday (when I received the package and filed the complaint) and Saturday morning (when they sent me the e-mail confirming their mistake).
Well it wi-nds
from Chicago
to L. A.
More-than-two-o-
thousand miles
all the way.
Get your kicks
on route
sixty six.
Also in the package from Amazon was the Cars soundtrack (yay!), with two versions of Route 66. It's strange how Americans rhapsodise about their roads. You never hear Brits sing about the virtues of the M4, or wax lyrical about the A350. While musing on this I came across a remake of Route 66 but about the A13. The differences between the original and this version are symbolic in so many ways.
Well it go-es through Saint Louis,
Jo-plin, Missouri;
Oklahoma City looks oh!-so-pretty. You'll see-e...
Amarillo;
ah-Gallup, New Mexico;
In other news, Eira and Dag visited for a few days, which was nice. We went to the beach, where I dug a hole for my ball and didn't trip into it (though Eira did). My beach ball this time was a lot larger than last time, for reasons that I won't go into that involved three very kind shopkeepers in Santa Cruz and a mechanical foot pump. Some evil person covered me in sand while I was reading my book.
Flagstaff, Arizona;
don't forget Winona;
Kingman, Barstow, Sa-n Bernardino! Won't you-
get hip to-this timely tip
and take
that Califorina trip.
The ocean is cold.
Get your kicks
on route
sixty six.
We also visited San Francisco, where I saw Superman (much better than I expected), and failed to see more than three sea lions (it's the summer), and ate at a very nice Cafe, called Cafe Divine, at Union and Stockton. After eating at the latter, which I must emphasise was very good in every respect, we spent a few hours in the nearby park. The sun was so bright that I found that I could read my laptop screen with the backlight turned off. I love my Powerbook.
While Eira and Dag were here we went to visit one of Dag's old friends, who used to work for SGI. He showed us a watch, made by Tag Heuer, which SGI had given him and which he hadn't looked at for some ten years or so. "What time is it?" I asked. "About thirty minutes past eleven." "Exactly how many minutes past eleven?" "Twenty-three past eleven." I laughed and tossed the watch back to Dag's friend, remarking upon the proficiency of Swiss horology with a quip like "Swiss made, baby!" (Tag Heuer is a Swiss brand.) Upon further investigation we found that the watch, which had been set to an accuracy of plus-or-minus one second back several years ago using NTP, was now only three seconds out of sync according to NTP.
There have been three leap seconds in the last ten years.
It-goes: through-Saint-Louis!
a-Jo-plin-Mi-ssouri!
Oklahoma City looks ohh! so- pretty. You'll see...
Amarillo;
ah-Gallup, New Mexico;
The week after that I bought a Mac Mini. It now runs my trains. I also bought a Linksys router which prominently mentioned the GPL on its packaging, and flashed it with a custom Linux-based firmware. This brings the total number of computers in my flat to an unreasonable five, running Windows XP, PowerPC Mac OS X, Intel Mac OS X, a Fedora Core distribution, and an embedded Linux distribution.
Flagstaff, Arizona;
don't forget Winona;
Kingman, Barstow, Sa-n Bernardino! Won't you-
get hip to this timely tip?
Speaking of my trains, Kerz and I are now starting to add levels to our layout. Today we went out and bought styrofoam (which it turns out is far cheaper at Home Depot, where it costs something like $20 per sheet, than at House of Foam, where it costs something like $220 per sheet). Boy does cutting this stuff make a mess. But we did good progress, and I'm very happy. We desperately need some 6017s and 6001s to power the track, though, it's somewhat sad how little power there is in the tracks. Adding hills isn't going to help matters.
Take- that California trip?
A few days ago I came across Eternal Flame, a parody recorded on Eli's label (Eli was my landlord/flatmate when I was an intern at Netscape). I mention this because of one line of the lyrics which totally floored me for no apparent reason: "...the Lord could not count grains of sand with a 32 bit word".
Get your kicks
on route
sixty six.
Who does 32bit maths these days anyway. All the code I've written recently is 64bit-native, isn't yours?
Get your kicks
on route
sixty six.
When I'm not doing all the above fun things, or relaxing at Bab5 (mmmmm, hot tub...), or playing board games, or going rock climbing at the gym in Sunnyvale, or trying to turn Aardvarks into Fearsome Nobles, or playing Jazz with colleagues, I sometimes watch videos online. Some of them are apparently part of modern pop culture, some are shorts that made the Canne Film Festival, others are tech talks.
And I'll meet you-u
on route
sixty two;
My current project at work is to specify, in near-complete detail, the document.write() DOM API, for both HTML and XHTML. This is proving non-trivial. Another word would be "challenging". I haven't yet thrown myself off the Googleplex roof, but it is an ever-present risk when having to deal with the insanity of browsers.
Get your kicks
on route
sixty six.
I was thinking this morning about a possible extension to the Namespaces in XML spec that might make life easier for authors.
<html xmlns="import svg xbl html">
...
<body>
...
<svg>
<rect .../>
</svg>
</body>
</html>
That is, add a new feature: the default namespace URI, if it starts with the string "import" followed by a space, is a space-separated list of keywords representing namespaces from which to look up each element. So in the example above, the "html" element is in the HTML namespace, the "body" element is too, the "svg" element is in the SVG namespace, and the "rect" element is in the SVG namespace. UAs would have a hardcoded list (given in the spec for this feature) of which element names are in which namespace, to make this possible. That way authors don't have to remember namespace URIs and they don't have to deal with namespace prefixes. Clashes would be solved by picking the first namespace in the author's list. Unknown elements would end up either in the last namespace specified, or the "" non-namespace, whichever way it was defined.
Alternatively we could have xmlns="web document", maybe, which would simply have the same effect but with a hard-coded list of namespaces and element names, so the authors don't even have to remember which languages to import. That would be less flexible, but the flexibility might not be needed.
The problem with this is how to introduce new element names; there'd be a long lag before people could start using them. That would be a reason to pick the namespace most likely to get new names as the default. Note that this wouldn't clash with existing usage of xmlns since you can't have a space in a valid namespace URI today.
This script appends an element to the DOM. The
element is itself a