[Bug 22996] Modify blockquote element definition to allow citations

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

--- Comment #4 from heydon <heydon@heydonworks.com> ---
(In reply to comment #3)
> (In reply to comment #2)
> 
> > I think this is an interesting solution to the problem but, since
> > <blockquote> is a sectioning root, I think <footer> is more apt for
> > <blockquote> metadata. It also requires less markup and (for me at least!)
> > less congnitive reconfiguration. 
> 
> It is not clear to me why you consider that the section root feature has as
> consequence that the metadata element should be kept inside (rather than
> outside) <blockquote>. And, FWIW, <figure> is a sectioning root as well.
> 
> (The meaning of 'section root' is: """can have their own outlines, but the
> sections and headings inside these elements do not contribute to the
> outlines of their ancestors""".)
> 
> > In addition, I think the <figcaption> has a less coupled relationship with
> > its sibling <blockquote> than the <footer> would as a child element.
> 
> Well, they would then both be generic children of <figure>, and as such they
> would be on equal footing and 'together'. (It could perhaps be a useful
> pattern for footnotes?) If we are talking about the generic level, then it
> can also be seen as a good point to keep them separete. After all, one
> (blockquote) is a quotation while the other (figcaption) is not a quoation
> ...
> 
> AT the HTML5doctor page, Oli pointed to a reply from Hixie [1]. In this
> reply, Ian suggested to introduce a new <credit(s)> element rather than
> changing <footer>.[1] And such a new element seems like a better idea than
> <footer> if first we want to place metadata inside <blockquote>. Quoting Ian:
> 
> """
> I expect we will eventually create a <credit> element that goes inside 
> <blockquote>, <figure> or <figcaption>, <caption>, and maybe other 
> contexts as well. At the moment, I'm deferring adding it so that we can 
> see how <figure> and the other new elements do in the wild.
> """
> 
> The pros of <credit> are that it:
>   a) avoids the problem of "what if I want to quote a <footer>?",
>      and thus is easier to understand.
>   b) is a new element - we don't need to change the semantics
>      of an existing elemen - plus that it is easier to fine tune
>      a new element for this purpose, rather than adding more 
>      gotchas to an existing element
>   c) can be used for giving credit also inside <figure> and 
>      eventually in other elements.
>   d) does not have a name that indicates that it should be 
>      placed at the foot of the element - a <credit> could
>      just as well go at the start of the element.
> 
> [1]
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-February/034822.html


You are quite right: figures are also sectioning roots.

However, since <figure> already has <figcaption>, <caption> is taken and
<figcaption> is clumsily named to be ported to <blockquote>s, there's still
<blockquote>'s (direct) metadata to address. 

The <credit> element is clearly intended as a replacement for <cite>. It does
not solve the problem that this bug addresses because it is far too specific.
That is, one could hardly include the information "emphasis mine" or "circa 2nd
Century Greece" in an element called <credit>, could they? If <credit> replaced
<cite> tomorrow, I'd be fine with that but it is not equivalent to either
<figcaption> or <footer>.

A compromise:

I think allowing <footer>s in <blockquote>s is the shortest route to providing
a metadata solution for blockquotes, and one which has the benefit of
precendent. However, I'm keen to emphasise the textual capacity of figure,
should it be a simple <p> or a <blockquote>. I'd be happy to raise a separate
bug / topic of discussion on that.

FWIW, I recommend we see to this specific bug, then address guidelines on
<figure> usage separately. If <credit> emerges it will be as a replacement for
<cite> - an action that will not be necessary if <cite>'s remit is allowed to
include author names etc.

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

Received on Sunday, 18 August 2013 18:51:53 UTC