Categories
Technology

Tech: A Welcome Respite

It’s long past time for me to return to technical writing, if only because I need a respite from the battle against Trump and his evil minions.

It helps that there is a lot to be excited about—in a good way—in the tech world. The Node community seems to be moving beyond its early growing pains and is starting to stabilize. There’s still occasional drama, but not enough to make you scream in horror and run away.

My beloved SVG is really coming into its own with widespread support. I’ve been waiting years for this. There are great libraries to make it easier to build applications, but for me, the holdup has always been browser support. Now, I can party.

CSS! Can you believe what you can do with CSS now?  Not to mention that the W3C has really its act together when it comes to documenting what’s happening with specs.

Speaking of specs…HTML is no longer held hostage by a tin-plated dictator.  I’m sorry, did I say that out loud? I did notice that the working group mailing list is extremely quiet nowadays. This is because all the action has moved to GitHub. Probably more efficient. Not as fun.

Excellent news about the W3C and IDPF merging their efforts.

The vision to align Publishing and Web technologies and create a new roadmap for the future of publishing became official today with the announcement that the World Wide Web Consortium (W3C) and the International Digital Publishing Forum (IDPF) have combined organizations.

 

Categories
HTML5 Specs SVG

This page isn’t valid…and who cares

I covered my recent experiments in using SVG in HTML in SVG in HTML. I linked two different example pages with SVG inline in HTML: one dependent on HTML5 parsing (Firefox nightly), the other using the library, SVGWeb.

There’s another difference between the two examples other than just their implementation. The first example, dependent on a browser parsing the page as HTML5, doesn’t validate. The example using SVGWeb, does. Yet, both pages display correctly, as long as you use an HTML5 enabled browser for the first. The odder thing is, neither page is “invalid”.

The HTML markup is fine for both, as is the SVG used. However, the Validator doesn’t like inline SVG at this time, because, we’re told, no browser implements SVG inline in HTML, yet. The SVGWeb example validates because the SVG is contained in a script block. The validation problems with the first example go beyond embedding the SVG element directly in the web page, though. The example also incorporates a metadata element in the SVG that contains RDF/XML.

Embedding RDF/XML into the metadata element is perfectly valid with SVG, and in fact, quite common when people attach Creative Commons licenses to their work. The HTML5 Validator, though, doesn’t really know what to do with this RDF/XML. Why? Because RDF/XML uses namespaced elements, and namespaced elements are taboo in HTML. Yet, SVG is acceptable in HTML5.

Herein we discover the paradox that is HTML5: XML allowed in HTML, but parsed as HTML; extensible namespaced elements that are valid in SVG/XML, becoming invalid when embedded in the non-extensible environment that is HTML5. HTML5 as XHTML likes namespaces. HTML5 as HTML does not like namespaces. But HTML5, as both XHTML and HTML likes SVG, and SVG likes namespaces.

Pictorially, the logic of this looks about as follows (which would not be valid if inserted into an HTML5 HTML document):

Ouroborous

Oh, what is a web designer/developer to do, who just wants to use a little SVG here and there? Enter, stage left, the HTML5 Doctor.

Recently the HTML5 Doctor was asked about attributes and elements from HTML4 that are now obsolete but conforming (or not) in HTML5. Won’t adding a HTML5 DOCTYPE while still using these elements cause the pages to be invalid?

The Doctor’s answer:

While validation is undoubtedly important for your markup and your CSS, in my opinion it isn’t crucial to a site. Allow me to explain, we recently received a couple of emails pointing out that this site doesn’t validate. While there were some errors that have now been corrected, a primary reason why is the use of ARIA roles in the markup. These attributes currently aren’t allowed in the current specification, however there is work underway to make this happen.

To illustrate this point let’s look at Google, the search giant. If you look at the source on Google’s search pages you’ll see they use the HTML 5 doctype.

<!DOCTYPE html>

However, those pages don’t validate because they use the font and center elements amongst others things that we already know have been removed from the specification. Does this mean that users stop visiting Google? No.

Remember too that the specification is yet to be finalised and may still be changed (thus breaking you’re perfectly valid docments), in partnership with this changes to the specification may not immediately take be implemented in the validators. We also need to bear in mind that HTML 5 takes a “pave the cowpaths” approach to development, meaning that the Hixie, et al will look at what authors already do and improve upon it.

The days of validation being an end all, be all, are effectively over with HTML5. By obsoleting (not deprecating) elements that were perfectly valid in HTML4; by not providing an extensibility path within HTML in HTML5, especially considering that new elements will arise over time—not to mention, the inclusion of perfectly legitimate namespaces elements in SVG— all, combined make “validation” a goal, but not an end when it comes to the web pages of the future. We’re more likely to define a set of supported browsers and user agents and worry more about the pages working with these, then be concerned about whether the pages validate in Validator.nu.

