Issues I see are on latest Chrome, Ubuntu 11.04, on a 12" screen.
BruceOn May 14, 2011 6:36 PM, “Dan Stillman” <@Dan_Stillman> wrote:
On 5/14/11 2:18 PM, Dan Stillman wrote:
A screenshot from Bruce suggests that the search box isn’t necessarily
being rendered properly everywhere.This is what it should look like:
http://www.zotero.org/styles-files/screenshot.png
If it doesn’t look like that for you, let me know your OS and browser
version.
I tinkered a little bit with the HTML and CSS. I think you can save some
vertical space by changing the positions of the Citation Formats and Fields
tag clouds, reducing the white space around the “Style Search” title, and
using one introductory paragraph instead of two:
http://img820.imageshack.us/img820/6597/stylesrepository.png
Rintze
P.S.
I’ve put up a version using your proposed layout. At most screen sizes
it should be five lines of field tags with the bottom tag aligned with
the bottom of the citation formats, and it’ll wrap more if necessary.
This layout will work until someone adds a style with
citation-format=“author”, at least.
There already is one, MLA, but it’s currently labelled as author-date.
I noticed that all the styles have an updated timestamp of 2011-05-12
12:16:08. Going forward, would probably be preferable to update the
timestamp in the github repository after an commit, if we can figure out to
do that.
Rintze
Huh?
Wouldn’t that be the other way around: that the index should draw the
updated value from the git repo (easy to do, and something more human
readable would be preferable), and that we should use a post hook ( as
w/the svn repo) to add that to the checked out files (also easy to
do)?
Bruce
Respectively:
Pretty Date Example - $ git log --date=iso --pretty=format:"%ad" -1 apa.csl
Keyword expansion - http://progit.org/book/ch7-2.html
Bruce
I just mean the cs:updated timestamp should reflect the time and date of the
last style edit.
Rintze
Oops …On Sun, May 15, 2011 at 9:23 AM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:
Pretty Date Example - $ git log --date=iso --pretty=format:“%ad” -1 apa.csl
That’d be to get a standard iso date-time format for the cs:updated value.
This would get a pretty, relative (and thus locale-specific), date:
$ git log -1 --pretty=format:“%ar” apa.csl
Bruce
>> >> I've put up a version using your proposed layout. At most screen sizes >> it should be five lines of field tags with the bottom tag aligned with >> the bottom of the citation formats, and it'll wrap more if necessary. >> This layout will work until someone adds a style with >> citation-format="author", at least. > > There already is one, MLA, but it's currently labelled as author-date.
OK, well, that’s kind of why I had it the other way around. With five
format labels there’s not much wasted space the other way.
Is the label going to be fixed? Are there others?
> > I noticed that all the styles have an updated timestamp of 2011-05-12 > 12:16:08. Going forward, would probably be preferable to update the > timestamp in the github repository after an commit, if we can figure out to > do that. Huh? Wouldn't that be the other way around: that the index should draw the updated value from the git repo (easy to do, and something more human readable would be preferable), and that we should use a post hook ( as w/the svn repo) to add that to the checked out files (also easy to do)?I just mean the cs:updated timestamp should reflect the time and date
of the last style edit.
Do you mean cs:updated, or do you mean the index timestamp? Remember,
the reason we advised leaving cs:updated blank in the styles was so that
authors wouldn’t feel compelled to update it on every update, which
would be a waste of their time. (I know there was the issue of whether
the styles still validated client-side…)
The problem with using smudge/clean filters in .gitattributes is that,
as far as I can tell, they require particular client-side programs
(e.g., Perl). A Windows user isn’t going to have Perl. So leaving it
blank seems best.
None of the date logic on the styles page changed, by the way. The
timestamps will be correct as the styles are updated. It’s just more
complicated to use the commit timestamp than to update the timestamp if
the style has changed, and so I didn’t bother.
…
I just mean the cs:updated timestamp should reflect the time and date
of the last style edit.Do you mean cs:updated, or do you mean the index timestamp? Remember,
the reason we advised leaving cs:updated blank in the styles was so that
authors wouldn’t feel compelled to update it on every update, which
would be a waste of their time. (I know there was the issue of whether
the styles still validated client-side…)
There are a variety of issues with forcing style authors to update the
cs:updated values manually:
The problem with using smudge/clean filters in .gitattributes is that,
as far as I can tell, they require particular client-side programs
(e.g., Perl). A Windows user isn’t going to have Perl. So leaving it
blank seems best.
“Leaving it blank” but presumably using some other code outside of git
to create the proper cs:updated values?
In any case, users aren’t often going to interact with the git repos
directly, so not sure that’s a reasonable argument against the git
filters?
None of the date logic on the styles page changed, by the way. The
timestamps will be correct as the styles are updated. It’s just more
complicated to use the commit timestamp than to update the timestamp if
the style has changed, and so I didn’t bother.
Not following you here. Can you restate, in light of my questions above?
Thanks,
Bruce
The problem with using smudge/clean filters in .gitattributes is that,
as far as I can tell, they require particular client-side programs
(e.g., Perl). A Windows user isn’t going to have Perl. So leaving it
blank seems best.
“Leaving it blank” but presumably using some other code outside of git
to create the proper cs:updated values?
Well that’s what either filters or the styles page would do.
In any case, users aren’t often going to interact with the git repos
directly, so not sure that’s a reasonable argument against the git
filters?
Who are “users” here? I was referring to style authors.
If you think only a few people will be committing and checking out and
we can require them to have Perl (or we’d be OK with the filters
sometimes not being run), then filters are fine. Otherwise, this
shouldn’t happen via git, and it should be left to the styles page.
None of the date logic on the styles page changed, by the way. The
timestamps will be correct as the styles are updated. It’s just more
complicated to use the commit timestamp than to update the timestamp if
the style has changed, and so I didn’t bother.
Not following you here. Can you restate, in light of my questions above?
The update script for the styles page assumes no filters and just
replaces the contents of with the current timestamp if the
content of the file has changed since the last run. If we were using git
filters it would just use directly.
The problem with using smudge/clean filters in .gitattributes is that,
as far as I can tell, they require particular client-side programs
(e.g., Perl). A Windows user isn’t going to have Perl. So leaving it
blank seems best.
“Leaving it blank” but presumably using some other code outside of git
to create the proper cs:updated values?Well that’s what either filters or the styles page would do.
In any case, users aren’t often going to interact with the git repos
directly, so not sure that’s a reasonable argument against the git
filters?Who are “users” here? I was referring to style authors.
Yes, me too.
If you think only a few people will be committing and checking out and
we can require them to have Perl (or we’d be OK with the filters
sometimes not being run), then filters are fine. Otherwise, this
shouldn’t happen via git, and it should be left to the styles page.
I guess we can always play it by ear, but in any case leave the
cs:updated value blank in the repo?
None of the date logic on the styles page changed, by the way. The
timestamps will be correct as the styles are updated. It’s just more
complicated to use the commit timestamp than to update the timestamp if
the style has changed, and so I didn’t bother.
Not following you here. Can you restate, in light of my questions above?The update script for the styles page assumes no filters and just
replaces the contents of with the current timestamp if the
content of the file has changed since the last run. If we were using git
filters it would just use directly.
How do you determine the updated value: from the file itself, or from git?
For whatever reason, they’re not (necessarily) the same thing.
$ ls -l apa.csl
-rw-r–r-- 1 bdarcus bdarcus 10186 2011-05-15 09:27 apa.csl
$ git log --date=iso --pretty=format:“%ad” -1 apa.csl
2011-05-04 15:49:04 -0400
Bruce
If you think only a few people will be committing and checking out and
we can require them to have Perl (or we’d be OK with the filters
sometimes not being run), then filters are fine. Otherwise, this
shouldn’t happen via git, and it should be left to the styles page.
I guess we can always play it by ear, but in any case leave the
cs:updated value blank in the repo?
Yes, I think so.
None of the date logic on the styles page changed, by the way. The
timestamps will be correct as the styles are updated. It’s just more
complicated to use the commit timestamp than to update the timestamp if
the style has changed, and so I didn’t bother.
Not following you here. Can you restate, in light of my questions above?
The update script for the styles page assumes no filters and just
replaces the contents of with the current timestamp if the
content of the file has changed since the last run. If we were using git
filters it would just use directly.
How do you determine the updated value: from the file itself, or from git?
We don’t use the updated value—just the system timestamp when the script
is run.
For whatever reason, they’re not (necessarily) the same thing.
$ ls -l apa.csl
-rw-r–r-- 1 bdarcus bdarcus 10186 2011-05-15 09:27 apa.csl$ git log --date=iso --pretty=format:“%ad” -1 apa.csl
2011-05-04 15:49:04 -0400
The first is just the checkout time, which git doesn’t set specially.
The latter is the commit time.
We don’t use either.
(But if the script was run from a post-commit hook then our timestamp
would be basically the same as the commit time.)
We don’t use the updated value—just the system timestamp when the script
is run.
OIC.
Isn’t that potentially dangerous (if we assume it likely that sources
for styles will proliferate, and that a given style may be available
from more than one source)?
Or to put it more directly, why not use the git value?
(But if the script was run from a post-commit hook then our timestamp
would be basically the same as the commit time.)
Isn’t the question of how the script is run (outboard vs. post-commit,
etc.) really orthogonal to the timestamp issue? E.g. you can get the
git commit timestamp from a simple shell script.
Bruce
So you all agree that:
a) the CSL 1.0.1 schema should require that the cs:updated element holds
either a xsd:dateTime timestamp or have no content
and
b) that for styles in the git repo, cs:updated should be blank. So we should
delete any existing timestamps, and make sure they aren’t added for further
commits.
?
Rintze
I will fix the label after the final merge. I don’t know if there are
others.
In the past, both the citation format and field metadata never got curated
very well, because it wasn’t really used. With the tag cloud filtering that
data becomes a lot more useful, so it’s something worth checking (e.g. there
are currently 129 styles marked “generic-base”, many of which are
journal-specific styles, so that should be fixed).
Rintze
Hi,
I guess we can always play it by ear, but in any case leave the
cs:updated value blank in the repo?
I would not do it (see below)
Yes, I think so.
So you all agree that:
a) the CSL 1.0.1 schema should require that the cs:updated element holds
either a xsd:dateTime timestamp or have no contentand
b) that for styles in the git repo, cs:updated should be blank. So we should
delete any existing timestamps, and make sure they aren’t added for further
commits.
I would not do it, I expect the cs:updated to have the timestamp in
the repository, so it’s easy to clone, users can just browse the
repository using the github interface and download the ready-to-use
style, etc.
I would update the cs:updated when pushing with the pushing date, no?
Carles,
…
So you all agree that:
a) the CSL 1.0.1 schema should require that the cs:updated element holds
either a xsd:dateTime timestamp or have no contentand
b) that for styles in the git repo, cs:updated should be blank. So we should
delete any existing timestamps, and make sure they aren’t added for further
commits.I would not do it, I expect the cs:updated to have the timestamp in
the repository, so it’s easy to clone, users can just browse the
repository using the github interface and download the ready-to-use
style, etc.
Except that the github interface lists updated date-times for all
files by default already.
And how do you respond to my previously noted problems? To repeat …
There are a variety of issues with forcing style authors to update the
cs:updated values manually:
I would update the cs:updated when pushing with the pushing date, no?
You mean like pre-commit or pre-push script?
That solves some of my issues above, but not all of them.
Bruce
Hi,
By popular demand[1], I’ve updated the Zotero styles page to use CSL 1.0
I’m very happy to read and see it!
styles from GitHub, and I’ve taken the opportunity to add some new
the “old” page had, at the end, a “Get Involved” section. Do you plan
to add the same? (I guess that redirecting the people to the github,
etc.?)
search features, with the ability to filter by name, dependent status,
citation format, and field.
yes, looks neat. Hopefully the previews will be there soon.
Let me know if you run into any problems with the new page or have ideas
for improvements.
I thought something similar for www.citationstyles.org, maybe can be
partially reused? I forgot if someone was working on it (I remember
Bruce talking about some software to prepare tables).
