[whatwg] The <dialog> element and related topics

Ian Hickson wrote:
> 
> The main reason for <dialog> is to resolve the evergreen debate about what 
> markup to use for dialogs, so actually the questions above are mostly 
> moot. :-)

Didn't you say "Shutting people up is not a valid use case for a new feature,
IMHO." ?

(Sorry, couldn't resist. I have no objections here... just some comments
and a question...)

Here's a better quote:
  http://krijnhoetmer.nl/irc-logs/whatwg/20070614#l-291
   <Hixie> <dialog> solves the problem that people have come up with dozens of
   creative and highly verbose ways of transcribing conversations, none of
   which handled screenplays and scripts, and all of which were an absolute
   pain to use in practice. By introducing <dialog>, we can shortcircuit the
   entire problem with a short syntax, which happens to already work in
   legacy UAs.

> On Fri, 30 Mar 2007, Michel Fortin wrote:
>> Here are some various potential use cases for <dialog> I've collected 
>> and which I think are problematic with the way the <dialog> element is 
>> currently defined.
>>
>> Regular dialogue:
>>
>> http://www.newyorker.com/humor/2007/03/26/070326sh_shouts_rich
> 
> We can do everything in that except the annnotations like "(laughing)". 
> I'm not sure how to handle those.

Alternate voice: <i>.

> On Thu, 21 Dec 2006, Michel Fortin wrote:
>> I read this text recently:
>>
>> <http://daringfireball.net/2006/12/apple_universal_conjectural_transcript>
>>
>> and wondered how it could be marked up using <dialog>. Basically, it's a 
>> fictional dialogue between two persons where once in a while the 
>> dialogue is interrupted by actions in separate paragraphs. It looks much 
>> like a scene in a screenplay.
>>
>> The current spec only allows <dt> and <dd> inside <dialog>, so the 
>> markup for something like this would require closing <dialog> each time 
>> an action paragraph is added and reopening it afterward. Wouldn't it 
>> make more sense to allow regular paragraphs in <dialog> for situational 
>> information and action descriptions?
> 
> What's wrong with closing the <dialog>?
>
> On Fri, 30 Mar 2007, Michel Fortin wrote:
>> IRC Logs:
>>
>> http://www.linode.com/irc/logs/linode-xenbeta.log-2006-03-26
> 
> We can't do /me, but other than that we're ok, no? I'm not sure how to do 
> /me actions.
> ...
 >
On 4 April 2007 Michael Fortin wrote:
>
> Indeed it could... in this case. Sometime however the time is indicated
> every 5, or 10 minutes to not overload the dialogue with time references,
> in which case associating the time reference with the speaker may not be
> the best thing to do. ...

Quite a few of the use cases you're having trouble with here would be
easily solved by allowing <p> inside <dialog>, parallel with <dt> and <dd>.
I think breaking the <dialog> for headings and sections makes sense, but
not for interjecting things like floating timestamps, /me lines and other
non-spoken active description.

> On Fri, 30 Mar 2007, Anne van Kesteren wrote:
>> If I remember correctly <li> was suggested for this purpose on IRC. The 
>> advantage of <li> over <p> would be that people wouldn't easily think 
>> you could put anything inside <dialog> (as you put <p> almost anywhere).
> 
> Anything but <dt> and <dd> is going to cause us headaches in the parser.

Is the problem with existing parsers or with the parsing algorithm?

<dialog>
   <dt>Ray</dt>
   <dd>Who are you?</dd>
   <dt>Faye<dt>
   <dd>The cookie girl.</dd>
   <p>Faye offers Ray some cookies.</p>
   <dt>Ray</dt>
   <dd>Thanks.</dd>
</dialog>

Opera, Safari, and Konqueror seem to handle the nesting just fine.
IE and Firefox have problems with it, but they're inconsistent: Firefox
ends the <dialog> (but doesn't end a <dl> in the same situation), IE
slurps the paragraph into the previous <dd>. Seems reasonable for the
parsing algorithm to adopt the Presto/WebKit/KHTML approach.

Presumably I'm misunderstanding something here. Mind explaining?

> On Thu, 28 Feb 2008, Dave Hodder wrote:
>> > html at nczonline.net wrote (with snippage):
>>> > >     *   I understand the concept of the <dialog/> element but it's named
>>> > > completely wrong. The point is to markup a conversation between two or more
>>> > > parties. The problem is that the word "dialog", when in used in user
>>> > > interfaces, refers to small windows that can be interacted with. When I
>>> > > first read about this element, I assumed it was a way to indicate that part
>>> > > of the page is a dialog window outside of the normal flow of the document
>>> > > (which I thought was cool). After reading the rest, I was disappointed to
>>> > > find out that wasn't the intent. I'd rename this element as <conversation/>
>>> > > or <discussion/> to avoid such misunderstandings.
>> > 
>> > I was confused by the name of the "dialog" element in exactly the same way you
>> > were, originally thinking it was to do with pop-up dialogue boxes. ...
> ...
> I don't think <conversation> or <transcript> or <discussion> are better 
> than <dialog>. I agree that "dialog" is a suboptimal name, though.
> 
> On Fri, 29 Feb 2008, Nicholas C. Zakas wrote:
>> >
>> > As discussed earlier this week, the <dialog/> element is confusing in 
>> > that the term "dialog" in software engineering typically means "dialog 
>> > window". I first thought the element was a way to indicate that a part 
>> > of the page was used as a dialog rather than part of the normal content 
>> > flow. ...

You could use <dialogue> instead of <dialog>. "Dialog" is an alternate spelling
of "dialogue" in common English, but IIRC "dialogue" is never used for dialog
boxes. I'm sure mpt can correct me if I'm wrong...

~fantasai

Received on Wednesday, 7 May 2008 00:37:43 UTC