Subject: Re: [PATCH 0/4 v4] minor gitweb modifications

From: Sylvain Rabot <[email-masked]>
Date: Sun, 02 Jan 2011 17:27:21 +0100

On Sat, 2011-01-01 at 04:41 -0600, Jonathan Nieder wrote:
> (adding back cc: jakub)
> 
> Hi,
> 
> Sylvain Rabot wrote:
> 
> >   gitweb: add extensions to highlight feature map
> >   gitweb: remove unnecessary test when closing file descriptor
> 
> I like the above two.
> 
> >   gitweb: add css class to remote url titles
> 
> I had a question (why make the remote url table inconsistent with the
> older projects_list table) and suggested a more generic approach in
> reply to v2[1]:
> 
> 	<table class="projects_list">
> 	<tr id="metadata_desc">
> 		<td class="metadata_tag">description</td>
> 		<td>Unnamed repository; edit this file to name it for gitweb.</td>
> 	</tr>
> 	<tr id="metadata_owner">
> 		<td class="metadata_tag">owner</td>
> 		<td>UNKNOWN</td>
> 	</tr>
> 	...
> 
> The idea was that the rows are already labelled for use by css, so to
> make this stylable all we need to do is use a class for the first
> column.  This way if some site operator wants the first column
> *always* be bold then that is easy to do.

So your idea is to use the same class for all this kind of tables' first
column ?

> 
> Another approach with similar effect would be
> 
> 	<dl class="projects_list">
> 	<dt>description</dt>
> 	<dd id="metadata_desc"
> 		>Unnamed repository; edit this file to name it for gitweb</dd>
> 	<dt>owner>
> 	<dd id="metadata_owner"
> 		>UNKNOWN</dd>
> 	...
> 
> but that does not degrade as well to browsers not supporting css.  Any
> thoughts on this?

I think table is fine, don't see the need to replace it by dd, dt, dl.

> 
> >   gitweb: add vim modeline header which describes gitweb coding rule
> 
> I don't like this one.  Isn't the tabstop whatever the reader wants it
> to be (e.g., 8)?  I don't like modelines as a way of documenting
> coding standards because
> 
>  (1) they are not clear to humans and editors other than vim
>  (2) they require annotating each source file separately.
> 
> See [1] for an alternative approach to configuring an editor to hack
> on git.
> 
> Regards,
> Jonathan
> 
> [1] http://thread.gmane.org/gmane.comp.version-control.git/109462/focus=109538

-- 
Sylvain Rabot <[email-masked]>