Menu

ComicsML: A Simple Markup Language for Comics

April 18, 2001

Jason McIntosh

Introduction

I like comics. I like the Web. I like comics on the Web. But I could like them a lot more, especially if more of them would realize they're not on paper, taking advantage of their electronic format and globally-linked positions. So I propose a simple XML-based markup language which, I believe, could help digital comics assert their value as online resources and as art forms.

Colliding XML and Comics

Not too long ago, I started a job that required me to learn XML, the "Tupperware of the Internet", as a coworker calls it . People have created XML-based languages for everything from technical documentation to mathematical notation to spelunking.

At about the same time, I read Scott McCloud's Reinventing Comics, which is basically a call to arms to revolutionize comics by capitalizing on the largely untapped power that the Internet can offer this art form. A long-time comics fan, occasional comics creator, and student of Marshall McLuhan, I found myself wholly taken in by McCloud's arguments that the many comics now available on the Web represent a good first step, but few if any of them manage to take advantage of their new location, being presented as if they were still on paper. What we need now, McCloud argues, is new ideas for presenting comics digitally, which will inevitably emerge from many directions; but we'll also need new technologies to make digital delivery easier.

So I thought I would try to combine XML with online comics to see what would happen. I began to toy with the notion before I could think of good reasons why anyone would want to use such a thing, but, thankfully, I eventually came up with some of those, too, and I'll get to them after I describe how this thing works.

The ComicsML Language

Like any other XML language, the kernel of ComicsML is its DTD, which I've tried to keep relatively simple. Experienced DTD users may note its similarity to RSS, and there's good reason for that, which I'll explain below. Much of the rest is inspired by John Bosak's play.dtd, which he wrote so he could mark up the complete works of Shakespeare.

ComicML's atomic element is the panel, which is inspired by the McCloud/Eisner reading of comics as being an art form based around the magic that occurs when images appear in a juxtaposed sequence. Comics artists most often use individual panels as their images, and so that's the word I picked for my core element. These panel elements hold all the information about a comic's words and pictures, and panels are bundled together into elements called strips, which in turn can live in the DTD's root element, comic.

The use of multiple levels was also inspired by RSS. The comic element contains various bits of static metadata about the comic in question, including name, a list of its artists, or a clever tagline. Each strip represents a separate instance of that comic, the meat of which is held within panel. Pretty simple.

Each panel may hold elements that describe what's going on, with special attention given to the characters' words and actions. I included rudimentary (and optional) text markup so one could precisely markup the shape of the text, and I treated word balloons similarly. It's fine to use the default speech element for everything, but you can stick attributes in to follow along with the balloons' various shapes. Please see the DTD for a complete listing of all the different flavors of speech, thought, and narration I've included. I can't account for everything a comics artist can pull off, of course, but I did try to cover the major, conventional visual idioms that have developed in Western comics over the last century.

Examples

I have made a complete and very chatty example ComicsML document that attempts to illustrate a few interesting things about ComicsML. I want to excerpt some of it here for sake of discussion.

Let's start with an actual comic strip (drawn by me in 1999):

I'll mark this one strip up in a very simple fashion, sharing only some metadata about it, without digging very much into its actual content.


  <strip id="disbroken-10-2">

    <date>2000-01-01</date>

    <title>Creation Myths</title>

    <url>http://disbroken.jmac.org/archive/?stripno=10</url>

    <teaser>

      <description>Burt scoffs at Martha's kitchen cosmology.</description>

      <panels>

        <panel><url>http://www.jmac.org/xml/dcs-xml/panel1.gif</url></panel>

        <!-- Actually, I just might want to use a <panel-desc> element

        here for accessibility reasons, but I'll skip it for now. -->

      </panels>

    </teaser>

  </strip>

This shows only part of ComicsML, but for most comics, it's probably enough; it could even be autogenerated without much human input. That's why I made so much of ComicsML optional; even if you do only a little extra work, you can still get a lot of its benefits.

