gitweb css - pixels?!

Hi, folks.

I've been gradually converting my ~/src directory full of tarballs I've found interesting enough to download to a ~/repos/ directory containing bare git repositories of the projects. I was thinking it might be worth my while to set up gitweb so I can peruse my collection of projects.

I noticed myself squinting, on my 1400x1050 laptop screen, at the 10 and 12-*pixel* font settings gitweb's CSS specifies before thinking to myself that I should bring this to the list's attention.

I'm no CSS guru, or I'd just provide a patch. It seems that *all* the measurements specified in the CSS file are in pixels, not ems or percentages. There's got to be a better way. I can't be the only person who would rather use my nice screen to render attractive, readable fonts rather than to render the smallest possible fonts?

On 2007-05-07T17:13:42-0600, Chris Riddoch wrote:

ctrl-+ (ctrl plus possible a couple of times) fixes that if you are using a browser from the Mozilla Foundation. It was perfectly readable for me, but I fortunate enough to have a large LCD.

/Allan

On 5/7/07, Allan Wind <allan_wind@lifeintegrity.com> wrote:

Yes, I'm aware of that feature.  Very handy.  And entirely too necessary.

Seriously, this isn't something to push on to users. Entirely too many websites don't follow sensible accessibility standards; shouldn't gitweb be fixed?

On Mon, May 07, 2007 at 17:13:42 -0600, Chris Riddoch wrote:

Well, there should be three ways to set font sizes:

 1. Use the symbolic small, normal, large..., which are derived from user
    settings (normal is user setting, large is one step larger etc.). IMHO
    this would be the best variant.
 2. Use *points* (pt) instead of *pixels* (px). Unfortunately most browsers
    don't know what their DPI is and will treat 1pt as 1px, even though they
    have more than 72dpi. I believe this applies to all Micro$oft browsers.
 3. Use designation relative to previous font. One step up is 1.2em, one step
    down is 0.8333333em. I am not sure this actually works in Micro$oft
    browsers. Also rounding errors may quickly get you to completely
    different font size that you wanted.

Avoid specifying font sizes in pixels, since that is just pure evil. Pointed out by Chris Riddoch.

Note that this is pretty much just a proposal; I didn't test if everything fits perfectly right, but things seem to be pretty much okay. repo.or.cz uses it now as a test drive - if you find any visual quirks, please point them out, with a patch if possible since I'm total CSS noob and debugging CSS is an extremely painful experience for me.

Note that this patch actually does change visual look of gitweb in Firefox with my resolution and default settings - everything is bigger and I can't explain the joy of actually seeing gitweb text that is in _readable_ size; also, my horizontal screen real estate feels better used now. But judging from the look of most modern webpages on the 'net, most people prefer reading the web with strained eyes and/or a magnifying glass (I wonder what species of scientists should look into this mystifying phenomenon) - so, please tell us what you think.

Maybe we might want to get rid of absolute sizes other than font sizes in the CSS file too in the long term.

Signed-off-by: Petr Baudis <pasky@suse.cz>
---

 gitweb/gitweb.css |   19 +++++++++----------
 1 files changed, 9 insertions(+), 10 deletions(-)

Petr Baudis <pasky@ucw.cz> writes:

This looks like going in the right direction, but...

	[12, 18, 10] / 12 * 100 = [100, 150, 83.33]

why not use 83% for what were originally 10px?

On Wed, May 09, 2007 at 07:54:43AM CEST, Junio C Hamano wrote:

It seemed to me that the small parts were way too large then (this is also why I decided not to use 'large', 'medium' and 'small' - large was too small and small was too large, I felt), but I don't particularily care about this detail.

On 5/8/07, Petr Baudis <pasky@ucw.cz> wrote:

Thanks!  It's definitely a step in the right direction.

In my browser, the decent-sized fonts make it apparent that we're trying to fit a lot in a limited horizontal space. In particular, the links (commit | committdiff | tree | snapshot) wrap in the space provided, for me. I dropped my default font size a little, and it's just fine... but it does make me think, perhaps that's something where either icons or abbreviations (with an appropriate key) might improve the appearance of the page. Perhaps something like: C | D | T | S. It might even let us put more functionality in and improve our use of whitespace even more.

