Why don’t forget the “dialog” element and use a new attribute on “p” element to inform ‘who’ is speaking? Using :before pseudo selector we can make a simple dialog to be transformed into a script, with the name of the character above the phrases.

Please, forgive my bad English.

We’ve looked at a lot of current practices over time. One we’ve seen a lot is DIV elements with class=”…” attributes, and for some of the most common values, we’ve added new elements to handle the case (SECTION, NAV, etc). Another is really complicated JavaScript and DOM constructs for date controls; we’ve added type=”date” to the INPUT element.

However, as much as I personally would like an element for conversations, the reality is that we haven’t found authors having much trouble with dialogue and the like. They seem quite content to use the P element and don’t seem to be suffering for it. This is in sharp contrast to the other cases I listed.

I would genuinely like to know, not just trolling.

Cheers,

Kelvin

However, while you and I agree with this, it’s not clear that the evidence really supports the need for this. People are using the “p” element for conversations pretty successfully, and there’s a lot of pushback (e.g. from Microsoft, IIRC) about implementing elements for this purpose.

That doesn’t mean we’ll never have one. But maybe it’s worth just waiting for the next version before adding it. HTML5 adds a lot of new stuff. Let’s see how it goes before adding more.

I certainly never thought of using “dl” for dialogues – it’s always meant a definition list to me, and on the basis of Jonas’s sample, everyone else has a similar view.

It would be great if HTML 5 could do better than what has gone before. There’s no question that dialogues are an extremely common idiom on Web 2.0 and therefore some focused markup for it would not be out of place.

I like the idea that AT could use different voices for different speakers, though I don’t know whether that would ever happen.

It does seem that markup for dialogue is being designed backwards though, trying to fit in existing tags first rather than working out exactly what idealised (i.e. without browser implementation limitations) markup would look like – for example, how should stage directions be included, multiple voices speaking simultaneously, etc – and only when we’ve got a full set of use cases, then try and fit suitable tags to meet those use cases.

Why would it not suffice?

Something like this would be grand:

June 10th 2009 11:30 am
Rachel
I want dialog tags, yeah!
Ian Hickson
Alas, you just missed them.

A girl can dream… too bad!