Export to HTML: where does the embedded CSS come from?

svictor
When I export a reference in HTML, it is wrapped in div tags. These have CSS classes but also CSS properties "hard-coded" inside the tags. I'd like to get rid of those, or at least be able to control them.

For example:
<div class="csl-bib-body" style="line-height: 1.35;">
<div class="csl-entry">
<div class="csl-block">AUTHOR</div>
2004 Title, publisher, etc
<div class="csl-indent" style="margin: .5em 0 0 2em; padding: 0 0 .2em .5em; border-left: 5px solid #ccc;">Abstract</div>
</div>
</div>

I know that the classes depend on the CSL display property. But I can't get rid of things like style="line-height: 1.35;" or style="margin: .5em 0 0 2em; padding: 0 0 .2em .5em; border-left: 5px solid #ccc;" These restrict pretty much the use of the classes, since "hard-coded" properties override any instructions in the CSS file of the website. In other words, one cannot change, say, the line-height of csl-bib-body, or the padding of csl-indent, because their css values in the div tags take precedence over anything else.

I tried exporting through drag-and-drop and also through menu "Create Bibliography from Item": same output.
I looked for a setting to disable css styling but couldn't find one. And also no answer on google, although I suppose it's a fairly basic question... Any hints ?
  • Simon
    edited June 18, 2013
    There's no option to control this, but you can override the style attribute in your CSS file using !important declarations, or you could use a regular expression find/replace to remove the style attributes.
  • svictor
    Thanks Simon! I had forgotten about !important declarations. That will do for now. (Find/replace is not a convenient option in my case.)

    As I understand it, the CSL standard offers the flexibility of bare CSS classes, and to that Zotero adds its own ideas about how the biblio should look? If so, it seems like a wrong choice to me. What would be the bast place to ask for a change?

    Thanks again for the tip: it solves my problem for now!
  • dstillman
    First, classes aren't specific to CSS. They're a generic way in HTML to identify blocks of content. A class itself doesn't tell anything about how to style something unless there's a stylesheet that references it, and you can only attach stylesheets to complete HTML documents. Since Zotero outputs HTML snippets that will likely be embedded in larger HTML documents, there's no way for it to include a separate stylesheet, and people who get HTML output from Zotero can't be expected to go separately download a stylesheet from somewhere and configure their website to serve it in its <head> block. And Zotero's job is to produce output that will look like what the individual style guidelines call for, so CSS rules need to be included one way or another.

    If you want to override or strip the inline CSS, you have multiple of ways to do that. But Zotero is doing the only thing that makes sense for it to do.
  • dstillman
    edited June 18, 2013
    (Actually, HTML5 does introduce scoped stylesheets, which would be something we could consider using in the future, but browser support for those is still very limited. And it'd still be something in the output that you'd have to strip or override.)
  • svictor
    Thanks Dan.
    I'm well aware of what CSS is. But you seem to only consider the case of a user exporting to a website where he/she has no admin rights. In that case, you're right: the user can't do anything about the css stylesheet. Note however that such users typically don't paste from zotero into plain text editors: they interact with wysiwig interfaces like TinyMCE. So they have all kinds of buttons to customize the appearance of the output as they like. And even if they were to rely entirely on Zotero, it would make sense to offer them some way to tell the software what it should output: say, indented abstracts but without the grey border-left (which seems to be mandatory as of now).

    My problem, however, is as a webmaster. It's a pity that I have to undo in the stylesheet what Zotero does automatically. At least there should be an option in the export prefs to include or not CSS styling. As you certainly know, the whole idea behind css is to separate the contents of the webpage from the way they look on screen.

    Note that there *is* a way for Zotero to respect this principle and still include something like its own stylesheet: simply put its attributes inside a <style></style> element at the top of the html export. This way, the user who doesn't want these styles can easily delete them, or change them in one place for his/her whole export. Of course, he/she would have to open the html editor of TinyMCE to do that. But then, a user who doesn't want to go that technical resorts to the wisywig features of the editor anyway.

    So the proposal is:
    - keep only the css classes in the divs;
    - wrap the CSS attributes inside a single <style></style> element at the top of the export;
    - offer an option to not output this element at all.

    This seems like a cleaner way to go, offering just as much functionality for the end user, and simpler to maintain for the webmaster.
  • dstillman
    But you seem to only consider the case of a user exporting to a website where he/she has no admin rights.
    No, I'm saying that embedding a bibliography from Zotero shouldn't be a two-step process that can only be done by people who know how CSS works.
    Note that there *is* a way for Zotero to respect this principle and still include something like its own stylesheet: simply put its attributes inside a element at the top of the html export.
    That would be an option for the "Create Bibliography from Current Item(s)" menu option, which generates a full HTML document—but it'd likely be a bad option, since who knows what happens in various editors when you paste a full HTML document with a <style> block into a larger document. With inline CSS, even if it strips everything outside <body>, the output looks correct.

    And it wouldn't be an option for Quick Copy export, which generates only an HTML snippet. If Zotero is exporting a <div> as the root element, we can't just put a <style> element above it, since it would be invalid, and many people who tried to embed the HTML wouldn't know that. That's what I was saying about the scoped HTML5 stylesheets. Again, when support for those becomes widespread, we might consider using them, because people would then still be able to copy and paste the output anywhere and have it do what they expect.

    Just to step back a little, I think part of the issue here is that you're focusing on one or two specific presentational things—like the grey line next to abstracts (which I'm not even sure comes from Zotero—that might be from the citation processor)—and ignoring the fact that most of the things that Zotero is adding aren't its own "ideas" about how things should look. They're the style's ideas about how things should look. As I said above, it's Zotero's job to produce output that looks the way the style guides want it to, and spacing and indenting—which are controlled by these CSS rules—are a big part of that. The inline CSS can even include things like small-caps, which a few styles call for. Without most of these things, the output is just incorrect. Not different from our preferences, but incorrect.

    (There are also various technical concerns here. Some of the style rules come from the citation processor and some come from Zotero. There would likely need to be many more classes added to the markup in order to convey all the style information that the inline CSS can contain. Zotero can put rich text (in the form of HTML) on the clipboard, and that HTML almost certainly has to have inline CSS to render properly in various programs. Basically, any changes here would make Zotero's citation handling code much more convoluted for very little benefit.)

    Our primary concern is for things to just work for the majority of users, without their having to know what a <style> block is or where it's valid. Inline CSS accomplishes that. If there are specific style choices you don't like, you can override or strip them. That's what !important is for.
  • svictor
    Hi Dan,

    I thought it was valid to use «style» outside the «head» but you're right, for that we need "scoped" and HTML5. In my experience it's already well supported but I understand that you prefer to wait.

    I think part of the issue here is that you're focusing on one or two specific presentational things—like the grey line next to abstracts (which I'm not even sure comes from Zotero—that might be from the citation processor)—and ignoring the fact that most of the things that Zotero is adding aren't its own "ideas" about how things should look. They're the style's ideas about how things should look.
    I'm talking about the style attributes which are not set in the CSL, and are actually not even part of the specification. I can set the css class in the csl style, but the grey line, the padding, the margins all seem to come from Zotero. Now you say that it is more complicated than that

    Some of the style rules come from the citation processor and some come from Zotero.
    My knowledge is clearly too limited here. I'm not using any word processor plugins, so I thought I was using just Zotero. Could you please clarify the distinction between Zotero and the citation processor?

    Our primary concern is for things to just work for the majority of users, without their having to know what a «style» block is or where it's valid. Inline CSS accomplishes that.
    Your concern is perfectly right. But inline CSS accomplishes that or not, depending on the way the website is set up. For example, the wysiwig editor on the website may have been configured to strip away inline CSS. This is the case on the websites I have to administrate, because it is important that we retain the same visual appearance throughout the site, despite the many contributors. There is an option in the editor we use (JCE, based on TinyMCE) to remove direct formatting on copy/paste. It converts the styles to standard html tags (title1 --> h1 etc.) or to csl classes. It removes everything inline. Users have a dropdown menu with available css classes to choose from if they want to further customize their posts. This helps in maintaining the appearance of «h1»,«p» and other basic elements accross the webiste. We need it because otherwise copy/paste from word processors is just a mess. We don't want the font, size, color of the pasted texts to be determined by the various settings people have in their word processors.
    Drag-drop from Zotero behaves weirdly because the first insertion bypasses somehow the stripping process and retains the inline css. It looks nice. But then, if you take what you just pasted and move it somewhere else, it looses all its inline CSS (--> ugly). The users don't understand why. They know that some styling may disappear when they paste to the website, but they don't expect this to happen inside the website itself. It's possibly a bug with the editor, as it should strip the css from the start. Or maybe there's something special in the drag-drop, because the stripping works well with the other sources we use (internet and word processors). So for example if I export from zotero to an html page and copy-paste from there, inline css is stripped from the start. If I drag-drop directly from zotero into JCE editor, the above behavior occurs.

    Anyway, this is a different problem. I mentioned it just to illustrate the limits of inline CSS: its behavior depends on how the wysiwyg editor is set up, and there is a logic to have it remove all direct formating on copy-paste.

    I'm ok with using !important for now, so my problem is solved. I still can't see it as anything else than a workaround. Even if we have to do with inline CSS, we should be able to customize it somewhere. There is no control in CSL for the padding, margins, grey border. So it must be set inside Zotero, or in the citation processor if that's another piece of software.
  • dstillman
    I thought it was valid to use «style» outside the «head» but you're right, for that we need "scoped" and HTML5. In my experience it's already well supported but I understand that you prefer to wait.
    Given that you didn't know that "scoped" was necessary, I'm not sure what experience you're referring to, but it's not supported anywhere other than in Firefox 21. Just including <style> in content is invalid and will remain so.
    Could you please clarify the distinction between Zotero and the citation processor?
    citeproc-js, which Zotero uses to generate citations, is a separate project, now used by other citation management programs. There's internal communication between Zotero and citeproc-js.
    But inline CSS accomplishes that or not, depending on the way the website is set up. For example, the wysiwig editor on the website may have been configured to strip away inline CSS.
    True. But, as you say, that's a different problem. Having a separate stylesheet wouldn't help with that, except to the extent that there'd be a copy of necessary CSS rules for a given CSL style. But that wouldn't help end users at all, and if you're a website admin, you can just write those rules once for whatever CSL style your users use and be done with it. The whole point of this is that the rules differ for different CSL styles.
    There is no control in CSL for the padding, margins, grey border. So it must be set inside Zotero, or in the citation processor if that's another piece of software.
    Again, the grey border is a corner case. The rest comes from the attributes in the CSL. You're not setting CSS classes in the CSL, obviously, but things like hanging indent, line spacing, and second-field-align are controlled by CSL properties. citeproc-js communicates those to Zotero internally and Zotero adds the necessary inline CSS (if it's generating HTML—if it's generating RTF it does different things).

    (And then a few other things, like small-caps, are embedded directly by citeproc-js instead of Zotero.)

    Anyhow, I don't really have time to discuss this further, but you're welcome to look at the Zotero-side code for this if you're curious. (Don't get too excited by that inlineCSS = true flag, though. If that were set to false, the output would just be incorrect for most styles, as I've said.)
  • svictor
    Ok. Thanks for all this!
Sign In or Register to comment.