I like it.

Petr Baudis wrote:

Not everyone has those huge monitors with extreme resultion. For me new gitweb look uses much to big font, so not very much fits in screen.

I'd remove 

chunk

Jakub Narebski <jnareb@gmail.com> writes:

But then we'd be back to the brain-damaged explicit-pixel sizes.

gitweb is simply using the font size you have configured your browser to use, and if you think that it too large, you are free to reconfigure it.

Unfortunately, the problem is that too many web sites explicitly select extra small font sizes, which means that you have to select a "standard" font size in your browser that is a bit larger than you'd actually like.

On Mon, May 14, 2007 at 18:06:54 -0700, David Kågedal wrote:

IMHO gitweb should explicitely request being somewhat smaller than normal, because it has good use for long lines. Normally I want to set font so large, that more than ~120 characters won't fit on the screen, since otherwise pages that don't use margins are simply unreadable. However gitweb presents a table with several columns, so having wider line is OK for it. Therefore explicit 'font-size: small' would make sense.

On Thu, 15 May 2007, Jan Hudec wrote:

And thanks to commit 63fcbe00 by Pasky
  "gitweb: Do not use absolute font sizes"
it has to be added in only one place:

Commit 63fcbe00a66d7cb7d8bce9a36120a19a809a33b8 by Peter "Pasky" Baudis
  "gitweb: Do not use absolute font sizes"
made gitweb use default font size, the font size you have configured
your browser to use, as a basis; other font sizes are given as
percentage.

David Kågedal noticed problem with this approach: too many web sites explicitly select extra small font sizes, which means that you have to select a "standard" font size in your browser that is a bit larger than one would actually like.

Additionally, as Jan Hudec noticed, gitweb should explicitely request being somewhat smaller than normal, because it has good use for long lines. Normally one would usually want to set font so large, that more than ~120 characters won't fit on the screen, since otherwise pages that don't use margins are simply unreadable. However gitweb presents a table with several columns, so having wider line is OK for it.

Jan Hudec proposed to use 'font-size: small' to take above issues into account. This avoid using "brain-damaged" explicit-pixel sizes, while taking into account nature of gitweb output.

Thanks to mentioned commit by Pasky we need to add 'font-size: small' in only one place, for BODY element.

See the original messages:
  Message-ID: <87odkmgaj5.fsf@morpheus.local>
  Message-ID: <20070515150912.GA3653@efreet.light.src>

Proposed-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is commit wich has commit message larger than patch itself, but
I think the explanation is as important as patch itself, perhaps even
more important.

 gitweb/gitweb.css |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

On Wed, May 16, 2007 at 12:51:38PM CEST, Jakub Narebski wrote:

Acked-by: Petr Baudis <pasky@suse.cz>

just for the record, since it seems to be already applied anyway. By the way, I think this commit message is more optimal than what ended up for some reason (Jakub wasn't fast enough? ;-) as b211c320eb5d753a7a44a03eccb9a15cfbcc563b - especially the subject of that commit is really weird.

Petr Baudis <pasky@suse.cz> writes:

Most likely timezone difference is the largest factor.

On Thu, 17 May 2007, Petr Baudis wrote:

Second 'gitweb: Do not use absolute font sizes' commit in git.git repo is from (authordate) Wed May 16 01:59:55 2007 +0200, while this one: 'gitweb: Change base font size to "small"' commit in my repo is from Wed May 16 12:16:02 2007 +0200

So it looks like my patch without commit message in
  Message-ID: <200705160159.55590.jnareb@gmail.com>
was taken, and commit message was added by Junio, and not ready commit
from this subthread (in message you have replied to, and which you Ack)
  Message-ID: <200705161251.38729.jnareb@gmail.com>

Gah, either I shouldn't have send bare patch, or I have should send reply that I'm working on commit message for this change.

I have tagged my commit message in git/jnareb-git.git repo as gitweb/change-base-font-size:

  http://repo.or.cz/w/git/jnareb-git.git?a=tag;h=gitweb/change-base-font-size

to protect it against rebase + prune.