I’m again not sure if stuff is getting through to the list. Anyway, I’m
just about wrapped up with the schema rewrite I think. See repo.
I’m contemplating adding back a root attribute I had at the very
beginning: class.
So it would be:
cs-class = attribute class { “author-date” | “number” | “label” |
“note” | “custom” }
Each class would carry with it some default assumptions:
author-date===========
sorting keys are author-date
author substitutions are: periodical title (and equivalent), title,
anonymous
also: author-year disambiguated using year suffixes
number
sort can be either “cited” or "author-year"
substitutions probably work the same
label
sort either “label” or “author-year”
All of the above require citation and bibliographic elements
note
bibliography is optional; if present use author-year rules
custom
assume nothing
Any objections to that?
The logic is that CSL allows custom sorting and substitutions, but it
doesn’t require it of either style authors or software implementors.
Bruce
Hi Bruce,
I’m again not sure if stuff is getting through to the list.
Sorry, the list probably works okay now (your mail did come through)
but I’ve been a bit quiet, because your questions are pretty difficult
at times. 
Anyway, no objections to the class tag. Sounds pretty straightforward to me.
About the annotated bibliographies: assume note and abstract are
blocks sounds reasonable to me.
That makes me think though, me now use an attribute for prefix and
suffix. What if a prefix or suffix needs a newline? I don’t think it’s
possible to enter an enter in an attribute right? But making it a full
element seems a bit too much too. Perhaps we could use \n for this
purpose?
I like the new sort element.
I hope that this is at least somewhat useful to your questions.
Bye,
Johan
Sorry, the list probably works okay now (your mail did come through)
but I’ve been a bit quiet, because your questions are pretty difficult
at times.
I was mainly confused because I wasn’t seeing my posts in the archive
either.
Anyway, no objections to the class tag. Sounds pretty straightforward
to me.
OK.
About the annotated bibliographies: assume note and abstract are
blocks sounds reasonable to me.
OK.
That makes me think though, me now use an attribute for prefix and
suffix. What if a prefix or suffix needs a newline? I don’t think it’s
possible to enter an enter in an attribute right? But making it a full
element seems a bit too much too. Perhaps we could use \n for this
purpose?
This is one of the reasons I was asking the question.
My guess is it’s probably best to use the unicode entity for the
newline (don’t remember what it is though!), though hopefully it’ll be
uncommon that people will need it.
Bruce
So long as we clearly define the behavior of each class and provide a fully
featured “custom” option, the class attribute sounds good to me. It may be
worth formalizing the definition of the various classes by demonstrating the
markup one would have to add to the CSL file to achieve the same behavior
with class=“custom”.
Simon
Looking at the class attribute on the group element, this appears to
be the last item (now that font-family has been dropped) that accepts
a free-form argument.
Should there be a fixed set of possible class names for this attribute?
If so, would anyone like to propose an initial list of possible names?
Frank
It might be fine with dropping the attribute at this point.
Looking at the class attribute on the group element, this appears to
be the last item (now that font-family has been dropped) that accepts
a free-form argument.
Should there be a fixed set of possible class names for this attribute?
If so, would anyone like to propose an initial list of possible names?
It might be fine with dropping the attribute at this point.
I think you suggested on a Zotero thread that moving toward classed
groups would relieve some of the pressure to create dedicated options
to support idiosyncratic bibliography formats. The leading example is
our old friend the American Anthropological Association (?):
But, for HTML output at least, the necessary effects for that one
should be within the reach of CSS, with a few supporting hints via
display=“block” and display=“inline-block”. As far as I can see, it
would be fine to remove it … oops, BUT …
A check of the repository shows that is used in 67
styles. Extracting the arguments, it looks like it always has one of
two values: container or containter-title [sic].
From the consistency of usage and that spelling error, I guess it must
either have been in some early style code that’s been copy-pasted a
lot, or Zotero output contains CSS that supports those particular
class names, and the HTML output depends on it.
Not sure what happens next. Maybe someone from Zotero can tell what’s
likely to break of this were to go away?
Frank
appears in only two styles, both
committed by the same user, so that can obviously be ignored.
appeared in the first two styles added to
Zotero, APA and Chicago, so Frank’s copy-and-paste hypothesis sounds
about right.
I don’t see any references to “container” in the CSL or integration
code, either now or in the earliest versions. So, Simon can correct me
if I’m wrong, but I suspect it has no effect whatsoever.
A check of the repository shows that is used in 67
styles. Extracting the arguments, it looks like it always has one of
two values: container or containter-title [sic].
From the consistency of usage and that spelling error, I guess it must
either have been in some early style code that’s been copy-pasted a
lot, or Zotero output contains CSS that supports those particular
class names, and the HTML output depends on it.
Not sure what happens next. Maybe someone from Zotero can tell what’s
likely to break of this were to go away?
appears in only two styles, both
committed by the same user, so that can obviously be ignored.
appeared in the first two styles added to
Zotero, APA and Chicago, so Frank’s copy-and-paste hypothesis sounds
about right.
I don’t see any references to “container” in the CSL or integration
code, either now or in the earliest versions. So, Simon can correct me
if I’m wrong, but I suspect it has no effect whatsoever.
Yay. Maybe I should stop messing around with inline markup and
talking out the side of my mouth, and see if it really is possible to
produce the AAA layout with the other markup we have available.
A check of the repository shows that is used in 67
styles. Extracting the arguments, it looks like it always has one of
two values: container or containter-title [sic].
From the consistency of usage and that spelling error, I guess it must
either have been in some early style code that’s been copy-pasted a
lot, or Zotero output contains CSS that supports those particular
class names, and the HTML output depends on it.
Not sure what happens next. Maybe someone from Zotero can tell what’s
likely to break of this were to go away?
appears in only two styles, both
committed by the same user, so that can obviously be ignored.
appeared in the first two styles added to
Zotero, APA and Chicago, so Frank’s copy-and-paste hypothesis sounds
about right.
I don’t see any references to “container” in the CSL or integration
code, either now or in the earliest versions. So, Simon can correct me
if I’m wrong, but I suspect it has no effect whatsoever.
Yay. Maybe I should stop messing around with inline markup and
talking out the side of my mouth, and see if it really is possible to
produce the AAA layout with the other markup we have available.
The attached file “aaa-sample.html” is done using only DIV tags and
appropriate CSS properties. The structure, at least, could be
produced with current CSL, using subsequent-author-substitute=“”
together with display=“block” and display=“inline-block”.
But a glance at the HTML shows that, although quite a few tweaks are
necessary on individual elements to get the formatting right. A
couple of the values (the widths of the two inline blocks) are context
and style dependent, but cannot be reliably deduced during CSL
processing.
aaa-sample.html (2.56 KB)
So what exactly are you proposing?
Bruce
Still just thinking out loud, but:
(1) Drop display=“block” and display=“inline-block” from the schema.
(2) Retain the attribute.
(3) Limit the permissible values to class= to the following tentative list:
– csl-subheading
– csl-label
– csl-item
(4) Provide documentation on the three classes above in (or with) the
schema. Illustrated examples similar to those provided in the CSS
specification docs would make things clear enough for implementors.
(5) Make it clear in the schema documentation that the assignment of
specific formatting attributes to the three classes above is the
responsibility of the calling application.
To go whole hog on rationalization of bibliography formatting, it
would be tempting to also delete the “second-field-align” and
"hanging-indent" options. The former could be adequately covered with
the “label” and “item” group classes. The latter would require its
own “csl-hanging-indent” class. This would allow the removal of some
black magic code from the CSL processor, and would allow user style
settings in the word processor to take effect across bibliography
styles, which would be a nice touch. But I do realize that the burden
and risk of remangling the repository is an argument, maybe a strong
argument, against going that far.
Frank
So what exactly are you proposing?
Still just thinking out loud, but:
(1) Drop display=“block” and display=“inline-block” from the schema.
(2) Retain the attribute.
(3) Limit the permissible values to class= to the following
tentative list:
– csl-subheading
– csl-label
– csl-item
How do these values address the use cases (AAA, annotated bibs, etc)?
So what exactly are you proposing?
Still just thinking out loud, but:
(1) Drop display=“block” and display=“inline-block” from the schema.
(2) Retain the attribute.
(3) Limit the permissible values to class= to the following
tentative list:
– csl-subheading
– csl-label
– csl-item
How do these values address the use cases (AAA, annotated bibs, etc)?
Not sure how to explain in words. These are arbitrary names for
blocks of text that have common features in the layout of the AAA and
second-field-align type bibliographies. I’m attaching another copy of
the HTML in which the inline CSS styling has been extracted to a
header block, as an illustration. For HTML output, the calling
application would need to supply that block in the finished HTML
document that it delivers to the browser. The content of the block is
not the responsibility of CSL.
I’m also attaching a test fixture that shows how the HTML code in the
sample could be defined in a CSL style.
(For annotated bibliographies, you might want a add a class for an
indented block.)
For reference, here is a link to a couple of related forum discussions:
(ignore the complaint about the forum in the second linked post – the
body of Dan’s message talks about RTF and styles). I looked for a
post in which you suggested something very similar to this, but the
Zotero forum search interface is playing funny tricks, and I gave up.
Frank
Missed out the docs mentioned in the last message. Sorry for the
extra traffic; they’re attached to this one.
Frank
aaa-sample_test.txt (2.51 KB)
aaa-sample.html (2.17 KB)
It might just be me with insufficient caffeine, but I’m still not
understanding a) how the formatting actually gets applied, and b) how
this is any better than the existing block and inline-block
attributes. In particular, what if the “csl-label” class should be
rendered inline?
You, for example, point out that inline-block in CSS isn’t just a
simple boolean, but that you need additional configuration (like
width). But can we not just give some guidance in the spec on what
that width should be?
Part of it may be that I don’t know what you mean by “block” in the above.
Bruce
So what exactly are you proposing?
Still just thinking out loud, but:
(1) Drop display=“block” and display=“inline-block” from the schema.
(2) Retain the attribute.
(3) Limit the permissible values to class= to the following
tentative list:
– csl-subheading
– csl-label
– csl-item
How do these values address the use cases (AAA, annotated bibs, etc)?
Not sure how to explain in words. These are arbitrary names for
blocks of text that have common features in the layout of the AAA and
second-field-align type bibliographies. I’m attaching another copy of
the HTML in which the inline CSS styling has been extracted to a
header block, as an illustration. For HTML output, the calling
application would need to supply that block in the finished HTML
document that it delivers to the browser. The content of the block is
not the responsibility of CSL.
It might just be me with insufficient caffeine, but I’m still not
understanding a) how the formatting actually gets applied, and b) how
this is any better than the existing block and inline-block
attributes. In particular, what if the “csl-label” class should be
rendered inline?
Mea culpa. The HTML file I sent was missing the CSS block. The
correct file is attached (I hope).
As Rintze pointed out in a side discussion, how to define a format in
CSL, and how to deliver it to a client are separate issues, and
implicit styling classes for the currently implemented use cases could
be provided to a client, without any change to the current CSL syntax
and conventions.
The reason I think using named class attibutes on CSL-side would be
better than display=“block|inline-block”, in particular, is that the
latter are purely presentational, and as such provide no handle or
hint with which to assign an appropriate class on the output side.
That compels the use of localized styling (i.e. inline styling in
HTML) with explicit parameters (like the width dimension), and that in
turn makes the output unavoidably stiff and brittle.
Frank
aaa-sample.html (2.17 KB)
Ha. The CSS block was not missing from the file, but some web based
mail readers (like GMail) will strip it when the file is opened via
the “View” option. To get the full file, download and open locally.
I might have put the block in the wrong spot in the file – thought it
belonged in the header, maybe that’s not correct.
Sorry for the extra traffic.
Frank
Further to the discussion of class names and bibliography formatting,
I have put up a sample document that illustrates the way CSL markup
could map through to named classes in HTML output. The output uses
the following classes:
– csl-bib-body (implicit in all output)
– csl-entry (implicit in all output)
– csl-entry-heading (used by the AAA style)
– csl-left-label (used by second-field-align type styles)
– csl-item (used by second-field-align type styles).
Here is the page:
http://gsl-nagoya-u.net/http/pub/csl-bibliography.html
The page shows the CSL that generates the HTML output markup in the
current revision of citeproc-js. As the
"actually-the-same-as-csl-entry" style class shows, some of the
manipulations require a change in the CSS parameters (and so cannot be
smoothly illustrated in a single document with a single CSS header).
The bibliography would be delivered as a two-item list, the first a
bundle of parameters, the second the formatted bibliography string.
The calling application would assemble the style header using the
supplied parameters, so that the size of indents and whatnot are
correct for the content.
Anyway, this is all running. All that would be required to firm it up
is the retain the class attribute, and inclusion of the class names
and the processor-supplied formatting parameters in the CSL
documentation somewhere.
At least that’s all I can think of; will look forward to reactions and views.
Frank
Further to the discussion of class names and bibliography formatting,
I have put up a sample document that illustrates the way CSL markup
could map through to named classes in HTML output. The output uses
the following classes:
– csl-bib-body (implicit in all output)
– csl-entry (implicit in all output)
– csl-entry-heading (used by the AAA style)
– csl-left-label (used by second-field-align type styles)
– csl-item (used by second-field-align type styles).
Here is the page:
gsl-nagoya-u.net - This website is for sale! - gsl nagoya u Resources and Information.
This is awesome!
However …
The page shows the CSL that generates the HTML output markup in the
current revision of citeproc-js. As the
“actually-the-same-as-csl-entry” style class shows, some of the
manipulations require a change in the CSS parameters (and so cannot be
smoothly illustrated in a single document with a single CSS header).
The bibliography would be delivered as a two-item list, the first a
bundle of parameters, the second the formatted bibliography string.
The calling application would assemble the style header using the
supplied parameters, so that the size of indents and whatnot are
correct for the content.
Anyway, this is all running. All that would be required to firm it up
is the retain the class attribute, and inclusion of the class names
and the processor-supplied formatting parameters in the CSL
documentation somewhere.
At least that’s all I can think of; will look forward to reactions and views.
As I mentioned on the ticket you posted yesterday, I’m getting
overwhelmed. I can’t follow all these threads (in part because of
other obligations).
I think one way to address this is, rather than suggesting things in
fairly general terms, you propose actual spec text. I, for example,
don’t know what the class names mean. So take a shot at explaining
them formally.
I also don’t know why we need this; why is this any different than
using block and inline block? I realize it may well be, but I just
don’t have the cycles to figure it out myself ATM.
Finally, I’ll just observe that using group in many of your examples
isn’t strictly necessary.
Bruce