- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 31 Jul 2008 01:43:38 +0000 (UTC)
On Thu, 28 Feb 2008 html at nczonline.net wrote: > > * 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. On Wed, 14 May 2008, Krzysztof ??elechowski wrote: > > I recommend <transcript> because it refers to a conversation that has > been put down, as compared to a live <conversation> (I do not recommend > introducing the latter, of course, as HTML is not live). On Wed, 14 May 2008, Smylers wrote, regarding the <transcript> idea: > > However many things in webpages are things which have been written down! > > This is specifically a transcript of some speech -- not a transcript of > commands typed at a computer prompt, nor an exam transcript, nor any > other kind of transcript. > > So focusing on the thing being transcribed, the speech, seems more > sensible; that it has been written down is something which will be > readily apparent to anybody reading it! On Wed, 14 May 2008, K?i?tof ?elechovski wrote: > > Commands typed at a computer prompt do form a conversation between the > commander and the executor (if the executor responds - otherwise it is > good old CODE). On the other hand, a speech is closer to a monologue > (soliloquy). On Wed, 14 May 2008, Smylers wrote, regarding the <talk> idea: > > Indeed; as a noun a "talk" seems to refer to a presentation more often > than the action of talking. <talking> would be less subject to > misinterpretation, but the gerund form makes an awkward tag name. On Wed, 14 May 2008, K?i?tof ?elechovski wrote, regarding <converse>: > > "converse" is more an adjective like "opposite" to me. Which is even > more awkward. On Wed, 14 May 2008, Tab Atkins Jr. wrote, regarding <talk>: > > Honestly, though, are we concerned that people will think a <talk> > element in html refers to a slideshow? The ambiguity of <dialog> occurs > because there is a very reasonable and natural interpretation for the > element name within the context of web applications that happens to be > completely wrong. <talk>, while certainly ambiguous in some ways, is > extremely clear within the context of a web application. There is no > other major existing entity or idea with the same or similar name for it > to clash with. On Wed, 7 May 2008, Simon Pieters wrote, regarding <dialogue>: > > Also see http://forums.whatwg.org/viewtopic.php?t=24 for discussion > about <dialog> vs <dialogue>. On Wed, 14 May 2008, Mikko Rantalainen wrote: > Ian Hickson wrote: > > > > Experience with language="" on <script> suggests that many authors > > have serious difficulties spelling words that contain the "gu" letter > > pair. > > I, too, think that the word "dialog" sounds more like dialog window or > dialog box than a dialogue. > > I'd prefer dialogue over dialog for following reasons: > > - cannot be confused with dialog box or dialog window > > - the dialogue tag would probably most often be generated by CMS system > or authoring software so spelling errors are not such a big issue > > - dialogue is pretty seldom used feature and I believe it doesn't > deserve any shorter tag > > If <dialog> is used instead of <dialogue> then it should be designed in > a such way that it can be used for dialog box in addition to dialogue > (e.g. chat) in the future. On Wed, 14 May 2008, Tab Atkins Jr. wrote: > > I severely doubt this is possible or desirable. It would make it *more* > confusing, I think, if <dialog> was meant for dialog boxes *and* marking > up conversations. > > Just to throw out yet another possibility, how about <convo>? I don't > like it too much, but it at least avoids most of the issues that plagued > the other submissions. I'm generally convinced that <dialog> is an okay > choice for this, but if we *were* to change, I at least want to make > sure it's something I can get behind. > > My personal favorite alternate suggestion so far has been <cl>. Short > and a little confusing? Maybe. But it has the benefit of being > unambiguous and parallels existing tags with similar syntax. But meh, > it's probably not quite right, as <dialog> isn't meant to be > illustrating a conversation list, but rather is a list illustrating a > conversation. On Wed, 14 May 2008, Charles wrote: > > My personal favorite alternate suggestion so far has been <cl>. On Thu, 15 May 2008, Mike Wilson wrote: > > Yes, I also quite like the analogy with dl/ul/ol. But it may be > confusing when using dt and dd as child elements (as in the current spec > for dialog): > > <cl> > <dt> > <dd> > ... > </cl> > > That could be resolved by introducing elements ct and cd: > > <cl> > <ct> > <cd> > ... > </cl> > > and that I guess can be regarded as making things better OR worse > depending on your focus... On Wed, 14 May 2008, fantasai wrote: > > Of course most people using these elements won't be reading the spec. It > is quite likely that someone will assume <dialog> is the "correct" tag > to use for a CSS+JS dialog box. On Wed, 14 May 2008, Scott Hess wrote: > > They are reasonably unlikely to ship a web page that assumes that, > though. > > People who don't read specs generally build web pages by copying and > pasting from other web pages. They don't just think up random things > they'd like to see and try them out to see if they work. So people > looking for a dialog box are going to be looking for an example with a > dialog box, which will _not_ reference the <dialog> element, so they > won't be particularly confused. People looking for an example of how to > express back-and-forth dialogue will find a web page which does so, > which does use the <dialog> element, and they will also not be confused. > Or at least they won't be materially more or less confused than they > would be if the tag was <al> or something (al for "alternating list"). On Thu, 15 May 2008, Keryx Web wrote, regarding <discourse>: > > Discourse is too general. > > In philosophy and theology a discourse can mean "teaching", as in > "Levinas' discourse about 'the other' has made alterity a recurring > theme in all modern philosophy" or "pentecostal theology is defined by > its discourse about the charims". > > I would not associate <discourse> with a spoken list-like dialog. That > would be way too narrow. On Thu, 15 May 2008, Ernest Cline wrote: > > Because of the backwards compatibility using <dt> and <dd> with a new > dialog element would have with most existing UA's, I'd be leery of > changing the names unless additional types of child elements for > <dialog/> (by whatever name it gets) were added, such as an element to > markup stage directions, audience response, or the like. Then, since > we'd be introducing enough new stuff to break compatibility anyway: > > <dialog/> > <speaker/> (what <dt/> currently is) > <speech/> (what <dd/> currently is) > <fx/> (a new element for stage effects, audience response etc.) On Thu, 15 May 2008, Tab Atkins Jr. wrote: > > Yeah, I'm backing off of that position... I'm back to liking plain > <dialog> or <talk>. Either sounds great to me. Having considered everyone's opinion here, I've decided to stick with the original name, <dialog>. It has a few advantages: it starts with "d", so it works well with <dt> and <dd>. It doesn't end in "gue", so it hopefully avoids the problems that "language" had. It means the right thing. I agree that the term is confusing with dialog boxes, however, nobody has made up the <dialog> element to mark up dialog boxes so far, so I see no reason for them to start. People who come across <dialog> are immediately going to see that it is for dialogue, so I don't see a problem here. On Wed, 7 May 2008, fantasai wrote: > > 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>. The problem is where to put the <i>. > 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. The problem is that the </dd> end tag is optional, and <p> doesn't imply it, so this: <dialog> <dt> Baker's Wife <dd> Why, come in, little girl. <dt> Little Red Ridinghood <dd> I wish... It's not for me, it's for my Granny in the woods. A loaf of bread, please. To bring my poor old hungry Granny in the woods. Just a loaf of bread, please. </dialog> ...works, but this: <dialog> <dt> Baker's Wife <dd> Why, come in, little girl. <p> Little Red Ridinghood enters the baker's shop. <dt> Little Red Ridinghood <dd> I wish... It's not for me, it's for my Granny in the woods. A loaf of bread, please. To bring my poor old hungry Granny in the woods. Just a loaf of bread, please. </dialog> ...suddenly doesn't, you need to add the </dd>. Which sucks. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 30 July 2008 18:43:38 UTC