Poor, Black, and Ugly

Missouri’s Governor Nixon asked the Missouri Attorney General to file suit in court to block the Army Corps of Engineers from blowing up the Birds Point Levee.

Blowing the levee will flood farmland and about 100 homes in Missouri, but not blowing the levee could very well endanger the entire town of Cairo, Illinois. A few years back, I wrote about Cairo, Illinois the town that pulls you in, as it pushes you away.

When Time covered Cairo, Illinois last year it described the town as poor, black, and ugly. It is, indeed, very poor and predominately black, but I cannot find it ugly. Or if I do, it’s an ugliness that reflects the south and our history and the civil rights fight and all that is both good and bad about this part of the country.

I guess the best description I have of Cairo is that it is a very real town.

Of course, none of this matters to the Missouri governor who wants to protect the farmland of Missourians. Missourians who happened to know they were building farms on lands designated as spillway, and that there was a potential for the Corps to breach the levee if flood proportions matched that of the 1937 floods. Well, we’re about to pass the levels of the 1937 floods.

But then again, who wants to save a town that’s poor, black, and ugly?

That’s just not right

Earlier, I found a PR release from the AVMA (American Veterinarian Medical Association) undermining Missouri’s Proposition B in favor of its “model bill”. In an associated video, the AVMA’s CEO, Dr. DeHaven, states that Proposition B only sets limits on the number of dogs that can be kept, when in actuality, Proposition B does more (DeHaven’s video)—much more than the AVMA model bill, which relies almost completely on a commercial dog breeder honor system (and large scale commercial dog breeders are not necessarily known for their honor).

Afterward, I received an email related to a bug I’m following in the HTML5 working group. In response to detailed, thoughtful request for a way to provide alternative text for a video poster, the HTML5 editor, Ian Hickson, declined, writing as rationale:

The request here is just cargo-cult accessibility and would not
actually improve the life of any users, while costing authors in wasted time
and effort.

I reacted the same to both: that’s just not right.

You would think that humane treatment of dogs and ensuring accessibility for folks would be no-brainers, equivalent to being “agin sin”. You would think so…and you would be wrong.

Whatever sense of empathy and compassion we had, once upon a time, seems to have been left in a long ago forgotten consciousness. Today, what rules is the bottom line, and if that bottom line must run over the bodies of puppies and disabled, equally, run it must because there’s a new sense of pragmatic necessity that rules in the land.

Those who cannot see do not really need to know what the poster to a video is all about, because authors can’t really be bothered to provide the information. It’s not pragmatic to even consider the option. As Hickson stated earlier in the discussion of the bug:

I’m confused. Why would you (a blind user) want to know what the poster frame
is? How does it affect you?

How does it affect you‽

The welfare of dogs is important, yes, but not at the cost of the rights of the breeder. Weighing the needs of the dogs over the wants of the breeder is not pragmatic. The AVMA invited Wes Jamison, a communications professor from Florida, to speak about the role of veterinarians in today’s society. What he said explains much about the AVMA position:

Dr. Jamison … indicated that the veterinary profession, by emphasizing the importance of the human-animal bond, enables consumer hypocrisy, which is exploited by animal protection organizations. He argued that the AVMA should abandon advocating for the human-animal bond in favor of fighting for the right of animal owners to use animals as they choose, whether that entails companionship, food, or labor.

The human-animal bond is hypocrisy‽

Pragmatic hell, that’s just not right.

Microsoft’s proposed namespace distributed extensibility in HTML5

Per Sam Ruby, Microsoft has submitted a proposal for distributed extensibility in HTML5, which features the use of namespaces.

The proposal uses reverse DNS names, but other than those ugly sons-of-bitches, it looks promising. There are some issues, including no support for innerHTML on namespaced elements, because they would end up defined as Element, not HTMLUnknownElement, but I don’t think that’s going to be a real problem in the wild. More importantly, I believe the proposal would handle the problems I noted in my last writing, about the valid use of namespaced elements and attributes in SVG. The issue with namespaced elements in SVG isn’t a made-up problem or one that is unlikely to occur: it is a real problem, it will occur in the future, and it does require real solutions. The problem is not going to go away because Ian Hickson clicks ruby shoes together and murmurs “There’s no such thing as namespaces…there’s no such thing as namespaces…” This absolute refusal to acknowledge something that has existed on the web for a decade is, frankly, unconscionable.

I wish I could say that the happy campers of the HTML WG are willing to at least enter into an open and unbiased discussion on the proposal, but I stopped believing in fairy tales, a long time ago. There is contention on this issue (namespaces for distributed extensibility), as noted in the past, in the current discussion, in the HTML WG bug database, related to the new RDFa-in-HTML proposal. Needless to say, the WhatWG members have responded in their typical, open and mature manner.

But here’s some cold, hard reality for Ian et al: this isn’t a proposal from folks like me, who have little say, and no power. This proposal comes from Microsoft. Microsoft, who still maintains a dominant position when it comes to browser use in the world. The HTML5 editor cannot simply ignore the proposal, pretend he doesn’t understand it, or rubber stamp it WONTFIX. Not this time.

SVGWeb and the XML Issue

I’ve been playing around with SVGWeb, liking the library more over time. I re-created the SVG in HTML5 example, and at first it didn’t work. I thought it could be because SVGWeb couldn’t manage the metadata element, but when I loaded the page in Firefox, with Firebug, I found that the SVG/XML still had the bugs I inserted to test whether the Firefox nightly would correct the HTML-enabled errors—the example still had an unquoted attribute, and elements with missing tag ends. In fact, I got XML error messages within the Firebug console exactly I would expect such errors if I loaded the SVG directly in the browser.