That being said, let's now pull out all the stops and revisit this strip, this time using panel elements to painstakingly describe each part of the comic:


  <strip id="disbroken-10">

    <date>2000-01-01</date>

    <title>Creation Myths</title>

    <panels>

      <panel>

        <url>http://www.jmac.org/xml/dcs-xml/panel1.gif</url>

        <panel-desc>

          <action>Martha, holding a knife and a fork, peers at an

              empty plate.</action> 

          

          <narration>Father Fork and Mother Knife looked down upon

              the Plate of the World, and saw that it was

              empty.</narration>

        </panel-desc>

      </panel>

      <panel>

        <url>http://www.jmac.org/xml/dcs-xml/panel2.gif</url>

        <panel-desc>

          <action>Martha, smiling serenely, places a slice of

              bread upon the plate.</action> 



          <narration>And so it came to pass that Father Fork said,

              "Let us put Bread upon the Plate, and give it Form. And

              so they did, and they smiled.</narration>

          <narration>But, ah! The Bread lay still on the Plate,

              itself empty, without Purpose. So Mother Knife said,

              "Let us call upon our Sister, Jar-of-Mayonaise

              and--</narration>

        </panel-desc>



      </panel>

      <panel>

        <url>http://www.jmac.org/xml/dcs-xml/panel3.gif</url>

        <panel-desc>

          <action>Burt interrupts Martha, brandishing a sandwich

              at her. Martha looks confused.</action>

          <speech>

            <character>Burt</character>

            <text><strong>Pagh!</strong>Again, I have completed

                construction of my chicken sandwich in half the time

                as you. Your "Kitchen Creation Myths" remain

                unconstructive drivel!</text>

          </speech>

        </panel-desc>

      </panel>

      <panel>

        <url>http://www.jmac.org/xml/dcs-xml/panel4.gif</url>

        <panel-desc>

          <action>Martha, a wild look in her eye, suddenly

              ripostes with her mayonaise-covered butterknife,

              disarming Burt, who drops his sandwich.</action>

          <speech>

            <character>Martha</character>

            <text><strong>Oh?</strong>And what do you

                tell<emphasis>your</emphasis> lunch, when it

                asks?</text>

          </speech>

          <speech>

            <character>Burt</character>

            <text><soft>Um...</soft></text>

          </speech>

          <speech>

            <character>Martha</character>

            <text><soft>I thought so.</soft></text>

          </speech>

        </panel-desc>

      </panel>

    </panels>

  </strip>

No matter the level of detail you choose, what you'll end up with after you're done markup up your comic is XML describing a collection of comic panels.

No Layout Here

ComicsML has no concept of layout. It knows that each strip has a bunch of panels in it, but it makes no presumptions about how to present them, beyond the order in which the reader is to see them. If a comic that makes use of ComicsML chooses to add URLs for all its panel images, then an application will not know how to display them without further information from another source, and will instead use its own methods for displaying the panels one after the other.

For the majority of comics, whose panel layout is simply a matter of convenience, this shouldn't pose a hardship. It might become less than ideal for comics that use full-page layouts, where panel positioning can often be an art in itself, and the model might break down for those very rare comics which use panels in ways integral to their very meaning. However, I suspect that most members of the former group could probably survive the application panel-description markup with no pain.

The first draft of the ComicsML DTD actually did have some elements for performing rudimentary layout modeled after HTML's table elements, but I decided to ditch that, preferring to make ComicsML all about content. If you have a different view, please let me know using the form on the last page.

Reasons to use ComicsML

There are several reasons why comics with a standard markup language applied to them could be cool.

Syndication

