• Related to examples in my various books
  • CSS
    Cascading Style Sheets
  • Figures for the book, Painting the Web
  • Notes and corrections from my various books
  • Related to GIMP and associated products, such as gimp-gap and UFRaw
  • Related to ImageMagick and related programming APIs
  • Related to photography, and photography tools
  • SVG
    Examples using SVG
  • The browsers and web graphics
  • Tools and technology related to web graphics

Writings about Web Graphics

  • 06/06/2010 - 11:57
    SVG

    Web Directions has created a No Bit, Sherlock developer challenge, with nice prizes such as a laptop and XBox for the person or persons who comes up with the most creative variation of SVG progress element. A nice play on the name ("no bit"), but even nicer prizes.

    I'm not participating in the contest, but couldn't resist playing with the idea of creating progress elements with SVG.

    One type of progress element is the indeterminate progress, also called a throbber. If you use Twitter, it's equivalent to the circling animated graphic, and indicates that an event is happening, but the web site can't determine the exact progress of the event.

    When I think of an unending event, I always imagine ouroboros, the serpent swallowing its own tail, and creating an infinite seeming circle. It can represent many things in many different cultures but, to me, represents a continuous cycle with no beginning, middle, or end. It just is, until it is no more.

    With that in mind, I thought I would try my hand at creating an ouroboros indeterminate progress element. Luckily for me, I didn't have to stretch my rather limited graphic skills in order to create the ouroboros: Wikipedia provides an elegant graphic, already formatted as SVG (PNG format), and with a license that allows me to use the graphic for my own work.

    My first indeterminate progress element plays on the cyclical nature of ouroboros, by rotating the graphic around its origin, as you can see in the following example if your browser supports SVG. Clicking the start button begins the animation; clicking the end button, stops it. The application makes use of the built-in transformational capability of SVG.

    It's an interesting effect, but a little CPU intensive. In addition, there's nothing uniquely SVG about the effect. I could have just as easily grabbed the PNG formatted graphic and used the new CSS3 transform attributes to rotate the image. I wanted something that plays on the uniqueness of SVG—that non-bit nature of SVG that forms part of the title of the Web Directions contest.

    SVG is a vector graphics language, which means that a graphic consists of various elements, all combined into a whole. The ouroborus I used is actually made up of several path elements, forming the head, the eye, and the different scales along the body.

    What if, instead of cycling the entire serpent graphic, I just cycle an effect around the serpent? A popular Ajax-based throbber is the one that Twitter uses, and consists of a animated dashed circle, where the dashes around the circle are hidden and displayed using a circular motion.

    I applied the Ajax style throbber effect to my ouroborus graphic to create my next effort, as shown below. In this case, the serpent remains static, and only the scales change color, in a circular motion, to indicate some action is taking place.

    I prefer the second approach, and it's less CPU intensive than using a rotating graphic. You can also play with the colors: just make sure there's enough contrast between "inactive" scale and active one so that the circular effect is easily seen.

    Of course, both of these designs are for an indeterminate progress graphic. What about a deterministic one, where there is a beginning, middle, and end?

    Even though I was inspired to use ouroboros because of the cyclical nature of the graphic, I'm also using SVG, which I've always felt to be synonymous with limitless possibilities. Ouroboros also means complementary opposites and what is more complementary, and opposite, than an event that's not started, and an event that's completely finished?

    I made a third progress animation, but this time, there is a beginning, middle, and end. As whatever task progresses, my serpent's scales turn from gray to black. In order to ensure that my application user knows what's happening, I also provide a text description of the progress.

    One last change for all of the graphics: ensuring they're accessible.

    All three graphics are given a role of progressbar. All three would also normally be associated with the task using other ARIA attributes. In addition, since the third application is a deterministic progress graphic, I also set the aria-valuemin, aria-valuemax, and aria-valuenow attributes on the SVG element. (I could have also set these values on the g element that groups the graphic within the SVG.)

    If you load the graphic within Firefox using the NVDA open source screenreader, you'll not only "see" the progress, you'll also be able to hear the progress. And though these variations are a fixed size for demonstration purposes, they can be easily scaled as small or as large as you want, because I'm using SVG.

    A fun little challenge. I'm looking forward to seeing the Web Directions "No Bit, Sherlock" contest entries.

  • 10/02/2009 - 10:06
    SVG

    Celebrating SVG

    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.

  • 10/01/2009 - 08:10
    SVG

    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 willingly 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 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 typically, 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.

  • 09/12/2009 - 12:07
    SVG

    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 support 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 with 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.

  • 09/11/2009 - 13:29
    SVG

    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".