views:

707

answers:

11

I have a sketch that I want to put up on my website, and I also intend to write a short play at some point which I'd also want to make freely available.

I'm trying to work out the best way of representing this in HTML. I basically need two columns - one for the character speaking, and one for the text. Each speech obviously needs to line up with the speaker though. In other words, something like this:

    Jeff        This sure is a nice website we've got now.

    Joel        It certainly is. By the way, working at FogCreek rocks.

    Jeff        Of course it does. Have you played Rock Band yet? It's
                 a lot of fun.

(Well it's better than lorem ipsum...)

I know how I could do this with HTML tables (with one table row per speech) but that seems pretty ugly, and everyone certainly seems to be keen on using CSS to represent non-tabular data. I can't see how this really counts a tabular data - my use of "row" and "column" earlier was to do with the layout rather than the fundamental data.

So, any ideas? I think most of the script websites I've seen (not many, admittedly) either use <pre> like my example above, or don't bother trying to keep the normal script format, instead just prefixing each paragraph with the speaker's name. (See the podcast wiki for an example of this style.) I'm having trouble working out even what HTML elements I should be using to represent this, frankly - a dictionary definition list with the speaker as the term and the speech as the definition is probably the closest I've thought of, but that feels like abuse.

+3  A: 

IMO that actually is tabular data. First column is speaker, second column is text.

If you want to be fashionable and aggressively eschew tables, though, what I believe is compliant with what the Web mavens are dictating this season is a structure like:

<div class="play">
  <div class="line">
    <div class="speaker">Jeff</div>
    <div class="text">This sure is a nice website we've got now. </div>
  </div>
  <div class="line">
    <div class="speaker">Joel</div>
    <div class="text">It certainly is. By the way, working at FogCreek rocks.</div>
  </div>
</div>

Then you control how that lays out with appropriate CSS.

If it looks like you're basically writing XML and using CSS to specify how it lays out, well, that's because that's what the Web mavens believe you should be doing, AFAICT.

chaos
That leads to an interesting idea, actually - XML + XSLT. <speech><speaker>Jeff</speaker><text>Foo</text></speech>. Hmm. Next job: a WYSIWYG app for it... otherwise I can see the creative flow getting somewhat interrupted :)
Jon Skeet
(I can use the XSLT to create tables instead of huge numbers of divs, of course.)
Jon Skeet
This is almost as much markup as a table...
Eran Galperin
@Jon Skeet: Not unreasonable. May be just as well to have your play editing interface store in a database, output whatever final form is useful, and skip the XSLT, though.
chaos
@Eran Galperin: Yup. But it's the magically politically approved divs, not the evil counterrevolutionary tables, so it's Right and Good. (Can you tell I think some people are a bit snooty and prima-donnaish with their knee-jerk "eww, tables" diatribes? Yeah, I thought you could.)
chaos
I don't agree. The same structure (two columns) can be implemented using semantic tags with much less markup, easily.
Eran Galperin
@Eran Galperin: While I think the divs are kind of ridiculous and would vote for tables in the first place, I have to point out that you and Mark Tyler's examples have a lot less markup, but they're toy examples that can't actually be used in a non-trivial production website. (cont.)
chaos
@Eran Galperin: It's insanely bad practice to globally repurpose semantic tags for something like this the way both of your examples are doing. In real production, your markup would be expanded by the class (or, ugh, id) attributes necessary to isolate your behavioral specifications.
chaos
of course in real world it would have a class, or a container with a class. it is just an example, not a full application. I added a container to my example, and still less than half the markup
Eran Galperin
@Eran Galperin: 'kay. I do like your example better with the container. Our examples are aimed at different things, really. Mine isn't trying to minimize markup, it's trying to map logical structure and maximize the clarity and precision of associated CSS.
chaos
Minimizing markup is not an ideal, but it does help maintainability and simplicity. Using named tags is also good for semantics (screen readers, etc)
Eran Galperin
@chaos "IMO that actually is tabular data." - I absolutely agree.
yaauie
Definitely a table - no need for divs - since this is of the form (a:b)+ and not a keyvalue form since "a" can be repeated (rules out <dl>).
annakata
@annakata: the spec says nothing about unique terms within a DL. A DL can contain any number of dd/dt elements in any order (well, as long as there's at least 1 in the entire list!). This makes the humble DL very flexible and quite well-suited to tasks such as this. Until we get an element ...
Bobby Jack
... aimed directly at scripts, I think this is the best we can do. I guess a table isn't totally wrong, but I generally get suspicious about tabular data that MUST be ordered in a fixed way, and not by a given column. This is my own personal definition, of course.
Bobby Jack
+1  A: 

Jon, I am not good at CSS.

But I have a suggestion. You can style it the way popular IM software do it (color the line by each character differently. i.e. Red for Joel & Blue for Jeff)

I am sorry, if I have misunderstood it completely.

shahkalpesh
+4  A: 

I would use headers and paragraphs.

<div class="play">
    <h2>Jeff</h2>        
    <p>This sure is a nice website we've got now.</p>

    <h2>Joel</h2>
    <p>It certainly is. By the way, working at FogCreek rocks.</p>

    <h2>Jeff</h2>        
    <p>Of course it does. Have you played Rock Band yet? It's<br />
    a lot of fun.</p>
</div>

With the following styles it would arrange as you presented it:

.play h2 {
    float:left; 
    clear:left;
    width:100px;
    margin:0;
}
.play p {
    margin-left:100px;
}
Eran Galperin
+22  A: 

More proper (symantically) and shorter would be to use definition lists:

<dl>
   <dt>Jeff</dt>
   <dd>This sure is a nice website we've got now.</dd>
</dl>


dl {
  overflow:hideen;
}

dl dt {
  float:left;
  width:30%;
}

dl dd {
  float:left;
  width:70%;
}
Deniss Kozlovs
I don't really agree that that's necessarily semantically proper. An actual definition list doesn't have an extended series of multiple definitions for the term "Jeff".
chaos
Thinking about this some more, I'd say the same thing if the <dl> element were called <al>, association list, but not if it were <pl>, paired list.
chaos
Sure, but unfortunatelly HTML doesn't have the <al> or <pl> tags implemented. There's so much things missing in HTML.. :)
Deniss Kozlovs
I'm pretty strongly against this for the same reasons chaos is
annakata
Chaos, I would tend to agree, but consider that the HTML 4.01 spec (for instance) actually says that "Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words."
Will Wagner
+1 for this solution and Will's comment.
Bobby Jack
@Will Wagner: Ha! Well, I guess it's all right, then. :)
chaos
+3  A: 

