[whatwg] The blockquote element spec vs common quoting practices
Oli Studholme
whatwg.org at boblet.net
Tue Jul 12 02:15:02 PDT 2011
Hi Bjartur,
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.
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.
> Interactive user agents should additionally make the cited
> resource available in manner similar to how they present other hyperlinked
> resources.
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?
> Additionally user agents with superfluous screen space may render
> the datetime. Handheld renderings should of course not display the datetime
> without user interaction, but reserve the screen estate for more critical
> information, such as the quotation itself.
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). Love your phrase
“superfluous screen space” btw ;)
> 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)
* 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
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.
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.
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
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>.
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>.
HTH
peace - oli studholme
More information about the whatwg
mailing list