[whatwg] Problems with the definition of <cite>
Benjamin Hawkes-Lewis
bhawkeslewis at googlemail.com
Thu Jan 18 16:10:55 PST 2007
I wrote:
> That's not a fair summary: see the example I gave to Anne van Kesteren
> of getting back to a Hamlet scene text from <cite>Hamlet, I.ii</cite>
> with a mere Google query.
James Graham wrote:
> Using the <cite> attribute to link to a search page is at best almost-useless
> and at worst damaging and confusing.
Sorry, I didn't make myself clear. The <cite> in my example does /not/
link anywhere. My point was that even with the mere knowledge that the
contents of <cite> are a citation, agents can construct useful web
queries. Not as good as a <cite> with a URI, but not /useless/.
> > It would be more accurate to see <cite> could
> > be improved upon. IMHO it would be nicer to have real elements in HTML
> > for detailed bibliographic elements, but that goes against the general
> > consensus that we should shift detailed semantics into
> > microformats/roles.
>
> So, if we accept that full bibliographic data will only be accepted as a
> microformat, does <cite> have enough value to warrant keeping it? If the best
> use case we can manage is "it could link to a search for the source" I would say
> the element is worthless.
My point was it could be used as the basis for a search by an automated
agent. This would be true of a microformat like hcite too, /if/ there
any guarantee that Web Applications 1.0 compatible user agents would
support such a microformat. (Of course, if there were such a guarantee,
one would have to ask why the microformat in question wasn't part of the
spec in the first place.) Guaranteed recognition of the <cite> element
is better than nothing.
> I suspect that browser makers would be unwilling to implement this change since
> there are probably a fair few sites that depend on <cite> being italic to look
> as the author intended and, as far as I know, major browsers have essentially
> interoperable default style sheets so making this change would "break" sites
> compared to the competition.
>From the perspective of website visitors, I'm not such a change would be
remarkable. For example, in some bibliographic styles, book titles for
example are non-italic anyway. From the perspective of authors, a fix
preserving the faulty semantics is trivial (style cite italic) and a
revision of their site to use the correct semantics is desirable.
I asked:
> Deprecating <cite> wouldn't solve any problems, as far as I can see. How
> would you connect <q> or <blockquote> to a particular hCite block?
James Graham replied:
> Indeed in many cases where citations are important there is no
> direct quote to match the citation (almost all scientific papers fit this
> model).
This might well be an argument for providing ways to explicitly connect
<cite> with elements other than <q> or <blockquote> (a global attribute
"citeref" could perhaps do that rather well). Given the existence of the
humanities (a literary form in which extended series of quotations are
decorated with footnotes and occasional commentary), I can't see how
it's in any way an argument against providing ways to explicitly connect
<cite> with <q> and <blockquote>.
James Graham continued:
> But, accepting that some people think this is very important, I don't
> see how a <cite> element that is not part of the microformat helps here - unless
> sandwiching stuff in <cite> without the microformat filling can itself lead to
> the development of worthwhile UA features.
Well, the original idea was the <cite> could contain some sort of link,
and that this would be a way of associating a URI with a <q> or
<blockquote>. To this I made an additional point, that the mere act of
marking up a bit of content as a citation with <cite> makes it easier to
perform more sophisticated automated processing, such as retrieving a
"best guess" source.
How worthwhile such automated processing is depends partly on whether
the spec and tools make it easy to provide citations in URI form.
--
Benjamin Hawkes-Lewis
More information about the whatwg
mailing list