[Bug 23021] New: Define a caption element for <blockquote>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23021

            Bug ID: 23021
           Summary: Define a caption element for <blockquote>
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: xn--mlform-iua@xn--mlform-iua.no
        QA Contact: public-html-bugzilla@w3.org
                CC: faulkner.steve@gmail.com, heydon@heydonworks.com,
                    mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org,
                    xn--mlform-iua@xn--mlform-iua.no
        Depends on: 22996

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 20 August 2013 15:22:36 UTC