Tables is the way to go.

Anything else like messing around with <div>s and css or XSLT is just reinventing the <table> but with a c**p syntax.

I would go for three or four fixed width colums. (Any non-trivial play is going to need stage directions, special effects, sound effects etc.).

James Anderson
Stage directions etc are generally represented in the same column as the speech, but in italics. It does sound like tables may well be the best way to go though.
Jon Skeet
Oh, but now I've read all the other answers a couple of times, it's getting less clear...
Jon Skeet
Don't let the anti-table bullies scare ya. If the situation calls for a GOTO, then by God it calls for a GOTO.
chaos
I see no advantage to avoiding tables here. I would, however, recommend using <th> elements for your names, as they are to the speech what headers are to numbers in a numeric grid.
yaauie
@chaos: The pro/anti table debate is *so* frequently miscast - tables are a perfectly acceptable solution to a range of problems. The troubles arise when people start to use tables as a means of layout control where the content has no earthly relationship with a table. It's all about the semantics.
annakata
@chaos - just because I care, doesn't make me a bully!
Steve Perks
+4  A: 

I second the heresy :-)

Always good to consider CSS before resorting to tables - but often tables really are the best fit. It looks like it in this case.

The only additional consideration would be accessibility. I've heard that tables make it harder for text reader software to process tables, but I don't see why this would be the case (feel free to comment here if you know more).

One other thing - I presume you'd be holding the raw data in some other format first - perhaps a database, or xml or some other structured text?

In any case, getting it into an xml format and tranforming that to html with xslt can be quite liberating when it comes to playing with this stuff.

Phil Nash
+3  A: 

Please avoid the "sledge hammer syndrome" (if your only tool is a hammer, you try to treat every problem like a nail). HTML is a representation language, not a source language.

So my suggestion is to write the play in something which can represent your thoughts best (not necessarily XML) and then convert that to HTML. For my own works, I'm using a recursive XML parser which can fall out of XML parsing for certain elements:

<content><<Hello,>> Forne smiled and thought: <<T Idiot.>></content>

My parser will invoke a custom parser to parse the content of <content>. In my case, it will create an intermediate XML tree:

<content><say>Hello,</say> <char>Forne</char> smiled and thought: <think>Idiot.</think></content>

This tree is then converted into HTML, TeX, PDF, whatever.

