Re: [PATCH] gitweb: tree view: eliminate redundant "blob"

From: Jakub Narebski <jnareb@gmail.com>
Date: Oct 1, 2006, 19:27 UTC
Message-ID: <200610012127.37113.jnareb@gmail.com>
In-Reply-To: <7vd59b27c4.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 7 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > ... That means that we cannot distinguish really well (at 
> > least color) between tree and blob entries.
> 
> Do we even say links are blue and underlined by forcing that in
> our css?

That is default style of link element, as specified by default CSS for HTML/XHTML.

> Doesn't leading drwxr-xr-x mean anything?

Neither d in drwxr-xr-x, nor trailing / in the name are significant
enough indicators of directory vs file (tree vs blob) indicator,
especially that by default git-ls-tree output mixes trees with blobs.

> Why is making the distinction important in the first place?

If you browse tree, you usually click on tree links, but not on blob links.

Show 13 quoted lines

> > In the case of shortlog/log/history/heads/tags view, to clearly mark 
> > subject/title of a commit or tag as link, we would have to use default 
> > link decoration....
> > But underlined text is harder to read, and blue underlined text even 
> > more so...
> 
> This is something in which I can see some more sense than tree
> vs blob issue, but only as a principle issue.  In practice, the
> list of commit subjects is the first thing users encounter, and
> as long as there is some visual indication (e.g. mousing over it
> makes it obvious it is something that is clickable), I think
> users will quickly pick up that it will lead to the commit's
> detail.

Well, that is certainly the question of style (redundancy vs. uncluttered output plus some coding issues).

By the way, I've planned to move printing those kind of links to separate subroutine (output based on type of object the links are related to, and somewhat als on the action/view we are in)...

-- 
Jakub Narebski
Poland