[uf-discuss] [citation]: Brian's outstanding issues 2:

[Michael McCracken]

On 9/25/06, Bruce D'Arcus <bdarcus.lists at gmail.com> wrote:
> On 9/25/06, Michael McCracken <michael.mccracken at gmail.com> wrote:
>
> > I do agree that using an element with type class instead of a huge
> > number of type classes is the way to go here, to avoid class namespace
> > pollution.
>
> I actually don't like using the separate element, in part because this
> information is usally not displayed, but rather used for processing
> (styling and conversion). The type does matter for display, in other
> words, but in more subtle ways that have the user see "book."

I know what you mean - the type matters in how you format the
reference, but it isn't usually displayed. This is something we'll
have to hammer out. Right now it looks like a tradeoff between
flexibility and elegance, but I'm hoping for a solution that combines
both...

Also, when I thought about it, in many cases where the reference is a
search result or otherwise not part of a specifically formatted
publication, I wouldn't mind the extra word explaining exactly what it
is.

> Before we settle this, can we go over the technical arguments against
> using classes? I know, for example, that Tantek once said it's not
> generally good practice to double up classes ("hcite book") but I'd
> like some explanation about why.
>
> But I will say that in either case, one must allow for extensions.
> I've worked on this for a long time, and defining a fixed list of
> types that is anything but arbitrary is pretty much impossible.

I'm not aware of the arguments for/against doubling up. Are you
referring to this:
http://microformats.org/wiki/hcard-faq#nesting-properties
?

The problem I have with using class names to encode the type of a
reference is that we end up having a new class name for every type of
reference, which as you say is large and arbitrary, and might be
considered infinite for any practical purpose. This seems like we're
claiming a very large and perpetually undefined set of class names as
potential citation type names, which violates the "minimal vocabulary
principle" that Gazza mentioned earlier:
http://microformats.org/wiki/naming-principles#Minimal_Vocabulary

While that principle isn't fully explained on the wiki, I'd say it's
pretty clear that even if we didn't allow arbitrary new class names,
we'd still be forced to propose a long list of new class names to
cover all the types of cited items.

On the other hand, I can imagine wanting to use CSS to display an icon
for a book next to a book's reference, or a journal icon for an
article. Many current sites do something like this. That's easy enough
with class="book", but I'm not familiar enough with CSS to know if
that's possible based on the content of an element. I suspect not. Can
any CSS experts chime in?

Thanks,
-mike

-- 
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/