[EDIT] My strategy to come up with a compact language works like this: I start with XML. After a while, I look at the XML and try to see patterns. Then I think how I could express these patterns in a more compact way 1.) as XML, 2.) as XML text (with custom markup) and 3.) as something else entirely. When an idea hits me, I write a parser for the new format.

Frankly, writing parsers which can turn something into XML for automatic background processing is a minor task, today.

Aaron Digulla
+1 for HTML just being the representation. I'm not sure what the best source language is at this point - but I will need to know what HTML to generate at some point. Of course, with an appropriate source language I can try all the ideas given here fairly easily...
Jon Skeet
@Jon: There are three people on this planet who can design a good language. One of them is Guido van Rossum and the other two isn't me or you ;)
Aaron Digulla
+1  A: 

If you want to do it semantically, I would use labels, something like:

<div class="script">
<label for="Jeff1">Jeff<label>
<div id="Jeff1">
  <p>This sure is a nice website we've got now.</p>
</div>

<label for="Joel1">Joel</label>
<div id="Joel1">
  <p>It certainly is.</p>
  <p>By the way, working at FogCreek rocks.</p>
</div>

<label for="Jeff2">Jeff</label>
<div id="Jeff2">
  <p>Of course it does.</p>
  <p>Have you played Rock Band yet? It's a lot of fun.</p>
</div>

</div>

That degrades pretty nicely and I think the label is a bit more appropriate for what you're trying to do. And then, in your style sheet, I would style it something like Eran Galperin's example CSS.

The other suggestion I would have, if you're serious about this, would be to look further into how dead tree scripts are written and do your utmost to preserve their style. This will help ensure that it looks familiar (read professional) to your audience.

Travis
I'm serious enough to have a look at some of the scripts I've got knocking around and try to work out any kinks. I'm not serious enough to spend hours and hours on it :) I like the look of this apart from having to have a separate ID for each speech - that doesn't sound ideal to me :(
Jon Skeet
You can do without ids and leave the for attribute out of the divs.
Travis
+9  A: 

My favourite example of marking up something like this is one of Tantek's XHTML compounds http://tantek.com/presentations/2005/03/elementsofxhtml/ (check out the conversation bit)

In summary it goes like so:

<ol>
  <li><cite>Jeff</cite>
    <blockquote><p>This sure is a nice website we've got now.</p><blockquote>
  </li>
  <li><cite>Joel</cite>
    <blockquote><p>It certainly is. By the way, working at FogCreek rocks.</p></blockquote>
  </li>
  ...etc...
</ol>

Not sure how you'd mark up stage directions etc... Maybe you'll end up creating a new microformat :)

Also that markup has some ideal CSS hooks, with discrete LInes unlike a definition list.

sanchothefat
Beat me to the cite, blockquote combination. I wasn't going to add a list though, although that is exactly what it is, a list of lines.
John_
+7  A: 

I'd say

<dialog>
  <dt>Jeff
  <dd>This sure is a nice website we've got now.
  <dt>Joel
  <dd>It certainly is. By the way, working at FogCreek rocks.
  <dt>Jeff
  <dd>Of course it does. Have you played Rock Band yet? It's a lot of fun.
</dialog>

as defined in HTML5.

Of course, you'll need a <script>document.createElement('dialog');</script> to get IE to do something sensible and a dialog { display:block; } in your CSS to get it to work completely.

Ms2ger
Wow - that's really cool! Now, how many current browsers support it?
Jon Skeet
Like it or not, I'd suggest that this supports the initial suggested use in the w3 specs of DL. No?
Steve Perks
+2  A: 

You're not going to get a definitive answer to this question as HTML has many gaps, one of which is this - there are some very solid articles dotted around the web about his subject and a good place to start would be Bruce Lawson's article from 2006.

Considering that there is no answer to the question, the best we can do is look at what elements that are available to us and make our own compromises based upon our (and the communities) interpretation of the guidelines.

I personally like the cite/blockquote and data list route. I know that data lists smack of none semantic markup, but I truly believe that the intent of data lists isn't to list data definitions purely in a dictionary fashion, but to pair data where uls and ols can't.

I've spent a lot of time thinking about semantics, and one thing I (as well as most others in the field) am sure of when looking at all questions of markup is that tables are not the answer to 99.9% of markup questions (if it's not tabular data where you can use th, caption then tables should really be dropped from your inventory). That said, I would also say that exclusively using divs is also probably not the right answer.

I very much doubt that the up-votes in this question will reflect the best approach, but will more likely reflect an agreement to the approach base upon the voters current knowledge and use of HTML.

Cheers,
Steve

Steve Perks