[whatwg] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

Þann þri 12.júl 2011 09:15, skrifaði Oli Studholme:
> Firstly thank you (and you Jeremy!) for your input. This thread will
> help decide how the blockquote spec changes to accommodate the use
> cases I outlined, so the more input the better.
>
Thank you for your commentary, it is most appreciated.

> On Tue, Jul 12, 2011 at 2:52 AM, Bjartur Thorlacius
> <svartman95 at gmail.com>  wrote:
>> I'm not arguing against rendering attribution. On
>> the contrary, IMO user agents should render at least the title of the cited
>> resource.
>
> This is a can of worms as authors will want control over both content
> and style. Attributes turned into content are harder to style than
> content. Also attributes tend to be for either humans (@alt) or
> machines (@datetime), so displaying attributes (for humans) that
> contain data (for machines) generally gives bad results.
>
Datetimes will usually be presented in a localized format to humans.

> In the print use cases I found, sometimes attribution is inline after
> the last sentence and sometimes on a following line. This is in
> addition to having attribution in the prose surrounding the block
> quote, as currently recommended by the spec. How would the user agent
> know which way the author wants to present attribution?
>
By fetching and reading a linked stylesheet. I think it's easier to 
style attributes then text nodes polluted with delimiters such as "from" 
and "by" that make reordering hard.
More importantly, how is the author to know how the user wants 
attribution presented?

> Again I have no idea how a user agent would follow these rules.
> Arbitrarily showing one thing in one viewport size and something else
> at a different size would be a bug (arbitrarily meaning without
> author/user intervention, such as via CSS).
A feature to one, a bug to another. The existence of the CSS height and 
width media features suggests that catering style to varying viewport 
sizes is desired by others than just me. I don't see why a user agent 
should seek an authors' permission to style a document for an unusually 
sized viewport, nor require users to write their own stylesheets instead 
of shipping customizable stylesheets.

> Love your phrase
> “superfluous screen space” btw ;)
:P

>> It's simply a question of
>> <blockquote>
>>         Lorem ipsum
>> <footer>
>> <a href="kennitala:2112952019" title="Bjartur Thorlacius">Bjartur</a>
>> on<time datetime="1997-4-2">the second April, 1997</time>
>> </footer>
>> </blockquote>
>> vs
>> <blockquote title="Bjartur Thorlacius" datetime="1997-4-2"
>> cite="kennitala:2112952019">
>>         Lorem ipsum
>> </blockquote>
>
> You've got two additional problems in your example:
> * currently only the<time>,<ins>  and<del>  elements accept the
> datetime attribute, and this isn't even a valid datetime value (you
> wanted 1997-04-02)
Ops, you're correct; this should've been 1997-04-02. I'm proposing 
adding a datetime attribute to <blockquote>.

> * the cite attribute must be a valid URL, and is for providing a link
> to more information about the quote (generally its source) – you can't
> use it for non-URL data
For a lack of a valid URI identifying myself, I used an unregistered 
uri-scheme ("kennitala") and my national ID as the scheme-specific part. 
The exact URI in question is unimportant to the example, but I see no 
reason to restrict values of cite to locators only, as opposed to 
identifiers in general. Quoting books identified by ISBN numbers seems 
like a good enough use case to me.

> This proves Jeremy's earlier point about attributes being a bad place
> to store data. Unless you look at the source you’d never notice these
> mistakes.
>
Sure I would, had I actually tried to, say, render them or validate 
before posting them on the Internet. I refrained from doing so as I knew 
this to be invalid markup, anyway. Where datetime to be a valid 
attribute of blockquote

> I also note that your<footer>  example contains a lot more content,
> the visible part being “Bjartur on the second April, 1997”. A
> potential rendering of the attributes in your second example would
> probably be something like “Bjartur Thorlacius 1997-04-02", which I
> think isn’t as good. This refers to my first point about authors
> wanting to control the content.
>
No, that would be quite an odd rendering. More likely renderings:

Þann annan apríl 1997 skrifaði Bjartur Thorlacius:
 > Lorem ipsum


On the second April, 1997 Bjartur Thorlacius wrote:
 > Lorem ipsum

“ Lorem ipsum
	— Bjartur Thorlacius

It all depends on the user's localized stylesheet.

Note that a datetime in a <time> element would have to parsed just as 
date in a datetime attribute of a <blockquote>. They're both machine 
readable (and that's the best way to internationalize dates).
> Finally two other strikes against attributes are they're harder for
> people learning HTML (which is one reason we have<section>  over
> role="section" etc), and we already have three (I’d argue) perfectly
> good elements for the data you are suggesting adding via attributes:
> *<footer>  for following-line attribution and notes
> *<time>  for datetime information
> *<a>  and<cite>  for citation information
>
I've never heard this argument before. I thought we had <section> rather 
than <div role=section> because the latter has a high 
noise-to-information ratio, leading to overly verbose constructs such as:

<div role=section>
[content]
</div> <!-- end section -->

> There’s also the possibility of adding another inline element, such as
> <credit>, which could let someone credit an author of a quote, or e.g.
> to credit a photographer of an image together<figure>  and
> <figcaption>.
>
So <credit> would be an inline version of <footer>, to be contained in 
<q>? Would it not be more consistent to use attributes, in that case? 
Note that <figcaption> may contain <footer>s.

> For the reasons Jeremy mentioned, I actually hope the cite attribute
> gets dropped in favour of a visible, explicit form of attribution.
> While something like<a>  and<cite>  in a<footer>  could work for
> citation, I still don’t have a good idea about citing explicitly when
> the citation is inline (on the last line of the block quote), or for
> <q>.
>
I do: use the same attributes as for <blockquote>.
Referencing people as works as I did in my examples is probably
bad (read: terrible) style. There should be a sepearate @author 
attribute for attributing an author, distinct from the @cite attribute 
for citing the work.

On a third thought, using a <footer> child of <blockquote> doesn't seem 
so confusing after all, but it'd be even less confusing to HTML 
newcomers were it named e.g. <credit>. But then it would not be an 
appropriate element for "fat footers", whatever they are. I don't see 
what citations and "fat footers" have in common.
The semantics of <footer> would be a lot clearer if "fat footers" were 
not to be enclosed in <footer>, but rather in <nav>s or <aside>s.

Were the "fat footers" example in the spec as follows, I'd have fewer 
objections.

...
  <nav>
   <section>
    <h1>Articles</h1>
    <p><img src="images/somersaults.jpeg" alt=""> Go to the gym with
    our somersaults class! Our teacher Jim takes you through the paces
    in this two-part article. <a href="articles/somersaults/1">Part
    1</a> · <a href="articles/somersaults/1">Part 2</a></p>
    <a href="articles/kindplus/1"><p><img src="images/kindplus.jpeg"> 	
    Tired of walking on the edge of
    a clif<!-- sic -->? Our guest writer Lara shows you how to bumble
    your way through the bars.</p></a>
    <a href="articles/crisps/1"><p><img src="images/crisps.jpeg">
    The chips are down, now all that's left is a potato. What can you
    do with it?</p></a>
   </section>
   <ul>
    <li> <a href="/about">About us...</a>
    <li> <a href="/feedback">Send feedback!</a>
    <li> <a href="/sitemap">Sitemap</a>
   </ul>
  </nav>
  <footer>
   <p><small>Copyright © 2015 The Snacker —
   <a href="/tos">Terms of Service</a></small></p>
  </footer>
</body>