SVGWeb manages SVG for browsers that can handle SVG by creating an XML document of the SVG. You can tell, because if you click the circle with the new example, all of the namespaces for the RDF/XML elements are handled properly, even though the page is parsed as HTML. To me, this is the way SVG should be handled in a document, whether the document is parsed as HTML or as XHTML. This pretense that SVG is not XML when its in HTML is patently absurd. It doesn’t map to anything that exists in the real world.

The SVGWeb library is a wonderful tool, but I would really prefer all that functionality be embedded directly in the browser handling of SVG in HTML. I read the past discussions on SVG in HTML, about how trying to maintain the XML nature of SVG within HTML would require “exceptional parsing rules”, or something of that nature. It seems, though, that SVGWeb is managing the issue just fine, and doing so without having to make one change to any parser for any browser. SVGWeb works by generating a SVG document and inserting the document into the DOM (if the browser supports SVG). Technically, this is little different than what happens for inline SVG in XHTML now. So why is this a perfectly acceptable approach when using script, but not acceptable when not using script?

I’m also aware of the discussions about mixing content, such as SVG in MathML, and MathML in SVG, and HTML5 in both. I made another copy of the example, this time inserting an HTML5 paragraph element into the SVG. Since the syntax I used was proper XML (no unquoted attributes, closing paragraph), it parsed without an error, but the paragraph didn’t display. Of course not, because there is no paragraph element within SVG, and the SVG is treated as an SVG document, not an SVG in HTML document. The thing is, though: the paragraph wouldn’t do anything in SVG within an XHTML document today.

However, returning to the example I linked earlier, I did insert HTML into the SVG using the SVG foreignObject element, with proper syntax, and as you can see, the HTML does display correctly. In fact, if you scroll down, I also created a second SVG element, this time with MathML as the foreignObject contents, which renders fine in Firefox, and partially everywhere else, depending on MathML support.

All of this works, and works well, when using SVGWeb. You can even access namespaced Rdf/XML elements in the XML, using the proper namespace functionality, but the page still validate using Validator.nu. All of the portentous grumblings about the horrors of mixing HTML and XML just don’t ring as ominously when one can see that, contrary to the dire warnings, and tales of potential woe, the two can mix. Unfortunately, the only way to mix the two, now, is to be dependent on a Google JavaScript library. Don’t get me wrong: I’m grateful for the library. So grateful, in fact, that I don’t recommend the use of SVG inline with HTML unless you use this library.

I just don’t like being dependent on JavaScript for that which should be and can be, natively supported in a browser. This approach requires library intercession for all instances of SVG use, which means the SVG markup won’t be accessible to server-side applications that disregard the script element. This JavaScript dependency also means the SVG won’t be visible if scripting is disabled, even though SVG does not require scripting support. When scripting is enabled, the approach is still inherently inaccessible.

These are the two choices facing us with SVG in HTML: SVG/XML treated as HTML, and all the problems this causes; or SVG/XML treated as XML, but requiring JavaScript.


I’m writing an article on using SVG for site decoration and backgrounds. Since SVG is now allowed in HTML via HTML5, it seemed a good time to introduce people to the concept. Especially since the nightly build of Firefox 3.7 has a configuration option (“about:configure”) where you can enable HTML5.

To test the new option in the Firefox nightly, I created a simple file, with a SVG red circle that can be resized with JavaScript. (HTML5 version and XHTML version).

Clicking on the circle will resize it, but also throws up some alerts outputting information about metadata in the element, including namespace, prefix, and element tag name. I wanted to see how Firefox parsed the SVG via HTML, as compared to XHTML. After all, it’s not unusual for SVG files to have namespaced entities in them, for metadata (Creative Commons RDF/XML), or even placed by a tool (Inkscape).

The results are about what I expected. The namespace, prefix, and tag element name all displayed according to their namespace goodness in XHTML, but the namespace didn’t work with the HTML parsing.

To me, this isn’t a showstopper. People who have been working with the DOM and JavaScript have had to deal with differences through the years, such as event handling differences between IE and the rest of the browser world. You just check to see MIME type of page, and either expect to look for the localname as a mashup between prefix and local name, or it’s handled properly.

It’s a little *challenging because prefixes aren’t always going to be the same. However, for the most part, if you need to access the data, you can either control the prefix used, or you can work through the differences without having to resort to rocket science. I rather expect both Dojo and jQuery to incorporate this functionality, once HTML5 gets wider use.

I also have been trying the new SVGWeb product from Google, and fine folks like Brad Neuberg, which enables SVG in HTML for all browsers, including IE. It does this by incorporating a JavaScript library that implements most of the SVG in Flash. Since Flash is pretty much ubiquitous, folks won’t have to install something new for the page to work.

I’ve used SVGWeb to manage the background image for The SVG Feed, which is now formatted as HTML5, and served as HTML. It works nicely in Safari, Opera, Firefox, and even SVG-challenged Chrome, but IE has a problem. Unfortunately, height and width are handled differently with IE as compared to the other browsers, so the values are coming up null in IE. However, Brad has added this as a bug, and I expect this page will work in the next iteration of the product.

Now, there are some differences between SVG parsed by an HTML5-enabled browser, and using SVGWeb. My earlier example embedded SVG directly in the page, but SVGWeb expects an inline SVG element to be enclosed in a script tag:

<script script type="image/svg+xml">

Embedded SVG in a script tag won’t work if you’re only dependent on HTML5 parsers. However, SVGWeb also works with HTML5 parsers, so you’re set, either way.

Until all browsers support SVG, in HTML or XHTML, SVGWeb provides the first real breakthrough in using SVG on the web. And here you thought that SVG was only good for **Scrapbooking.

*It’s a little more challenging for server-side applications parsing the web page, but again, the differences aren’t insurmountable.

**The background SVG I’m using for my site originated as a scrapbook pattern for the cutting machine, Cricut.