right, what Frank says is the broader answer to your question. As both me and Bruce said in the original thread, the issue is not that this isn't an understandable and relevant request, but that the CSL specifications aren't the right place for it. This needs to happen in the various processors, some of which, as Frank points out, are well set-up for this.
My guess would be that with three flags, something like "hyperlink_title," "hyperlink_DOI," and "hyperlink_URL" you'd have most bases covered. As for the escaped/unescaped html in affixes: The original poster had html in affixes, so I assumed he was happy with the output. My suggestion was just a tweak on something he posted and I was quite clear that I didn't consider it a general solution. On Thu, Jun 12, 2014 at 4:24 PM, Frank Bennett <biercena...@gmail.com> wrote: > Christoph, > > That's right. Any text that reaches the processor through CSL code will be > escaped according to the output format. The only way to do this through CSL > markup is what you have been doing (i.e. setting a slug in the CSL, and then > replacing it in each citation after it is rendered). > > Adding wrapper markup is currently out of scope for CSL proper, but > processors may offer their own hooks to accomplish this. If you're running > citeproc-node, you'll be running citeproc-js, which could be extended to > support field-level wrappers with a small amount of work, thanks to > groundwork done to support Steve Ridout's work on the CSL Visual Editor. > > The business end of the hook is in formats.js, in the "@showid/true" > function: > > > https://bitbucket.org/fbennett/citeproc-js/src/0948536cb1b541aea81b2b94ba98682c8692bcf6/src/formats.js?at=default#cl-112 > > As you can tell from the source, this is currently just hard-wired code that > sets a span on the output. The span is used in the Visual Editor to navigate > from an element in a rendered citation back to its source in CSL code. It is > enabled by a processor option (csl_reverse_lookup_support), which (unlike > other options) must be set in the source code itself, _before_ building the > engine: > > > https://bitbucket.org/fbennett/citeproc-js/src/0948536cb1b541aea81b2b94ba98682c8692bcf6/src/formats.js?at=default#cl-112 > > We can exploit this code to support your use case (which I'm guessing will > be very popular once supported). I think the way to do it would be to > provide a hook on the processor that registers a callback to add a wrapper > according to your preferences, based on the item data and the context of the > item. > > Does that sound like it would be useful? > > Frank > > > > > On Fri, Jun 13, 2014 at 12:53 AM, Christoph Bersch <use...@bersch.net> > wrote: >> >> >> Zitat von Sebastian Karcher <karc...@u.northwestern.edu>: >> >> >> The solution provided by Sebastian doesn't work, because it is invalid >> >> XML (using prefix="<a href='"). >> > This is mainly a technical discussion list for an XML based format, so >> > I assume people know how to escape XML. See e.g. >> > http://www.freeformatter.com/xml-escape.html >> >> I know how to escape XML, but not how escaping in this specific case >> would solve the problem, i.e. get a valid <br/> tag after processing. >> Using e.g. citeproc-node with something like suffix="<br/>" for >> testing, gives me <br/>, which is a verbatim <br/> and not a >> line break, what one would need. >> >> Christoph >> >> >> >> ------------------------------------------------------------------------------ >> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions >> Find What Matters Most in Your Big Data with HPCC Systems >> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. >> Leverages Graph Analysis for Fast Processing & Easy Data Exploration >> http://p.sf.net/sfu/hpccsystems >> _______________________________________________ >> xbiblio-devel mailing list >> xbiblio-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > xbiblio-devel mailing list > xbiblio-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > -- Sebastian Karcher Ph.D. Candidate Department of Political Science Northwestern University ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ xbiblio-devel mailing list xbiblio-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
