Multiple-item "type" conditionals with match="all"

Andrea Rossato recently identified a discrepancy between the CSL spec
and citeproc-js. While the spec describes match=“all” to be the
default for conditionals, citeproc-js uses “any”. See and
for more details.

Since most CSL styles have been developed against citeproc-js
implementations, this has gone unnoticed for quite some time.

I would prefer to keep “all” as the default, if possible. For the
short term, I fixed styles that used the “type” conditional to test
for multiple item types without setting “match”. According to the
spec, such conditionals should never test true, and so I’ve added
match=“any” to these cases:

We can probably expect some changes in citeproc-js output if it
changes its behavior. I’ll think about it a bit more to see if we can
modify the existing styles to prevent that from happening.


CiteProc-Ruby uses ‘all’ as the default – in this respect, perhaps the spec should explicitly define what the edge cases are, particularly what happens when there are no conditions. This seems fairly important to me. For example, in the Ruby implementation we’re assuming that:

all + no conditions --> true
any + no conditions --> false

This is particularly important, because we handle ‘else’ like a regular ‘if’ node with no conditions (in fact, both if and else nodes are mapped to a conditional node internally, so the processor does not need to distinguish between the too).

Note that the assumptions above are based on predicate logic (universal quantification over the empty set is always true). Furthermore, the fact, that this yields the ‘logical’ implementation of the else node above is a strong indication that it does indeed make sense to keep ‘all’ as the default.

cs:if and cs:else-if elements require at least one condition. The CSL
schema checks for this.


True : ) that takes care of the edge cases as far as the specification is concerned.

Nevertheless, it wouldn’t hurt if implementations agreed to apply predicate logic there.

Dear all,

I’m very sorry for this misstep. The default to “any” was coded into
citeproc-js before the specification existed, without sufficient

I set “match” to “any” in what should the remaining problematic cases:

Related Python script update (don’t look if you’re a
professional/experienced programmer!):

Frank, I think now is as good a time as any to change the “match”
default in citeproc-js to “all”.


Sebastian: You might see a rise in complaints about things going
missing from citations when a change in the default works its way into
official Zotero. Okay to go ahead?


sure. But what’s the current status of Zotero auto-updating styles? I
thought that was happening now - Dan?
If that’s the case we should be mostly good anyway.

Currently only the bundled styles are updated, and only when Zotero is
upgraded. Auto-updating of all installed styles is in 3.1, which should
be out by the end of the month.

Does CSL allow for inputs to contain any formatting markup?

For example, given this BibTex title:

title = {Distribution of \textit{Culicoides} Latreille (Diptera:
Ceratopogonidae) in Saudi Arabia}

Docear4Word contains a BibTex parser that will strip out all the braces and
formatting directives before it gets passed to CiteProc.js but the user
would like to have the word ‘Culicoides’ in italic regardless of the CSL
style being used.

I can change the parser to replace \textit{…} with any markup but I don’t
believe CSL supports this.
I am guessing that even if I use HTML markup and ask for HTML output then it
is likely to be escaped before it comes back (haven’t actually tried this)

Can someone confirm this isn’t possible?


The processor recognizes the markup described here:

It looks like HTML, but it’s converted in the output.

See also

The tag has since been deprecated in favor of the more standard
, but citeproc-js supports


Zotero does convert BibTeX markup for the supported HTML and Mendeley was
at least talking about implementing that, too - not sure if they did.

Zotero does convert BibTeX markup for the supported HTML and Mendeley was at least talking about implementing that, too - not sure if they did.

Our current plan is to formalize the XHTML subset that is supported
inside various metadata fields which will initially be quite minimal.
We have discussed converting TeX markup during BibTeX import but have
not implemented this yet.