any chance for finer grained "csl- " classes in the citeproc-js output

Hi all,

I'm experimenting with using Zotpress to populate library research guides. One of the things that I would like to be able to do is to use CSS to alter the appearance of zotpress citations.

Could there be a way to adapt the HTML output to make that easier? Citeproc-js gives classes down to the "csl-entry" class but nothing finer grained than that. Could it go down to having classes for each CSL field? That would give us a lot of flexibility to adapt the output to a number of different needs, even beyond what a custom citation style would do (though I'll likely make one too, to choose exactly the csl fields I'll need).

Thanks,

Larry
  • Preparing a custom style is the way to go. I don't think we'll be applying classes to HTML output below the block level in the foreseeable future.
  • But custom styles can't yet be used with the Zotero API and thus with Zotpress.
  • You've got a point there. I suppose that field-level wrappers in HTML output might come along eventually, if we make a push for RDFa support. But I'd expect style selection in the API to come well before that. It would be pretty complicated to implement (bug-inducing complicated), and is only relevant for HTML output.
  • and is only relevant for HTML output.
    I would submit that "only relevant for HTML output" is actually quite a big relevancy. The easier it becomes to cite stuff from within Zotero libraries across the web, the more important it becomes to present the information in a semantically transparent way and to have control over styling. ZotPress suddenly makes it trivially for many users to generate online bibiliographies; I think it would be great if this spurred development of ways to present citations in semantically transparent and CSS-stylable ways.
  • I agree that HTML is important, and that the potential for automated citation tools like citeproc-js to feed on and reinforce linked data is an exciting prospect. If you like, I'll happily retract the "only relevant to HTML" throwaway comment. It's enough to say that this would be very complicated to implement, with only modest benefits -- with CSS you would only be able to change typefaces and hide things and whatnot. A custom style, on the other hand, gives you all the power of CSL to play with, and it's already there.

    I'm certainly not against the Web or anything. :)
  • Worth noting that the Zotero API currently supports only HTML bib output, so milliken probably can't just use a custom style, since that would just produce HTML-encoded HTML markup within citeproc-js's actual HTML markup. Either the Zotero API would have to offer the plaintext output from citeproc-js or Zotpress would have to offer a mode to treat the encoded HTML as HTML code itself. And unless I'm overlooking some feature of CSL, I believe in either case there's a potential security vulnerability: since citeproc-js wouldn't be operating in HTML mode (or at least treating the custom markup as HTML), field values could contain HTML markup that couldn't be differentiated from the custom HTML in the style, which could open up the door to XSS attacks if the extracted HTML wasn't run through something like HTMLPurifier. The alternative would be for a custom style to use some arbitrary non-HTML markup that Zotpress turned into valid HTML, but that's getting pretty hacky.

    This isn't really limited to CSS. This is about proper semantic structure, and the ability to style it would just be a benefit. None of this changes that this might be difficult to implement, but it does seem like it would be good to have, and there aren't great workarounds.
  • @frank, I understand that it is complicated and certainly didn't want to retract from that. I was attracted by semantic transparency first, and only secondarily by styling possibilities with CSS — much like what Dan says above.
  • If the API could provide citeproc-compatible JSON for items (how hard could that be?), then citeproc-js could be used by API consumers (i.e., Zotpress) to use custom CSL that is not in the main repository (and you don't want site-specific CSL in the general repository). Zotpress could embed citeproc-js in the page (probably not worth the overhead), or call a local citeproc-node instance (and probably cache the rendered output).

    This still doesn't get us a citation-element-level metadata, but I think it's good enough to attach something like BIBO RDF to the citation's outer container-- much of the citation information might not even be included in the rendered citation anyway.
  • The alternative would be for a custom style to use some arbitrary non-HTML markup that Zotpress turned into valid HTML, but that's getting pretty hacky.
    This isn't really limited to CSS. This is about proper semantic structure.
    ... much like what Dan says above.
    "Uncle."
  • Thanks for considering this. In the meantime I'll play with a custom csl and see how close that will get me.

    Larry
  • (Sorry, as a non-native I don't get your reply Frank, so I can't compute whether it is irony, a cultural reference, or something else. As I'm a linguist I'd like to know :) )
  • I was wondering that myself as well. But the internet saves the day: http://idioms.thefreedictionary.com/say+uncle
  • If I had to guess based on previous discussion, I'd say it's just not easy for Frank to add this now, since the current design essentially treats output as a presentational string.

    FWIW, I've started to write a bib profile that I think should be usable for both RDFa 1.1, and HTML5 microdata. In both cases, one is wrapping metadata chunks in HTML nodes, and attaching attributes to add semantics.
  • edited August 18, 2011
    [T]he current design essentially treats output as a presentational string.
    That's not entirely accurate [please apply English rules of intepretation]. The relevant discussion can be found in this thread on zotero-dev, and in this one on xbiblio-devel.

    The citeproc-js code base is not necessarily easy to follow, but it certainly doesn't treat output as a string internally. CSL 1.0 could not be implemented by a system that did so.

    A set of worked examples, preferably cast as test fixtures, would be helpful. It all seems particularly daunting when there are no concrete examples on which to base queries from my end.
  • Well, there are two cases:

    What the OP is asking for (I think), which is just having class names on output tokens. For this, it should be straightforward to just dump the relevant variable names on the output nodes.

    Microdata and RDFa is a little more complex, but I think it's probably best to iteratively build this, and worry less about some of the more difficult/less-frequently-used variables. I've started to create examples here, but I know there's a lot more to do:

    http://bdarcus.github.com/bibo-in-html/examples
  • edited August 18, 2011
    What happens for names that are concealed by et al. (Edit: and the full form of names that may be masked by initialization or short-forming)?
Sign In or Register to comment.