Burningbird
Wordle Image of RealTech front page, captured using Skitch and saved as PNG.
PNG file opened in Inkscape, and Trace Bitmap applied. Bitmap options: Multiple Scans, Colors, 5 Scans, with options to stack the scans, and remove background.
SVG finished by running Scour, saving 52.1% of the SVG file size. SVG made cross-browser friendly, via SVGWeb.
Cynthia Shelly released an alternative proposed HTML5 draft that addresses the table summary attribute. The responses to her draft have been less than edifying, and demonstrate rather succinctly most things wrong with the HTML WG.
If you follow along in the thread, you’ll see Apple’s Maciej and IBM’s Sam Ruby go back and forth on protocol, a discussion Maciej ends with a suggestion to focus on salvaging a “proposal” from the work. The thing is, providing alternative text in a specification is the proposal, the only that is deemed acceptable to the HTML WG. At least, that’s what we’ve been told in the past.
Not that Cynthia is demanding that the text be used as is. This was a suggested text, addressing how summary could be discussed in the HTML5 specification, in order to ensure proper use. The proposal also removes summary from the obsolete list. Cynthia proposed this alternative text in order to generate discussion, leading to its refinement; to encourage team effort. Simple enough to understand, but then we’re subjected to the typical Ian Hickson disingenuous approach to anything he disagrees with: pretend he doesn’t understand what the proposal is all about.
I couldn’t find any description of what problem this proposal is trying to solve. Could you point me to the description of the issue that is being resolved here? Why is the text currently in the HTML5 spec not considered acceptable middle ground?
It is difficult to evaluate proposals without understanding what problems they are trying to solve.
Incidentally, I believe the process that we are supposed to be following these days is that when there is a problem in the spec, a bug should be filed describing the problem, so that the issue can be tracked. If you could file a bug (or point me to the relevant bug if one is already filed), that would be very helpful.
(At this point I would like to inform my readers: everyone can file a bug, you don’t have to be a member of any W3C organization to do so.)
So, HTML WG team members are told by one of the HTML WG Chairs to provide alternative specification text, while the HTML5 author countermands such a recommendation, with a note that we file bugs, instead. Seriously, I keep expecting the third stooge to enter the scene, stage left.
And he does. The author of validator.nu, worker extraordinaire for Mozilla, Henri Sivonen, puts on his court jester cap to derail even the potential for worthwhile discussion:
Further quotes are from the proposed text--not from Maciej: > Summary is one way to provide explanatory information about tables > that consist of more than just a grid of cells with headers in the > first row and headers in the first column. > Does this intend to say that using @summary is categorically unnecessary when headers appear in the first column and/or first row? If so, it would be good to make this clear. > Such explanatory information should introduce the purpose of the > table, > Shouldn't the purpose be stated to all readers? > outline its basic cell structure, > Shouldn't this be generated by the AT from the table model? > The information provided by the summary is needed by users who > cannot see the table, but would usually be redundant for those who > can. > This sentence sticks out as non-spec-like. It doesn't state a requirement, so it looks odd in the middle of a paragraph that states requirements. > This must be done in a way that is associated with the table via > markup, such that user agents and assistive technology can > programmatically determine the relationship. > This sentence could make sense in WCAG-like contexts where things are defined in terms of what available software happens to support. It doesn't make sense in a spec that defines what software must support. (Furthermore, "programmatically determine" is a special term from other specs but isn't defined as part of the special vocabulary of the HTML5 spec.) The proposed text seems to imply (in the edits done on examples) that having the explanation in a paragraph preceding the table isn't sufficient without an explicit aria-describedby link (misspelled in the proposed text as aria-described-by). Why is that not sufficient? > When using summary in combination with another technique, authors > must not use the duplicate text, but instead use summary for the > parts of the description that are only useful to users who cannot > see the table. > What about duplicating information that AT should be able to voice based on the table model? > <table summary="The table is divided into six columns: Map number, > Date, Area or stream with flooding, Reported deaths, Approximate > costs (uninflated), and Comments. The rows are grouped by flood > types into six subcategories: Regional flood, Flash flood, Ice-jam > flood, Storm-surge flood, Dam-failure flood and Mudflow flood." > In this case, the first sentence clearly duplicates information that are trivially programmatically determinable by the AT from the table model (given proper <th> markup). As for the second sentence, I think it would be worth investigating if the salient content of the second sentence is also realistically programmatically determinable from the table model. On the face of it, discovering the content of the second sentence from the table model doesn't seem like an overly hard software problem.
So, the text of the proposal that Cynthia provides is addressed to humans, which Henri rejects, because Cynthia’s text should be addressed to machines. She discusses declarative markup, and addresses this discussion to people, in order to ensure that the summary attribute is properly used by web page authors and designers. Henri reduces the whole to algorithms, care and feeding of.
This is a perfect lead in to another discussion about HTML5 taking place elsewhere, in the W3C TAG, which has ultimate responsibility for ensuring the many specifications such as HTML5 work in a complementary manner for the web. The focus of the TAG at this time is detailing issues this group has with the current HTML5 draft, a discussion generating a typically mature level of discussion in the WhatWG IRC channel.
One such issue, as I have noted, as others have noted, is the fact that the specification is given in algorithmic terms, rather than as declarative text—based on discussions of a Document Object Model (DOM) with HTML markup given as a distant secondary item (barely covered, and leaving ripples of confusion in its wake).
The current rendering of the specification is considered more precise for the browser companies, for Mozilla, Google, Microsoft, Opera, and Apple, but the precision completely obfuscates the information needed by thousands, perhaps millions of web page authors and designers.
In the past, the main specification would be about the markup, with a secondary document describing the DOM. And oddly enough, this has worked, if we can believe the evidence of our eyes. Evidently, this wasn’t to the taste of the browser companies, who believe that it is more important that their needs be met, rather than the needs of the thousands, perhaps millions of web page authors and designers.
In addition, rather than leave many decisions up to the implementors of the specification, the editor’s draft seeks to detail, in minute detail, how everything is to be handled by implementors. Precise, very precise. Good luck with the 50,000 or so test cases.
So far, I have submitted three HTML5 bugs:
And I just submitted a bug for table summary. There will be others. Too bad I’m not one of the elite.
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"> <svg... </script>
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.
I’m usually good about reminding (nee nagging) my friends about updating their WordPress weblogs, but in case any of you missed the last upgrade, there’s a good chance your weblog may have been seriously compromised. Lorelle covers the exploit and how you can tell if your site has been compromised.
From other discussions, I gather that if your site has been compromised, it’s going to be a mess to try to fix the problem, because the hacked software is now a part of the database, so exporting your data and re-building won’t help.
It’s not unusual for CMS to develop security problems that need fixing, but I am a little surprised that there’s been no official statement from the WordPress folks and the parent company, Automattic about this issue. Regardless of notification, it’s really important to always update your sites when security releases are issued, no matter what software you use. When I get an update notice for my Drupal sites, I update immediately. If updating is too much of a hassle, or you’re intimidated by the process, then you need to hire someone to help you with upgrades, go with a hosted solution, or change your software.
update Robert Scoble’s site was one that was hacked. There’s an interesting discussion on this at FriendFeed though how long that link will be viable, is hard to say.
I found it disingenuous of Matt Mullenweg to blame Rackspace for the problem Scoble had because of the WordPress exploit. Having said that, security updates rarely impact on plug-ins, and if a plug-in is broken, disable it and do the security update, anyway. I don’t know of any module in Drupal, outside of core, that I am so dependent on that I can’t upgrade Drupal based on a security release. But then, the modularization architecture with Drupal is different than that for WordPress.
As for Scoble, I feel for him, but he’s got plenty of free support. I feel worse for the folks who have to go it alone when trying to fix their sites. Hopefully some of the new articles on this story will provide the help you need, including one just released by Matt at WordPress. I’d offer to help, but I don’t run WordPress now, and I’m becoming less familiar with the tool with each new release. Still, if you’re desperate, holler, and I’ll see what I can do.