[whatwg] The blockquote element spec vs common quoting practices

On Thu, 7 Jul 2011, Oli Studholme wrote:
> 
> I?ve been thinking about this line in the blockquote spec:
>   ?Content inside a blockquote must be quoted from another source?
> Depending on how literally you read this, it makes the following
> common quoting practices annoying or impossible:
> 
> 1. Typographically accepted changes to a quote, such as changing
> capitalisation or adding ellipses to indicate missing prose

This is now explicitly allowed, with an example.


> 2. Adding quote metadata inline, such as notes and attribution

This is indeed intentionally non-conforming.


> 3. Adding quote metadata on a line after the block quote, but such that 
> it remains visually associated with the quote

That's fine, so long as it's not in the <blockquote>, per the spec.


> I?ve found examples of these in the Chicago Manual of Style, web
> pages, and books (on Google Books), and the results are here:
>   http://oli.jp/example/blockquote-metadata/
> These examples are annoying (3) or impossible (2, 1?) to achieve while
> being conformant with the current spec.

I don't think they're impossible, though I agree they're annoying, in 
particular the attributions inlined into the last paragraph. We should add 
support to CSS to make this kind of thing easier.


On Fri, 8 Jul 2011, Jeremy Keith wrote:
> 
> Oli has shown the real-world use cases for attribution *within* 
> blockquotes.

I think that overstates the case. The real world use cases are for the 
*presentation* having a block-like effect containing both the quote and 
the attribution. However, that's not a use case for the markup; the 
attribution still isn't actually a part of the quote, however it is 
presented.

Presentation issues like this should be solved in CSS, not in HTML, even 
if it may superficially seem easier to fix in HTML. If we just fix things 
using the simplest possible fix rather than the best possible fix, we end 
up with things like <font>, javascript: links, using <blockquote> for 
indentation, document.write(), having bidi control in the presentation 
layer, etc. These were all mistakes, though, I think we'd all agree. They 
led to the Web being harder to maintain, they led to layering violations, 
they led to the technology being harder to explain, etc.

It's important to keep things well-designed, even if it means more 
up-front work in getting the technology created. If CSS was flexible 
enough to address this kind of problem, it would also be flexible enough 
to solve many other problems.

That's not to say that one day we won't provide an explicit way to mark up 
attribution for <blockquote>s in markup, just that the desired 
presentation isn't a relevant concern in doing so (except insofar as it 
may help decide between two otherwise equally good solutions).

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.


On Sun, 17 Jul 2011, Jukka K. Korpela wrote:
> 17.07.2011 18:07, Nils Dagsson Moskopp wrote:
> >
> > Someone would need to standardize ???ISBN sniffing behaviour??? for 
> > UAs then. Could you make a proposal?
> 
> I think it would be rather trivial. The string ???ISBN??? followed by 
> something that matches the syntax of ISBN numbers, perhaps allowing some 
> variation in punctuation, could be treated as an implicit link to a 
> resource _if_ you have some mechanism(s) for mapping ISBN numbers to 
> URLs.

Given registerProtocolHandler(), it would be trivial to do that for an 
isbn: (or web+isbn:) scheme. No need for browser vendors to get involved.


On Thu, 14 Jul 2011, Kevin Marks wrote:
>
> There is another common pattern, seen in blogging a lot, of putting
> the citation at the top eg
> As <cite class="vcard"><a href="http://www.gyford.com/phil/"
> class="url" rel="acquaintance met colleague"><abbr title="Phil Gyford"
> class="fn">Phil</abbr></a></cite> wrote about the <a
> href="http://www.gyford.com/phil/writing/2009/04/28/geocities.php">ugly
> and neglected fragments</a> of Geocities:</p>
> 
> <blockquote>
>   <p>GeoCities is an awful, ugly, decrepit mess. And this is why it
> will be sorely missed. It???s not only a fine example of the amateur web
> vernacular but much of it is an increasingly rare example of a
> <em>period</em> web vernacular. GeoCities sites show what normal,
> non-designer, people will create if given the tools available around
> the turn of the millennium.</p>
> </blockquote>
> 
> (from jeremy) or pretty much any post here:
> 
> http://www.theatlantic.com/ta-nehisi-coates/
> 
> Would a <header> pattern in the blockquote work for this?

No need, the current markup handles it fine already (as you demonstrate 
above).


On Thu, 14 Jul 2011, Tantek ?~Gelik wrote:
>
> In agreement with Jeremy, I too have found the blockquote/q cite 
> attribute to be nearly as ignored as the longdesc attribute, despite 
> having conducted talks and written tutorials about how to use the 
> cite="" attribute (makes me think that the non-visible-effect-URL 
> attributes on elements should be considered an anti-pattern, evidenced 
> by the fact that they (cite, longdesc, profile etc.) have all failed to 
> get any meaningful uptake among web developers).

Agreed. The only reason I haven't dropped cite="" is that it doesn't cause 
any harm (unlike, say, longdesc="").


> <label for="input-id"> is a known working and in use pattern.

It has an effect.


> Thus I feel much more confident advocating use of the parallel:
> 
> <cite for="quote-id">

What effect would it have? You just pointed out that a feature with no 
effect is an antipattern. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 11 February 2012 16:13:50 UTC