When I first started thinking about ComicsML, I had in mind the very successful XML syndication application known as RSS, Netscape's Rich Site Summary format. Thousands of web sites, including news sites, weblogs, and other sites whose content changes rapidly, publish a special version of their latest material as an XML page in compliance with the RSS document definition, allowing web applications to swoop in and collect the site's latest headlines without knowing anything else about the site -- in other words, it doesn't have to know where the site keeps its normal, human-readable headlines, or how to parse the HTML once it gets there, since the RSS page uses the same standard elements as every other RSS page in the world.

RSS gives web publishers an easy way to invite automated entities to grab pointers to their latest information. This little bit of extra work can pay off immensely for the site, as now people visiting web sites that collect and display a user-configurable collection of content from these many RSS 'channels' -- like my.netscape.com or (my favorite) Meerkat -- can effectively surf several sites simultaneously, paying one an actual visit when an item of interest pops up on its channel.

This is the heart of web syndication: sites agreeing to share a little bit of their content with other sites, which are free to do with it what they will, but it's presented so that each clump of content ties back into its origin. RSS has changed my surfing habits so that nearly every site I regularly visit now I hit by way of Meerkat, where once I would randomly bop around my bookmarks every so often, seeing if anything new and interesting was immediately obvious on various sites, a far less efficient or fun method.

I think a similar model might be able to work with online comics.

The reader's perspective

I don't read a lot of online comics, and I can tell you at least part of the reason: I am far, far too lazy to hunt them down. One could argue that this isn't too hard to overcome with a standard browser: just bookmark all these sites and, once a day, visit them all in order.

But many fine online comics come out less often or (like mine) on an entirely irregular basis. Nothing's stopping me from still hitting them every day if I wanted to, but I probably won't, because I'll feel like I'm wasting time.

The creator's perspective

There are many more comics available online than there are in your favorite newspaper, more even than there are of all the different comic strips published in all newspapers by every print comics syndicate. Getting a syndicate's attention is hard. Being a talented artist with an intelligent and sustainable idea for a regular comic isn't enough; one also needs a great deal of timing and raw, dumb luck to make one's pitch exactly when the syndicate is looking for a particular niche to fill. The number of new comics accepted by an average syndicate in a given year can usually be counted on one hand.

It may be a little easier for a talented creator to get into comic books, since their editors -- at least with smaller, less superhero-centric publishers -- tend to look more for creativity than pure mass-market appeal. But there's a reason for that: the audience for comic books is much, much smaller, often dwindling down into single-digit thousands where newspapers have a potential for millions.

So the Web provides a great opportunity for the comics creator to reach millions of people.

The Web perspective

If there were enough online comics using a standard markup language, then aggregators could regularly snarf up information about them, just like RSS aggregators do, and web applications would summarize what's new in the world of (XML-clueful) comics without anyone anywhere doing (much) extra work. The contents wouldn't have to be the comics themselves, and many comics artists might prefer if people still had to visit their site in order to see the full thing. That's OK, and it's why I put the teaser element in place. In any case, though, users still get informed that this comic has been updated. Syndication is cool.

What if I wanted to use panel-describing elements so that I could add search engines to my comics website? What if I also wanted to syndicate my comics, but didn't want to let these syndication sites also grab all my content? I'd build two separate ComicsML documents. The first, without panel elements, would live at a URL I'd freely share with aggregators, while the other would reside in some private location, so that my own site-building tools could take advantage of them, without the whole Internet peeking in. This might be ideal if I relied on income from advertising, micropayments, or merchandise sales.

Some intermediate solutions already exist which partially address these same issues. Lots of people have written Perl programs that sneak off to their favorite comic web sites and download the most recent image from each, but this means playing the tired old game of accounting for every site's unique HTML style, which is a hassle to create and a burden to maintain. Other sites try to be something like web comic portals, but take extensive human input to maintain properly.

Searchable Archives

Just about every comic with a web presence has an archive collecting older strips. As these often stretch back to their first issue, archives of older strips can be massive. The normal way to read through them is to start at the beginning and step through the comics, one by one. Most comics archives have a ubiquitous suite of first, previous, next, last controls, and not much else. Let's say I wanted to find all Dilberts that mention downsizing. I'd be out of luck. Since all Dilberts are archived solely as images, no software can easily find what I want, and I'm not about to click through years of cartoons to find what I want.

