On the WHATWG public mailing list Ian Hickson linked to a survey done by Google on how authors write HTML. There is some great data in there on used class attribute values, HTTP headers, used elements, misspellings of the not-to-be-used language attribute of the script element and more. Really great.
There are some accessibility problems with the pages though as pointed out by Peter-Paul Koch. The pages also do not mention that Opera could be used as well (and make the text in the images actually readable by zooming in), but the lack of proper fallback content is a bigger issue.
Joe Clark weighs in: The author of the series – obviously Ian Hickson – has a bit of a history of pluperfect Web pages. Some of the graphs, indeed illegible on various of my computers, have puny stubs of alternate content, but the whole presentation is a boondoggle. He’s trying to explain how real-world authors ignore standards using a standard we have all chosen to ignore.
Just a note on Opera -- the currently released version (8.51) doesn't handle the graphs. It takes the Opera 9 preview to display them.
An interesting thing to note: it doesn't display perfect in Firefox 1.5 either. Some graphs are cut off at the right (or rather the numbers below the graphs). I find it at the very least ironic that the advised browser merely performs satisfactory and not excellent.
Opera 9 does very good job here having abilities to zoom all content including SVG. Great!
I use zoom feature on my 1600x1200 screen every day... and for that day I noticed only one (but old) issue.
FataL That image bug seems to have been fixed here :-)
OMG! You make my day! Great!
Soooo, when we can see new release? I know - WIR! ;)
Fatal: You answered it for me ;-)
It’s not just Firefox and Opera. The charts work in WebKit nightlies, too.
For the record: I didn't mention Opera because Opera's current released version doesn't handle the graphs. I didn't mention Safari for the same reason. The graphs do have "proper fallback content". I didn't use PNGs because those are even less accessible than SVG, would have been more of a pain to create. Everyone that we expected to read the report was almost certainly already using a browser that could handle SVG.
Y'know, Ian, it wouldn't have been that hard to produce something which would have worked with Adobe's SVG plugin as well. All you would have had to do was add the line
<?xml-stylesheet href="webstats.css" type="text/css"?>
to the top of each SVG file.
Was that tiny bit of interoperability too much to ask?
Oh, and one more thing. If you sized the graphs in em, instead of px, then they would zoom along with the text. Surely, the main selling point of using vector graphics for the graphs is to have something that rescales smoothly along with the text. Why ruin that by sizing the graphs in px?
To clarify Comment 9, the current SVG files are invalid, because the XML-Stylesheet PI omits the REQUIRED type attribute.
Just because Firefox doesn't care about the omitted attribute, doesn't mean that other, pickier UAs won't care either. The Adobe plugin, for one, does care.
The type pseudo-attribute is not required. The errata change the specification in type CDATA #IMPLIED.
On comment 10, in Opera, the images scale when using zoom. Your UA just doesn't allow you to change the dimensions. This doesn't mean that these vector images have failed.
Also in SVG, px units are equal to one unit in the coordinate system. They scale when the dimensions of the image change, for example with user-defined css.
Also in SVG, px units are...
I wasn't talking about the dimensions of SVG elements. I was talking about the height of the <object> element in an HTML document. Most browsers do not rescale <object> and <img> elements, whose sizes are specified in px, when you zoom the text.
If Opera does, that's very interesting. But it's uncommon behaviour (I would say "nonstandard," but there is no Standard for how UAs should behave in this regard).
The type pseudo-attribute is not required. The errata change the specification in
type CDATA #IMPLIED.
I stand corrected.
Though reading the explanation is a hoot:
Correction: The declaration is changed to: type CDATA #IMPLIED so that it is optional.
Rationale: This pseudo-attribute is adopted from HTML 4.0, where it is optional.
type attribute to the <style> element was type CDATA #REQUIRED.
type CDATA #REQUIRED.
type CDATA #REQUIRED.
type CDATA #IMPLIED for compatibility with HTML 4.0.Funny stuff, man.
But, regardless of whether it is REQUIRED, it's a good idea to include it, both for the sake of UAs which we know require it (Adobe's SVG plugin), and for the sake of other UAs, whom we can save the trouble of downloading a stylesheet, only to find that it's of a type that they don't support.
I loved reading it - there's some very funny writing in there!
Jacques, you want the link element. Nevertheless all those specifications are crap and in need of an update, but I guess that may take a while.
Jacques, you want the link element.
Fascinating.
Really, the XML-Stylesheet PI borrows features from both <link rel="fubar"> (e.g., rel="stylesheet" and rel="alternate stylesheet" get mapped to alternate="yes|no") and from <style> (media="...").
If one had to choose between them, "obviously" one would want to model it on the generic <link rel="fubar"> element.
Nevertheless all those specifications are crap and in need of an update, but I guess that may take a while.
In the meantime, one needs to deal with what currently exists...
The most-used attribute on
htmlelements isxmlns, from misguided people using XHTML but sending it astext/html.
Maybe because Googlebot does not recognize pages sent as application/xhtml+xml. Google, as long as Googlebot still sends an Accept header of text/html,text/plain, don't you hixishly scold me for serving it XHTML 1.0 as text/html.
A whole slew of people are specifying the xml:lang attribute, which will have absolutely no effect (no HTML processor will look at that attribute; it's an XML attribute).
That would be the influence of XHTML 1.1 dropping lang in favor of xml:lang.