I presume that’s the more important point, and that the fixed-width
character of the preceding content (the label) is a consequence of
Yes. So could this be marked with something like display=“label”?
What rendering would that trigger?
A label should float to the left of an inline-block that follows it,
and should have the same width as other labels in the bibliography.
So it should have a negative indent?
No. Not in CSS, at least. A negative indent of an inline element
would align a column of such elements on their right edge, which would
be wrong for labels.
But the choice between “indent” and “float” is an implementation
detail, which may vary between output languages. Currently, Zotero’s
CSL processor does second-field-align as a table in HTML, and as a
list of labels with block-tab indents in RTF. CSL doesn’t need to
know anything about that choice. But CSL does need to be able to
describe the elements of the layout to the client’s rendering engine.
I’ve already boiled down what’s needed for that description.
Bibliography layouts can be described with four elements. I’ve called
them “heading”, “left-label”, “item” and “block-indent”. They don’t
have to be called by those particular names in CSL, and they don’t
need to be assigned through a class= attribute. But there must be a
minimum of four different layout elements, and it should not be
exceptionally difficult to assign portions of the output to them.
Any solution should be supported, at minimum, by worked examples of
how CSL elements are mapped to each of the four parts of a layout, as
I have done here:
OK, so let’s try to break this down in ways that we can feed into the spec.
The display logic of CSL is based on a small subset of CSS [ref
http://www.w3.org/TR/CSS2/visuren.html#display-prop]. The normal
display rule is that a content node is rendered inline. Exceptions can
be configured using the “display” attribute, which includes the
block: this causes a content node to render as a block separate
from the main item content. For example, if one wanted to have an
annotation note on a separate line for an annotated bibliography, one
could assign this display value to a “annote” cs:text node.
inline-block: this causes a content node to render as a block
inserted into the item block. Effectively, this will shift the margin
for flowed content to align with the first line of this node. [ this
is HARD to explain; also, need an example]
We run into this in comparative law a lot, actually, where concepts
from different legal systems have similar functions and the same name,
but slightly different meanings (“mortgage”, “heirs”, “trust”). It’s
an endless source of confusion, caused by overcrowding in the
namespace. We’re not bound by the constraints of legal tradition
here. If it works differently, we can and should call it something
different, to reduce the potential for confusion.
The original CSS inline-block display property only has meaning when
applied to elements that have a fixed width. It’s used to produce
flowed layouts composed of boxes containing their own formatted
content, like this:
A CSS inline-block MUST be assigned a fixed width, or it will behave
exactly like a normal block, and consume all available horizontal
space. What you are calling an “inline-block” above is something
else. In CSS terms, it’s just an ordinary block, indented by a
specified amount. To create it, you need to know the indent
OK, now we have this indenting problem. Labels may need to be negative
indented, and other content, including inline-blocks, may need to get
positively indented in complex ways (alignment and such). I have
- indent: when coupled with block or inline-block, indents the content
So the problem: it’s too vague; we don’t say how much to indent, nor
allow it to be configured.
It’s only vague if you assume that the CSL markup needs to say
something about this dimension. But it hasn’t done so in the past,
and it needn’t do so here.
CSL can’t know specific dimensions, because it doesn’t know the sizes
of the fonts involved. What it can do, though (and what it already
does in the Zotero implementation for RTF output, I believe) is to
measure the maximum number of characters in the label, and pass that
through to the calling application, separately from the output
strings. The max-width number is then used by the calling application
to compose a class description, which it will apply to the four
elements out of which the layout is composed.
If we add the ability to specify a value (including a negative value),
then we’re stuck with defining what those values should be.
As outlined above, we don’t need to do that.