Once again, some web-savvy comics have taken this matter into their own hands. User Friendly's site, for example, has its own search engine to match text queries with appropriate comic strips. This may work well for that one strip, but it sure doesn't scale across the Internet. If I wanted to grab a handful of geeky comics that dealt with some particular topic, perhaps in order to lighten the mood at some presentation, I could only easily find User Friendly comics. On the other hand, if all my favorite comics marked themselves up in a standard way through something like ComicsML, I could use an application to run my query across all their archives, returning with a result list likely comprising many different comics.

This would allow for searches with quite a bit of refinement, as the textual (and hence searchable) information about each strip would already exist in a hierarchy with implied levels of interest to a search engine. Strip titles and captions would probably have the most prominence, followed by dialogue, and then description.

One could also find more abstract information. Returning to the Dilbert example, were I particularly fond of Catbert, I might want to see all comics that have Catbert in them. That might be quite a few, so I could mix search styles to constrain the search, perhaps to all strips where Catbert says the word "outsourcing". Thanks to the descriptive elements that handle characters and dialogue, the software can return a list of relevant matches.

Accessibility

I am not blind and I don't know any blind people, so I don't know what resources may exist to help the visually impaired read comics (beyond what web searches tell me, which doesn't seem like a lot). I feel fairly certain, however, that a blind person can't pick up just any comic book or visit any web comic site they desire and give it a read. I think that sucks. Here is a part of your potential audience who might really enjoy your comics, but can never hope to do so unless they get friends to read and describe it aloud. OCR software might be able to read the text parts of the comic (if they're typed or written very neatly by the cartoonist) but can't describe the visuals that accompany them.

Proper markup could do a lot to help the blind enjoy comics. The W3C, the organization principally responsible for XML's creation and continuing development, has always held web accessibility for all as one of its primary goals. XML is already being used in several accessibility projects. Since the most obvious way to make comics readable to blind computer users involves keeping a text version of the comic as accessible as the comic itself, so that software can locate it and pipe it through a text-to-speech device, it follows that keeping this text in a predictably structured format would let this software quickly pull out the comics' content without any extra parsing.

Additionally, while it's an entirely different sort of accessibility, I'll note that descriptive markup would also let people with any level of sightedness read comics in a text browser like lynx. Perhaps the only Web browser I have to hand at a certain moment is the LCD screen on my cell phone, for example, but I'm stuck in a traffic-bound taxi, and I really want to see what's new with my favorite comics.

Conclusion

In the short time since I first shared a draft of this document with friends and coworkers, I've seen glimmers of wonderful ideas for directions to extend ComicsML that I doubt I would have ever conceived myself, covering everything from cross-referencing to story line management, and lots of folks seem game to try and catch the elusive problem of sanely describing layout. What's more, each of these people seemed to name a different reason why they liked the idea of a comics markup language. Given enough time and testing, I think ComicsML can live up to its name, becoming a method to let digital comics, no matter who produces them, hook into the vast information potential their presence on the Internet offers, while remaining simple enough for any aspiring comics creator to use.

Please contact me if you have feedback or leave comments in the forums at the bottom of this page.

References

  • I've made a separate ComicsML resource page, an index to more information and support for this idea, as I develop or collect it.
  • A draft of the ComicsML DTD available as well as a very chatty example document.
  • The coworker who made the comment about Tupperware has written a very nice book called Learning XML, which I highly recommend. (Look for me in the Acknowledgments section, right above his list of favorite mustards.)
  • Scott McCloud's website has all kinds of good stuff about digital comics (including many excellent examples from his own hand, one hilarious Web-collaborative effort, and lots of links to other groundbreaking work), but his big treatise on the issue is Reinventing Comics.