[whatwg] The blockquote element spec vs common quoting practices

[Oli Studholme]

Hi Bjartur,

On Tue, Jul 12, 2011 at 8:28 PM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> Þann þri 12.júl 2011 09:15, skrifaði Oli Studholme:

> Datetimes will usually be presented in a localized format to humans.

I think at most user agents will offer users the option to localise
datetime attributes. I don’t think such localisation would be the
default. This is because even in one localisation there are multiple
ways to present dates, and automatically changing a short date form to
a long localised date form may break layout (which user agents avoid
wherever possible).

>> 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.

This is an interesting idea. However I think this would be a large
increase in complexity (code & l10n) for user agents, and for little
gain. If the user agent was also translating the content then this
might be considered, but merely styling block quote attribution this
way would involve many options per language (depending on what
attributes were present and what data they displayed).

There are a *lot* of potential attributes just for citation.
http://microformats.org/wiki/citation lists 22. Even providing for all
of these will still exclude other potential block quote-related
information, such as notes, copyright etc

> More importantly, how is the author to know how the user wants attribution
> presented?

Heh. Generally users are happy with the author’s content as long as
they can read it. I think there’d be few people in the world that
would care enough to add user styles to change e.g. from a
bibliographic to an author-date system citation. For more than this
you may need to wait for the semantic web ;)

>> 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.

However you’re advocating the user agent follow these rules without
author/user intervention. The reason that adaptive layout isn’t done
by default by user agents (with some notable exceptions in mobile) is
that it has the potential to break things, in such a way that neither
the author or user can fix.

> 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.

But what would a user agent do with an ISBN number? if there’s a URL
at least the user agent can theoretically present a link, like how the
cite attribute is supposed to work. I also just realised you used this
in your footer example for an href. This would present text styled as
a link that doesn’t respond to clicks, a usability problem.

>> 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

You are assuming the rest of the internet’s authors are as
conscientious as you are :/ humans are very adept at making mistakes.
hidden data makes mistakes in this data far harder to identify and
correct

> 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.

this requires the user agent to localise the attributes before
displaying them. what about for languages which aren’t localised in
the user’s stylesheet?

>> 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.

I’m not sure on the earlier discussion about <credit>, and actually
it’s only my assumption that it’d be inline. I’m not even sure if it
would contain all credited information (including perhaps copyright
data), or just the creator’s name. Hopefully someone will weigh in on
this…

>> 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.

what about for notes on a blockquote, such as “emphasis mine”? you’d
need another attribute. what about for when you’d like to contain
HTML, such as “<em>emphasis</em> mine”? attributes prevent this use
case.

> 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.

in graphic design a footer contains supplementary information about
the content it follows. the spec initially disallowed ‘fat footers’,
but the naming and common usage would have led to people using them
for fat footers regardless of the spec. they still contain
supplementary information about their sectioning element or sectioning
root. This semantic connection seems stronger to me than one based on
arbitrary size

peace - oli studholme