This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13201 - Flow content should be allowed in <dt>
Summary: Flow content should be allowed in <dt>
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-10 19:15 UTC by Aryeh Gregor
Modified: 2011-10-11 18:57 UTC (History)
7 users (show)

See Also:


Attachments

Description Aryeh Gregor 2011-07-10 19:15:40 UTC
Currently <dt>'s content model is phrasing content.  I think it should be flow content.  XHTML 1.0 only allows inline content, but I don't think this restriction is useful.  <dl> is a very generic sort of element that can fairly be used for any kind of key-value mapping, and while it's not common that the keys will need to contain flow content, it's perfectly conceivable, so there's no reason to tell authors their page is invalid because of it.

Example of where this would be reasonable: a <dl> is used for a FAQ, where some of the questions are multiple paragraphs long.  This seems like a legitimate use-case for <dl>, and the most natural way to represent it is to nest <p> inside <dt>.
Comment 1 Marat Tanalin | tanalin.com 2011-07-10 19:44:21 UTC
Yes, current purely formal restriction is only why such things as FAQs cannot be marked up as DL.

It should be allowed to put block elements inside DT.

P.S. Strange that there is no standard bugzilla's ability to vote for the bug here.
Comment 2 Tab Atkins Jr. 2011-07-11 20:24:57 UTC
Agreed that this restriction should be lifted, because I've written precisely the use-case listed here: A FAQ using <dl> with a multi-paragraph <dt> for a question.
Comment 3 Michael[tm] Smith 2011-08-04 05:34:20 UTC
mass-move component to LC1
Comment 4 Anne 2011-08-16 08:44:50 UTC
I think it would help if someone pasted in or linked to some examples of this in the wild. (With potential for reuse in the specification.)
Comment 5 Ian 'Hixie' Hickson 2011-08-31 23:51:25 UTC
Examples would indeed be helpful.
Comment 6 Marat Tanalin | tanalin.com 2011-09-01 12:44:49 UTC
(In reply to comment #5)
> Examples would indeed be helpful.

Usecases are FAQs, Q&As, interviews.

Examples (in russian):

http://sergeytroshin.ru/articles/windows-xp-sp2-faq/ (see first question)
http://sergeytroshin.ru/articles/faq-6/ (see last question)

The only reason why this FAQs are not marked-up as DL is that HTML spec does not allow DT to contain block-level elements.
Comment 7 Ian 'Hixie' Hickson 2011-09-27 19:44:56 UTC
Multiple paragraphs or paragraphs with nested lists like this really stretch the definition of "name" in "name/value pair", but yeah, based on those examples, I agree that if we're going to allow questions at all, there is at least some credibility to asking why such long questions wouldn't be ok.

FWIW, such questions also aren't allowed in <h1>-<h6> or (now) in <th>, where one could imagine them being equally justifiable.

I guess it comes down to two things: Are there compatibility reasons to be concerned, and what do we lose if we allow it?

Compatibility-wise, it seems that (for <dt> at least) there is no particular issue with allowing flow content.

The loss from allowing this would be that validators no longer flag cases where an author has gotten confused about <dt>s and <dd>s.

So the question really is whether multi-paragraph <dt>s are more or less common than authors confusing <dt>s and <dd>s when they intend to have flow content in their <dd>s and not their <dt>s.
Comment 8 Aryeh Gregor 2011-09-27 20:06:35 UTC
(In reply to comment #7)
> So the question really is whether multi-paragraph <dt>s are more or less common
> than authors confusing <dt>s and <dd>s when they intend to have flow content in
> their <dd>s and not their <dt>s.

We have demonstrated examples where people want to use multiple paragraphs in <dt> (see comment 2), but no demonstrated cases where the validator error was helpful, so the answer seems straightforward right now.
Comment 9 Marat Tanalin | tanalin.com 2011-09-29 21:57:47 UTC
(In reply to comment #7)

> So the question really is whether multi-paragraph <dt>s are more or less common
> than authors confusing <dt>s and <dd>s when they intend to have flow content in
> their <dd>s and not their <dt>s.

Is it more or less common than confusing one HTML element with another? HEAD with BODY? TABLE with TR and TD? One language with another? Bus with car? Apple with orange?
Comment 10 Ian 'Hixie' Hickson 2011-09-30 19:41:58 UTC
Oh there are plenty of cases where validators have caught mistakes like this. Even looking no further than the spec itself, I've had the validator flag this mistake for me.
Comment 11 Ian 'Hixie' Hickson 2011-09-30 20:02:53 UTC
Maybe I can use the approach I suggested in bug 13174 comment 8 for <th>, namely, allow some flow content but not sectioning or heading content descendants.
Comment 12 Marat Tanalin | tanalin.com 2011-09-30 20:56:12 UTC
(In reply to comment #10)
> Oh there are plenty of cases where validators have caught mistakes like this.

During 10-year webdev experience, I've _never_ confused DT with DD. So why other authors (all the more so, that ones who know and care about validation) should?

(In reply to comment #11)
> Maybe I can use the approach I suggested in bug 13174 comment 8 for <th>,
> namely, allow some flow content but not sectioning or heading content
> descendants.

Well, allowing block-level content inside DT with _some_ reasonable structural elements (heading inside heading) blacklisted is definitely far better than nothing.
Comment 13 Ian 'Hixie' Hickson 2011-09-30 22:42:56 UTC
I guess you're just better than I am? I dunno. I make the mistake a lot with copy and paste, or just typos.
Comment 14 Marat Tanalin | tanalin.com 2011-10-01 20:59:12 UTC
(In reply to comment #13)

Validator is just a helping tool. This tool cannot prevent all sorts of errors -- this is realidad, just put up with this.

For example, the validator cannot detect situations where blockquote is used instead of div, and vice versa -- it's just _not of validator's responsibility_. Exactly the same applies to DT/DD in particular.

The fact that formerly you could use validator to detect DT/DD swapping is not more than just _side_ effect of current impractical spec definition. This side effect at all cannot be a reason to ignore real-world needs.

So don't complicate things, throw your scruples overboard, stop unneeded flame, and just accept the change that has more than enough arguments and real-world examples mentioned here to accept this.

Thanks.
Comment 15 Ian 'Hixie' Hickson 2011-10-02 05:20:05 UTC
> Validator is just a helping tool. This tool cannot prevent all sorts of errors
> -- this is realidad, just put up with this.

Just because we can't catch every mistake doesn't mean we shouldn't catch the ones we _can_ catch.


> For example, the validator cannot detect situations where blockquote is used
> instead of div, and vice versa -- it's just _not of validator's
> responsibility_. Exactly the same applies to DT/DD in particular.

It is entirely the validator's responsibility. It's in fact the only point in _having_ a validator. Validators have no role other than helping authors catch their mistakes. That's why we have them. The only reason they can't catch everything is due to technical limitations. Once we have computers with AI and telepathy, these mistakes will also be caught. :-)


> The fact that formerly you could use validator to detect DT/DD swapping is not
> more than just _side_ effect of current impractical spec definition.

It's more than a side-effect, it's the reason for having the definition.


Note that I haven't rejected this bug (if I had it would be marked WONTFIX). In fact, quite the opposite, I've marked it "ASSIGNED", indicating that I do intend to make a change. See comment 11 for the change I am contemplating. That change would have the unfortunate side-effect of no longer catching the mistakes I've mentioned in this bug.
Comment 16 Marat Tanalin | tanalin.com 2011-10-02 15:33:57 UTC
(In reply to comment #15)

> Just because we can't catch every mistake doesn't mean we shouldn't catch the
> ones we _can_ catch.

Ones we can catch _directly_ and _unambiguous_. DT/DD content-type difference is not a such case.

> It is entirely the validator's responsibility. It's in fact the only point in
> _having_ a validator. Validators have no role other than helping authors catch
> their mistakes. That's why we have them.

Validator is primarily to catch syntax errors (nonclosed tags, missing closing quote for attribute, unknown or nonclosed entity, etc.). Validator cannot exactly know semantic intentions of an author. Validator having AI is currently purely fantastic thing, you know that. ;-)

> The only reason they can't catch
> everything is due to technical limitations. Once we have computers with AI and
> telepathy, these mistakes will also be caught. :-)

You have answered yourself to the question. At the present time, validator cannot detect wrong using of elements that syntactically can contain same content. And the fact of current purely-formal restriction for allowed DT content is purely _indirect_ indicator for validator, and therefore this cannot be a serious reason to ignore real-world needs.

> > The fact that formerly you could use validator to detect DT/DD swapping is not
> > more than just _side_ effect of current impractical spec definition.
> 
> It's more than a side-effect, it's the reason for having the definition.

Sounds ambiguous and unclear for me.

> Note that I haven't rejected this bug (if I had it would be marked WONTFIX). In
> fact, quite the opposite, I've marked it "ASSIGNED", indicating that I do
> intend to make a change. See comment 11 for the change I am contemplating. That
> change would have the unfortunate side-effect of no longer catching the
> mistakes I've mentioned in this bug.

Ok. Your continuous doubts are just slightly confusing as for your intentions.
Comment 17 Ian 'Hixie' Hickson 2011-10-03 19:03:51 UTC
My intention is to find a solution that addresses both your needs and mine. My doubts as expressed in the bug are just a stream-of-consciousness dump of my trying to work out whether your needs or my needs are real, which is more important if both are real, what possible compromises might be possible, etc.
Comment 18 Ian 'Hixie' Hickson 2011-10-04 15:57:50 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: http://html5.org/tools/web-apps-tracker?from=6617&to=6618
Rationale: I've allowed all flow content except <header>, <footer>, heading, and sectioning content, based on the discussions above.
Comment 19 Aryeh Gregor 2011-10-11 18:57:38 UTC
Seems reasonable enough to me.