In thinking about how to allow users to make specific changes to a
citation style format within Zotero (which seems like good
functionality to have), is this really possible with the current
version of CSL? Or is local customization of CSL files the wrong
It’s the wrong approach in my view.
One option might be to duplicate a base CSL (Chicago, say), bring up
the options in a generic CSL editor, then ask the user to configure
the punctuation (or whatever) to according to the user’s wishes, then
output a new CSL file, essentially written from scratch by the UI.
That’d be my preference, where those base styles are composed of a set
of macro components. Max’s interface can be nicely extended along
Providing that any UI can make a nice CSL (still undecided, i think),
this would be considerably easier than editing an existing file. But
the problem here seems to be in parsing a CSL file and translating it
into a decent UI that is structured the way a user is likely to think
about styles (who i presume is rather uninterested in the language
that creates the styles). I say this is a challenge because it seems
that good UI will be in line with how users think of styles (i.e.
itemTypes, as in “i want to format pre-modern manuscripts like THIS,
and encyclopedias like THIS”, etc. and which is also how journals,
presses, etc. provide citation examples to readers),
I’m really not convinced about this assumption. I think it just as
likely that users and style writers think in terms of generic rules,
with type-related exceptions/modifications. With Max’s UI, for
example, adding previewing would go a long way to making it easier to
but a good CSL
creation UI, i think, will need to be in line with how properly-done
CSL files are organized, which is in terms of macros, groups, etc.
I believe that’s right.
I’m finding in quite difficult to translate between the two.
Rather than note this in the abstract, it might be more useful to
identify particular issues in existing interface efforts like Max’s?
Another option might be to duplicate the Chicago CSL file and add to
it the block to handle the new itemType. This obviously
degrades the quality of CSL per the original intent of the language.
But it often seems to me that the original goal of CSL was to design a
syntax and structure that prioritized economic markup over easy
editing and augmenting by a wide user base.
Not exactly “economic markup” for its own sake, but rather to allow
the styles to be made in such a way that they are robust. E.g. they
should work at least well in cases where there are no explicit
instructions for a given type.
Type-based formatting languages, by contrast, tend to be pretty
fragile, forcing users to regularly edit styles.
Another option in the same vein is to move away from the intricate
macro oriented approach of CSL files and favor organizing CSL files by
itemType. While not as elegant and certainly more repetitious than CSL
as now implemented by Zotero, a more explicit definition of styles may
have the advantage of being easily edited by the average user with an
intuitive UI, who could augment and modify citation styles at the item
I think before you go through all of this, you really need to spend
some time with Max’s prototype and consider how it can be improved.
Once we all agree that approach has been exhausted, we might consider
other options. But I think copying Endnote’s approach to styling is a
really bad idea.
Even if we have a good makeCSL-like tool for creating new CSL files,
it seems that local and specific customization would always be nice to
provide to the Zotero user. So, to echo my initial questions, is user
customization really possible with the current version of CSL? Or is
local editing of CSL files the wrong approach? Or am i making improper
assumptions about editing a complex CSL file?
Hopefully the above comments give my answer to this.
Keep in mind that my goal with CSL is to have something like BibTeX
for the 21st century. My goal is that in five years, say, one never
has to think about citation styling; that there are thousands of
styles easily available on the web, and that one can use those styles
in dozens of applications.
Zotero is just the first (absent my early prototypes), but we now have
people working on CSL processors for Python, Ruby and Haskell, in
version will get updated as well.
So I think carefully building this infrastructure out has some value,
even if many users are currently frustrated by not having infinite
flexibility (which, as I hint above, has its own costs).