(Actually it would be preferable to move cs:et-al, and a new cs:and
element inside cs:name itself, but we can discuss that when we dig
into this in earnest.)
Agreed this makes more sense. But clearly something for CSL 1.1.
My main objection (other than
that delimiter-precedes-last functions fine in CSL 0.8) is that you’d
confuse the concept of affixes. When not defined on an attribute,
should not be applied.
The same would be true here. The single/multiple special prefixes
would be available only on the special elements, like cs:et-al. On
those elements, if no value is given for prefix, prefix-single or
prefix-multiple, you get no prefix on the element.
The “prefix-single” and “prefix-multiple” attributes
don’t offer context-dependent formatting, and I think it’s confusing to
contextual prefixes by default.
The single/multiple attributes would indeed provide context-dependent
formatting: on cs:et-al, if the element is preceded by a single name,
use prefix-single (or prefix, if that’s set instead); if it’s preceded
by multiple names, use prefix-multiple (or prefix, if that’s set
Ah, yes. Sorry. So my main objection is that, if a style author wants to
italicize the et-al term, (s)he shouldn’t have to specify affixes (or
prefix-single/multiple attributes) just to keep existing behavior. E.g.
should behave the same (apart from the italics), and both should offer
Hmm … with respect to contextual prefixes, did you mean to say that
it’s confusing not to have contextual prefixes by default? If so, I
take your point; with your proposal, default prefix behavior of
cs:et-al could be aligned with the current implicit default, and that
would be a very good thing.
This thread is getting confusing, but I think I agree :).
Would a consequence of your delimiter-precedes-et-al proposal be that
the prefix attribute becomes unavailable on cs:et-al? That seems to
be the logical outcome, but just to confirm.
Affixes are also unavailable on cs:name-part, which is somewhat similar. So
I think we can scrap them from cs:et-al as well.
Now that I’m persuaded … and if it’s right that the prefix attribute
of cs:et-al will be dropped to make room for delimiter-precedes-et-al
… would it make sense to amend the specification now, and align the
behavior of cs:et-al with the implicit et al. term?
RintzeOn Fri, Apr 30, 2010 at 11:57 PM, Frank Bennett <@Frank_Bennett>wrote: