ComicsML
A proposed simple markup language for online comics
Abstract: 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 started realizing they're not on paper, and took advantage of some of the wonderful mechanisms their electronic format and globally linked position makes available to them. So, I propose a simple XML-based markup language which, I believe, could help digital comics assert their value as an online resource, as well as an art form.
XML + 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 -- an all-purpose information container that has been finding rapid and enthuastic acceptance for all manner of Internet applications. In a nutshell, it's the younger brother of HTML (the markup language that allows the World Wide Web to exist -- the stuff you see when you hit 'View Source' on any web page), but rather than a fixed package of meaningful tags, it's a toolskit for creating one's own markup languages. People have invented XML-based languages for everything from book publishing to mathematical notation to spelunking.
At about the same time, I read Scott McCloud's Reinventing Comics, basically a call to arms to revolutionize comics by capitalizing on all the largely untapped power that the Internet can offer this art form. A longtime comics fan, occasional comics creator, and would-be 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 of this art form into the digital age, but few to none of them manage to take advantage of their new location, acting 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.
That I could try colliding the two to see what happens was an obvious outcome, yes? I began to toy with the notion before I could started trying to 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 Language
Like any other XML-based language, the kernel of ComicsML is its DTD, which I've tried to keep relatively simple. Experienced DTD pokers-at may note its similarity to RSS, and there's good reason for that, which I'll also explain. 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>, taking
after the McCloud/Eisner reading of comics as being, at its core, an
art form based around the magic that occurs when images appear in a
juxtaposed sequence. Most often, comics artists 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 abouta comic's
words and pictures, and panels are bundled together into elements
called <strip>s, which in turn can live multiply in the DTD's
root element, <comic>. (All these other elements' names are
subject to change, I'll point out right now, and I welcome suggestions
for improvment.) The many levels are, again, RSS-inspired: the
comic element contains all manner of static
meta-information about the comic in question, such as its name, a list
of its artists, or a clever tagline. Each strip
represents one separate instance of that comic, the meat of which is
held within panel. Pretty simple, I think.
Each panel may hold elements that describe what's
going on within which special attention given to the characters' words
and actions. I threw in some rudimentary (and completely optional)
text markup so one could make very precise markup that follows the
shape of the text, and treated word balloons similarly; it's fine to
use the default speech element for everything, but you
can stick attributes in it to follow along with the balloons' varying
shape in the actual comic. Please see the
DTD for a complete listing of all the different flavors of speech,
thought and narration I've tried to predict. I can't account for
everything a comics artist can pull off, of source, but I did
try to cover all the major, agreed-upon visual idioms that have
developed in Western comics over the last century.
Examples
I have made an complete and very chatty example ComicsML document that attempts to illustrate a few of the many ways one can apply this language. While that document is meant to stand alone as a complete example, allow me to excerpt parts of it to show how they might work in context with the content they're decsribing.Let's start with an actual comic strip (drawn by me in 1999):
Now, 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.
This is just enough information to allow for some of the features I'll discuss later in this essay, such as syndication and index generation, while leaving others, like searching and accessibility, without enough information to work. Yet, for a lot of websites, this will probably be enough, as this brief element is relatively easy to make, and can 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:
Whew!
No matter the level of detail you choose to put into your efforts, what you'll end up with after you're done markup up your comic is XML describing bunch of collections of comic panels.
So, the question becomes: why?
Reasons
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 websites, 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. Webmasters finally had 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 websites that collect and display a user-configurable collection of content from these many RSS 'channels', such as 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 all over the place agree 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, thus letting it receive more visitors as its reward. I know that the presence of 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' front pages, a far less efficient or fun method that probably caused me to overlook a lot of the sorts of articles I'm able to catch now.
I think a similar model might be able to work with online comics.
The reader's perspective
I actually 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 go out trying to hunt them down. I have to, because each comic usually has its own site dedicated to it, and while that's fine and good, that means I have to perform an increasing amount of (virtual) legwork as my list of good online comics expands. Now, one could argue that this isn't too hard to overcome with a standard browser: just bookmark all these sites and, once a day, hit 'em all in order. My counterargument, though, would involve the many fine online comics that come out less than daily, 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 every time I go there and it's the same old thing, so in due time I'll give up, and then I'll miss out when a new comic appears. Arrgh!
The creator's perspective
At the same time, you'll notice that there's many more comics available online than there are in your favorite newspaper. There's more available here on the Web, even, than there are of all the different comic strips published in all newspapers by every print comics syndicate. This is because, for a comics creator, 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 right 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.
But you and I, we know of another medium that can reach millions of people, now, don't we?
The Web's 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
any extra work, in effect building self-maintaining funnypage. Of
course, 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 why I put the
teaser element in place. In any case, though, users still
get informed that this comic has been updated. See, syndication is
cool.
What if I wanted to use panel-describing elements so that I could add search engines and other content-delving features to my comics website, and also wanted to syndicate my comics, but didn't want to let these syndication sites also grab all my content? Well, I'd just build two separate ComicsML documents! One, without all the panel elements, would live at a URL I'd freely share with syndication 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 nosey Internet peeking in. This might be ideal if I relied on income from advertising, micropayments, or merchandise I sold within my own Web domain, but I still wanted to be able to easily share news of new and updated comics with the world!
I should note that some in-between solutions already exist which partially address these same issues. Lots of people have written Perl programs that sneak off to their favorite comic websites 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, which you'll do as often as the webmasters change their minds about layout, something that happens quite a bit when tracking lots of sites. (And this isn't even getting into the issues of how the various owners of these sites might feel about you removing the images from the context of their pages.) Other sites try to be something like webcomic portals, but take extensive human input to maintain properly. One of the better models I've seen relies on the comics sites' owners to update their database record whenever they have a new strip available, which might seem reasonable until you consider that the system is closed; information posted to it will appear to people who happen to use that one comics site, but not the countless others who frequent other comics sites, who have their own internal and equally closed systems. Speaking as both a lazy comics fan and a (very, very) lazy web comics creator, that's just too much work! I'd much rather just post my comics and make what meta-information updates I need on a single site (probably my own) than run around and tell all these other sites about it.
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 truly massive. The normal intended way to read through them is to start at the beginning and step through the comics, one by one; most every comics archive page has a ubiquitous suite of first/previous/next/last controls, and no others. But what if I wanted to try fin, Let's say I wanted to find all Dilberts that mention downsizing? Well, I'd be out of luck; since all of that comic's archives are stored solely as images, no software can easily hunt around in its text or topics for me, and I'm not about to click through years' worth of cartoons to find something that matches the topic I'm after.
Once again, some web-savvy comics have taken this matter into their own hands by inventing their own solutions; the User Friendly website, for example, has its own search engine for its hosted comic, using its own software and database to match users' text queries with appropriate comic strips. Now, 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 geeky topic, perhaps in order to lighten the mood at some presentation for which I was preparing, I could only easily find User Friendlys (as well as any other comics on sites that have gone to the trouble to make their own databases -- but then I'd have to know where they were, and then perform a separate search query on each one. Bleah.) 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 (or write my own, if none existed!) that could run my query across all their archives, and return with a result list likely comprising many different comics. Nice!
This markup 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 hiearchy 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. I may add in a 'keyword' element at a strip's top level, as well, whose contents a search program would consider of highest relevance.
As well as these general searches for text, titles and topics, one could also find more abstract information; going back 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 narrow it down, perhaps to all strips where Catbert says the word 'outsourcing' at any point. Thanks to the descriptive elements that handle characters and dialogue, the software can return a lits of hits with a 100 percent relevance rate (assuming the comic's elements have been filled out correctly). Spiffy.
Automatic Index Generation
This is almost an aside to the previous point, but it's an important
one: webmasters can easily generate index files with software that
scans through all the strip elements of a comic and
builds a list of all the titles and their links. Tangentially, they
can also easily experiment with alternatives to those next/previous
links, by yanking more information about nearby strips for display, if
they wish.
Best of all, since the data is stored in a common format, if one person creates software to generate indexes or next/previous pages and decided to share it, then it can work with little to no modification on every site that uses ComicsML!
Equal Access
I am not blind and I don't know any blind people personally, so I don't know what resources may exist to help the visually impaired read comics (beyond what websearches 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-based comic site they desire and give it a read. I think that sucks. Here is a subgroup 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, which I imagine blind computer users make extensive use of, might be able to read the text parts of the comic (if they're typed or written very neatly by the cartoonist), but never hope to describe the visuals that accompany them.
I think proper markup could do a lot to help the blind enjoy comics. The W3C, the orginization principally reponsible for XML's creation and continuing development, has always held web accessibility for all as one of its primary goals, and XML is already being used in numerous ways towards this end, giving content providers a wealth of ways to make sure their material can reach as wide an audience as possible. Since the most obvious way to make comics readable to blind computer users involves keeping an all-text version of the comic as accessible as the comic itself, so that software could 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, thus allowing these readers to enjoy all fully marked-up comics without having to make any adjustments at all to their comics-reading programs.
Of course, this would work better on some comics than others. It would shine with ones which have most of their content in the character's dialog and action, which is the vast majority of them. The few that are very dependent on their visuals would lose something. Of course, one could make the argument that all comics would lose some of their essence through a reduction to prose, but I'd counterargue that the task is nevertheless as worthwhile as translating media (comics or otherwise) into different languages -- and making a textual version of a comic would, in a sense, be just another kind of translation. It will require some creative adjustments, sometimes leaving behind things that can only be expressed in the original language (the visual one, in this case) but replacing them with concepts that have the same semantic essence in the other language (which would be the written word, here).
And, while it's an entirely different sort of "equal access", I'll note off to one side that descriptive markup would also let people with any level of sightedness to read comics in a text browser like lynx. I can think of a few instances when a sighted individual (such as myself) might want to do this. Perhaps the only Web browser I have on-hand at the moment is the LCD screen on my cell phone, for example, but I'm stuck in a traffic-bound taxi, and really want to see what's new with my favorite comics.
And So On
The advantages a comic strip markup language that I list here happen to be the first few I thought up, and I didn't envision them all at once; I actually started with the syndication idea and got as far as writing a first draft of this essay before deciding that the markup language could serve other purposes. The accessibility facet occurred to me during this period of further pondering, and, a while later, my reading about User Friendly's search engine on a mailing list pushed me to finish the deisgn and rewrite this document.
I bet plenty more uses for ComicsML remain for future discovery.
Layout: Not
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 other 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, much as with the strips in a newspaper's comics pages, this shouldn't pose a hardship. It might become somewhat 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 it, preferring to keep this markup language simple and all about content, not presentation. Which might be the wrong idea entirely, for comics. What do you think?
Conclusion
In the short time that's passed since I originally shared the first 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 storyline 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 concept of a comics markup language, and this makes me very optimistic. Given enough time and testing, I think ComicsML can eventually turn into something that lives up to its name, becoming a method to let digital comics, no matter who produces them, truly hook in to 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 any thoughts regarding my scribbling here.
References
- I've made a separate ComicsML resource page, an index to more inoformation and support for this idea, as I develop or collect it.
- A draft of the ComicsML DTD available, of course, 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 Acknowledgements 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 creators' groundbreaking work), but his big treatise on the issue (and, hence, the source of my own thinking in this area) is his Reinventing Comics.
All content on this page is copyright © 2001 by Jason McIntosh.
Return to ComicsML resources" | jmac.org
jmac@jmac.org
jmac@masto.nyc