13201 2011-07-10 19:15:40 +0000 Flow content should be allowed in <dt> 2011-10-11 18:57:38 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All CLOSED FIXED P3 normal --- 1 ayg ian annevk ian jackalmage mike mtanalin public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 50876 0 ayg 2011-07-10 19:15:40 +0000 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>. 50877 1 mtanalin 2011-07-10 19:44:21 +0000 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. 50929 2 jackalmage 2011-07-11 20:24:57 +0000 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. 53906 3 mike 2011-08-04 05:34:20 +0000 mass-move component to LC1 55207 4 annevk 2011-08-16 08:44:50 +0000 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.) 56136 5 ian 2011-08-31 23:51:25 +0000 Examples would indeed be helpful. 56179 6 mtanalin 2011-09-01 12:44:49 +0000 (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. 57439 7 ian 2011-09-27 19:44:56 +0000 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. 57442 8 ayg 2011-09-27 20:06:35 +0000 (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. 57527 9 mtanalin 2011-09-29 21:57:47 +0000 (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? 57583 10 ian 2011-09-30 19:41:58 +0000 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. 57588 11 ian 2011-09-30 20:02:53 +0000 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. 57597 12 mtanalin 2011-09-30 20:56:12 +0000 (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. 57600 13 ian 2011-09-30 22:42:56 +0000 I guess you're just better than I am? I dunno. I make the mistake a lot with copy and paste, or just typos. 57616 14 mtanalin 2011-10-01 20:59:12 +0000 (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. 57624 15 ian 2011-10-02 05:20:05 +0000 > 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. 57633 16 mtanalin 2011-10-02 15:33:57 +0000 (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. 57721 17 ian 2011-10-03 19:03:51 +0000 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. 57775 18 ian 2011-10-04 15:57:50 +0000 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. 58068 19 ayg 2011-10-11 18:57:38 +0000 Seems reasonable enough to me.