Peter Howard is Wintermute, mythologist

New-Ness

31December2006 [directLink] [personal]

Was about ready to release a rebuild to the web when I realised I wanted to add a ‘scripts’ app, which may take a little time.

Have basically rebuilt the entire site in Django, with significant additions to the photos setup - I’ll now be storing a bunch of metadata in the database and in the photo files, plus I’ll archive the original (full-res) files. Managed to keep the ?bits and articles (?film and ?myth) sections fairly similar, meaning data migration should be easy enough - just have to add a bunch of slug’s to the bits to get the new URL formats working… Unfortunately the photo rewrite means I’ll have to re-upload every photo and re-create the albums (and map the old album IDs to the new ones so I don’t break the internets).

There are a few minor tweaks to be made and I’ll start on the migration; perhaps tonight while people are out celebrating the rolling over of another midnight I’ll try roll over this site…

Semantics and Style :: Markup for Dialogue

30December2006 [directLink] [webprog]

In an effort to create something as portable as possible, I wrote my latest screenplay in near-plain text (using Markdown Syntax). The aim was to have a document I could easily convert to html and style according to the screenplay formatting guidelines given us by the uni. I ended up cheating somewhat on the semantics, both for my sanity (given the markdown syntax) and because I couldn’t find any decent guidelines on marking up dialogue in xhtml1 anyway.

What I ended up with is still somewhat meaningful, so I think I did alright:

• h1 = Scene headings
• h2 = Character (ie, the character speaking)
• h3 = Dialogue description
• h4 = Scene transition
• blockquote = Dialogue
• (and plain text for scene directions)

Both h3 and h4 aren’t always used, so it does break the outline a little, but generally works, in that it still makes sense unstyled. More importantly, each element can be targetted easily, so it’s easy to write up some css rules that push the elements into the correct locations, even for printing (with the limitation that I can’t predict page-breaks properly, so I did have to manually insert a few line-breaks when it came to printing it up).

But it still offends my sensibilities somewhat - using headings for things that aren’t headings is just bad. And it’d be good if I could semantically indicate the link between the speaker and the dialogue. So I’ve been exploring some xhtml1 syntax in an effort to come up with an alternative markup. There are two options that get thrown around:

• Use <blockquote> with a <cite> inside it
• Use <dt> and <dd> (a stretch of the word ‘definition’, but seems to fit the spirit of the spec)

But both I’m uncomfortable with, mainly because there’s no room for directions with either approach. Take an example:

TWITCH
(gruffly)
Your wallet

Using <hN>s as above, it comes out:

<h2>Twitch</h2>
<h3>(gruffly)</h3>
<blockquote>
 Your wallet
</blockquote>

If I encased all that inside a <blockquote>, I could put ‘TWITCH’ inside a <cite>, but it would be inaccurate, as ‘(gruffly)’ isn’t part of the quote, it’s just a direction. Same goes if I put ‘TWITCH’ inside a <dt> and ‘Your wallet’ inside a <dd>; where would ‘(gruffly)’ go?

I’m currently experimenting with an alternative:

<p><cite>Twitch</cite>
 (gruffly)
 <q>Your wallet</q>
</p>

Or, alternatively, which is especially useful for longer dialogue:

<p><cite>Twitch</cite>
 (gruffly)</p>
<blockquote>
 <p>Your wallet</p>
 <p>Or else</p>
</blockquote>

Both kind-of work. They feel a little better semantically, as I’m now citing the speaker, though it’s annoying that xhtml1 has no way of linking a <cite> element to the related quote. (And it’d still be okay to stick an <hN> outside the speaker instead of the <p>, as it is actually a section heading of sorts)

And both can be styled properly, using some simple css:

p cite { display: block; }
p q { display: block; }

The above rules will make the speaker’s name and their dialogue display in blocks (ie, on new lines) of their own, leaving the description on a line of its own as well. It’s a simple matter of applying the correct margins to each element to get correct screenplay formatting.

There’s obviously a tradeoff here though. Unstyled, the dialogue now displays on a single line (though using the <blockquote> element the whole way through will work around that), and browsers apply default styling to each of these elements differently. To get it right, the css will have to be modified to remove all the ugly browser defaults (eg, italics on cite, q or blockquote, and the generated “s :before and :after <q>s in non-IE browsers).

And of course, this syntax can’t be mapped back to markdown syntax… I’m going to have to play around with some regex of my own to see if I can’t reuse the syntax anyway (eg, replace all instances of <h2> with <p><cite>).

