23021 2013-08-20 15:22:33 +0000 Define a caption element for <blockquote> 2013-09-21 10:46:05 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified All All RESOLVED LATER NeedsExtensionSpec a11y P2 normal --- 22996 23315 1 xn--mlform-iua faulkner.steve faulkner.steve heydon lwatson mike public-html-admin public-html-wg-issue-tracking xn--mlform-iua public-html-bugzilla oldest_to_newest 92339 0 xn--mlform-iua 2013-08-20 15:22:33 +0000 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. 92955 1 faulkner.steve 2013-09-04 10:38:35 +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: 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 92959 2 xn--mlform-iua 2013-09-04 11:10:00 +0000 OK.