This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
PROBLEM: It is not uncommon that authors place the annotation of a quotation inside the blockquote element. As there is no child element for annotations, this conflicts with the definition of <blockquote>, which says that all the content is (possibly edited) quotation. PROPOSAL: Define a blockquote caption element (hereafter described as 'bqcaption') for this purpose. This element should be allowed anywhere inside <blockquote> (at start or at bottom) - much like <figcaption>. The ARIA role should probably be contentinfo. PROS: 1) Captioning elements are often child elements of the element it is captioniong. Thus it follows a well known designpattern in all markup languages. 2) It follows a particular pattern that has emerged in HTML, where there is no general caption element that changes meaning based on context. Instead, the caption elements of HTML tend to differ in their name from parent element to parent element. Examples: <legend> for <fieldset>, <caption> for <table>, <figcaption> for <figure>, <summary> for <details> etc. This pattern has the advantage that, if the author misplaces the element, it is easy to see were it belongs or that it is incorrect. Also, it means that copy-paste of code will not easly change the meaning of the element (as could be the case if the element was a general captioning element that was used in several elements) 3) Lets us avoid the competing proposal, namely the proposal to reuse <footer> - see bug 22996. The reuse of <footer> would contradict with the pattern of using differently named captions, as described in point 2) above, as it would effectively make <footer> into an element that function as un-quoted caption. Footer would be an element that changed meaning per context, whereas <bqcaption> would not. So, for instance, if someone copies an entire page with a <footer> inside, per bug 22996, the copied <footer> would, as it seems, get the meaning of an unquoted footer. 4) A dedicated caption element would be simpler for authors to understand (this point is actually a variant of 2) and 3)). 5) But for stating that <blockquote> can have one or none blockquote caption elements, we avoid redefining the <blockquote>, and we also avoid redefining <footer> - plus that we avoid that authors have to struggle with the contextual meaning of <footer>. 6) We don't hurt anyone’s toe. Though some has advocated using <footer>, this is *far* from a pattern. CONS: * We must deifine a new element, which isn’t without costs. * AT, e.g. Jaws, supports <footer> as content info but do not support this new element. # COUNTER ARGUMENT: <footer> is presented to AT as content info because its default role is contentinfo. By defining the same role for <bqcaption>, AT users get the same experience.
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: later Change Description: no spec change Rationale: We're not rejecting this feature request but it requires someone to write up a concrete proposal in the form of an extension spec. For information on how to do so refer to: http://www.w3.org/html/wg/wiki/ExtensionHowTo
OK.