So, my one web page with the inline SVG works with the Firefox nightly, with HTML5 parsing enabled. It isn’t valid…but who cares?

Categories
SVG

SVG in HTML

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.

Categories
SVG

SVG doesn’t need to compete and neither do I

The worst mistake I made in the recent discussions about open compared to proprietary technologies was to allow myself to be pulled in by sweeping statements such as, “the W3C has failed”. Not only be pulled in, but to get into some form of competition over which is the best: SVG/Ajax, Silverlight, or Flash.

The W3C has failed because Rich Internet Applications are the way of the future, or so goes the prescient among the pundits. Standards are dead, said others. Silverlight is the future. No, no, make that Flash. Silverlight! Flash! And on it goes, with poor SVG dragged along like the cousin who showed up at the dance without a date.

At the same time I waded into the battle of the—well, we really can’t call it vector graphics, as there is so much more involved— I also wrote about IE6 and the difficulty of ending the life of this seven-year-old browser. A seven-year-old browser that still dominates so much of the web. Person after person told me about this place or that with umpteen thousands of employees all using IE6. Someday, I’m told, we’ll signal the EOL of IE6, but not today. Not today.

These are two different views of the world, neither of which is compatible with the other. Either the world is ready to leave the W3C and other web standards organizations in the dust as we leap into the bright future where all the web is a box embedded in a single page with a big friggen cloud behind it, or we’re living on the edge just using transparent PNGs.

The Hard Rock Cafe website is fun, but it doesn’t work on my pre-Intel Mac, nor with Opera, and crashed my Safari on Windows XP and caused my not low-end laptop to spike at 80%…when idle. But it is pretty and is cool, and makes use of new JPEG compression techniques that are very cool, and we need pretty and cool, just to keep excited about all this stuff.

However, the world will still turn, every day and every night, to Google Maps, created with technologies in use today— standard and proprietary technologies, both—and now so much a part of our lives that we’ve forgotten when we considered it cool.

Years ago, one group of companies proposed one way of doing 2D vector graphics, and another proposed a different way and from the clash came SVG. However, Microsoft did its own thing, and implemented VML, and created what is probably the last battleground in the war of the browsers. I don’t know why Microsoft went with VML. I imagine one reason is that Microsoft was not willing, then and now, to commit to the necessity of XHTML. Either that or the company was being purblind, pig-headed stubborn. Either way, Microsoft went one way, everyone else went another, and now we’re left with no meeting ground between two positions. To say the situation is disappointing is to say that the Midwest got a touch wet this spring.

Maybe HTML5 will be the bridge that brings the sides together. I hope so, but that’s in the future and we have to think of the now. The now that celebrates the latest whizzy from Microsoft and Adobe, while having to continue to support IE6. The now that needs the standards, even when most of the people don’t realize how much they need them. And OK, the now that needs Silverlight, and Flash, and whatever else new comes along, because that’s what the web is, has been, and probably will always be.

I’ve always said we need more women in technology because I believe we women bring balance to technology. I like to think that we foster cooperation, rather than competition, but perhaps that’s my own bias, or even my own stereotype, shame on me. However, I didn’t bring any cooperation to this discussion. I was right in there with the boys: snorting, stomping, and digging my feet into the dirt, as I rolled up metaphorical sleeves and prepared to wade in with code. Of course, it was little bitty code, and all I managed to really do was look a little silly. Worse though, is I looked silly at the same time I was saying stuff that was anything but. I guess that makes me a real tech because I can be just as purblind, pig-headed stubborn as every other tech I’ve ever met. Stubborn and with code—that’s a dangerous combination.

I like SVG. I like SVG for itself. I like that you can add 2d graphics directly into a web page; that you can use JavaScript to manipulate the SVG after the page loads—not to mention the really fun declarative animations. I like that it is interactive. I like that it’s free, and that it’s open; that it belongs to all of us. Most importantly, I value that it’s built into the browser, not added via a plug-in, and I can depend on it being there. Well, mostly there. I have many more fun things I want to try with SVG (and the Canvas object and JavaScript and CSS)—even if it means I’ll be putting the results of my efforts on a four-legged stool with one leg missing.

I like SVG, but SVG is not Flash. SVG is not Silverlight. However, that doesn’t make SVG better or worse than Flash or Silverlight—it just makes SVG different. And that’s where my time should go: celebrating the difference, not trying to trip the other guy up, so I can kick dirt in his face when he’s on the ground.

Enough rambling, back to the book.