And a final note: using <q> or <blockquote> for dialogue gives me one further option: I can use the @cite attribute and create URIs for each of my speakers - eg, cite="http://wintermute.com.au/scripts/twitch-draft-2/characters/Twitch"

Am going to have to play with this further; I may end up with a combination of the two approaches (perhaps compromising some semantics for practicality); will report back when I come up with something that works (and I do like the idea of URIs for my scripts and characters, so am going to have to include that in the Django rebuild).

Winter with Django

02December2006 [directLink] [webprog]

The list of things I want to change on this site has just kept on growing for some time now. And it’s now reached a point where, combined with my desire to learn another language (no, not that kind of language), I’ve decided to do a complete ground-up rebuild. It does mean, though, that I won’t touch much on this site until I’ve got a bunch of areas working together nicely (though the intention is that the site will consist of modules that can easily be added and removed, so I could probably get the basics up and start plugging bits into it):

• Pretty URLs; I’ve had enough of the ‘?’s everywhere, even though I did make a motif of them, and want some easier-to-parse URLs; I know, for example, when I’m taking a look at a link from one site to another, a pretty URL gives me a lot more context, at least letting me know if I’ve read the linked article
• Some restructuring; not sure whether I want to keep the date-based system or focus on categories; and either way I think I’ll move the longer articles (ie, everything under ?film and ?myth) into the general ‘?bits’ section; they were kept apart because I felt they were the kind of thing I might revisit, so they existed independent of time; using date-based or category-based navigation makes a big difference to the way I interact with the site, particularly now that things are quiet around here (I have no entries for Nov2006 and only one for October!)
• Redo the photo gallery; I want to improve the navigation to allow links direct to a photo inside a template rather than standing alone; I want to allow ‘original size’ versions of the photo (at the moment I’m resizing everything to 640x480); I’m going to look at adding a watermark to the images on upload; and I want to keep some metadata around - at the moment, when I resize the image, I lose any metadata attached to the jpeg, some of which is actually interesting…
• I think I’m going to drop the Creative Commons license altogether; I’m thinking it’s actually somewhat meaningless, as the basic Attribution-NonCommercial clause is just an ordinary part of copyright law; and CC allows derivative works, which isn’t something I feel is particularly appropriate to the work I have on this site (under the CC license, someone could rewrite one of my articles to change its argument, then republish it (non-commercially), with attribution to me, which suddenly seems absurd); I think I’d rather just stick to what have become the defaults for internet use - assumed copyright on my articles, photos and videos, assumed freedom on code snippets, commercial use requires permission
• And a redesign or two; with IE7 released I’ve a suspicion people are going to start designing for the web a little differently, and I want to experiment with that (more on this in a separate entry); plus I want to find a way to show off some designs (similar to the old style switcher I had on here around the beginning of the year)

The cool kids are all using Ruby on Rails these days, so I played with it for a week to try figure out if it would suit my purposes. The complete lack of coherent documentation (ie, out of paying for a book, when I don’t even know if I want to continue with the language) was off-putting, and I’ve been hearing some buzz about Django for a while now. Took a brief look at it and I’ve fallen in love. The structure seems a little more elegant, the basics better-documented, and there’s a little more flexibility for working with database structures that don’t quite match the language’s expectations.

Where Rails is a MVC framework for Ruby, Django is similar, but for Python. The two base languages are fairly similar (though support for Python is wider and easier), but Rails tries to hide most of the Ruby, while Django has a straightforward/simplified template syntax, with support to drop into Python anywhere and at any time. The idea of the MVC (model-view-controller) structure is to separate business-logic and presentation, which is a thing of beauty, but Django takes it a little further, splitting the ‘view’ into Templates and Views. So the view is where I handle the presentation-of-data-logic, and the template is simply presentation - the idea being that a designer with no knowledge of the base language could build a Django template - all they’d need is a couple of field names. Breaking up logic and presentation also means there’s generally only one place to go looking when debugging… And, when I’ve been all about separating data and presentation already with XHTML and CSS, Django suits my mindset.

So I’ve been playing with getting Django working on an old CD-collection system I run locally on PHP; biggest problem is that Django doesn’t support composite primary keys, which is something I use in the database. (Rails doesn’t support them either, but I got as far as displaying the data in Django despite the key limitation, while in Rails I could barely start the application.) Fortunately I use primary keys the way Django expects them throughout wintermute’s system, so I’m hoping the database-interface will actually be easier. Working with a database it doesn’t like has taught me a lot about Django though, so it’s all useful… If I can’t get it working as-is, I’m just going to add a primary key field to the table that uses composites; will take a little work going through and adding IDs (talking a couple thousand rows here), but it may have to be done…

Changes are afoot.