This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In XHTML 1.0, block elements inside TH elements was allowed. In HTML5, only phrasing content is allowed inside TH: http://www.w3.org/TR/html5/tabular-data.html#the-th-element This is bad in some cases, and forces developers to use TD instead of TH when the cell actually contains _heading_ content. Using TD instead of TH for heading content is harmful as for semantics. For example: <th> <dl> <dt>Actual header</dt> <dd>Additional content that, by visual design, cannot be represented as a separate table cell</dd> </dl> </th> Its very questionable that heading content cannot contain blocks at all according to common sense. However, if necessary, new THCAPTION element could be added to the HTML standard to resolve the semantic issue: <th> <dl> <dt><thcaption>Real header</thcaption></dt> <dd>Additional content that, by visual design, cannot be represented as a separate table cell</dd> </dl> </th> Thus, user agents (that ones that care about such semantics) would treat THCAPTION content as actual heading content of the TH, and all other content of the TH could be treated as non-heading content (as inside TD). Thanks.
What is a specific real-world use-case where you want to put non-phrasing content inside a <th>? Can you point to particular sites you were trying to write (or someone else was) where you did this or wanted to do it, and explain why? Personally I'm inclined to think this would be a good change, but it would help your case a lot if you provided specific real-world examples.
(In reply to comment #1) > Personally I'm inclined to think this would be a good change, but it > would help your case a lot if you provided specific real-world examples. Real-world example: <th scope="row"> <div><a href="#">Example preparation</a></div> <dl> <dt><abbr title="International nonproprietary name">INN</abbr>:</dt> <dd><a href="#">Example nonproprietary name</a></dd> </dl> </th> Example preparation is a preparation title. INN is (sematically) DL and, by visual design, is placed inside TH after preparation title. Moreover, both preparation title and international nonproprietary name are heading content, and so should be placed inside TH. In XHTML 1.0, this is perfectly valid.
mass-move component to LC1
Another case where you might want flow content inside a <th> is <h#>. Consider a Wikipedia article that consists of a single long table, with information about several hundred different things listed alphabetically. You might want to subdivide it by letter, with rows like <tr><th colspan=X><h2>M</h2></th></tr> But you want it to all be in one big table, not split into several tables, because it's logically one big table with hundreds of rows and not multiple unrelated tables.
*** Bug 13924 has been marked as a duplicate of this bug. ***
No need for the <hx> in comment 4. The <th> provides sufficient semantics. In fact an <hx> element there would screw up the outline. I don't understand the case in example 2. Can you show me a Web page using this? The only use case that I've seen on real sites is including a tooltip in a <th>. My plan is to address that by specifically allowing <dialog> when we introduce that later on.
(In reply to comment #6) > Can you show me a Web page using this? http://cdl.ru/categories_in_item.mhtml?CatID=3&ShortID=945 http://cdl.ru/categories_in_item.mhtml?CatID=3&ShortID=69 etc.
Hm, yeah, hard to argue with that. I guess I'll change the content model back to allowing flow content, but add an example or note explaining why putting headings in <th>s is a bad idea. Maybe we should just allow flow but blacklist certain descendants, say sectioning content, sectioning roots, and heading content?
(In reply to comment #8) > I guess I'll change the content model back to allowing flow content Unbelievable. ;-) > but add an example or note explaining why putting > headings in <th>s is a bad idea. Yes, it's good idea to give recommendations here instead of requiring smth. It makes sense to adopt this practice more widely in the HTML spec. > Maybe we should just allow flow but blacklist certain descendants, say > sectioning content, sectioning roots, and heading content? Maybe. But, quoting yourself, wouldn't it be confusing for authors who do not read specs (as well as do not care about validation) at all? Anyway, it may make sense to just rollback rules for TH to HTML4 state, and, instead of inventing some blacklists, work harder on more important things like providing consistency between good-practice server-side validation and client-side one (bug 13769). Thanks.
> But, quoting yourself, wouldn't it be confusing for authors who do not > read specs (as well as do not care about validation) at all? A conformance requirement is unlikely to have any effect at all on someone who doesn't look up the conformance requirements nor use software that checks the conformance requirements, least of all confusing them.
(In reply to comment #10) Ok. By the way, I personally would prefer to have the blacklist as spec recommendations, not requirements (first of the options you proposed in comment 8). Sothat validator could detect such situations and report them not as errors, but as just notices or warnings.
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.