[PATCH] gitweb: pull ref markes pull out of subject <a> tag

[PATCH] gitweb: pull ref markes pull out of subject <a> tag

[Giuseppe Bilotta]

Since 4afbaefffa9095fe1391b4b61289a7dc954e9f7b ref markers that
accompain the subject in views such as shortlog and history point to
something different from the subject itself. Therefore, they should not
be included in the same <a> tag.

Benefits of the change are:
* better compliance to the XHTML standards, that forbid links within
  links even though the restriction cannot be imposed via DTD; this also
  benefits visualization in some older browsers;
* when hovering the subject, only the subject itself is underlined; when
  hovering the ref markers, only the text in the hovered ref marker is
  underlined; previously, hovering any written part of the subject
  column led to complete underlying of everything at the same time,
  with unpleasing effects.
---
 gitweb/gitweb.perl |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

The next step would be to find a way to layout decently the case when
some shortlog entries have a _humongous_ amount of ref markers. See
for example http://git.oblomov.eu/acecad/shortlog

I honestly doubt these cases happen in normal git repositories, but it
might still be worth taking them into consideration. Possibilities
include hard-limiting the title column maximum width (in browsers for
which the corresponding attributes and rules work), manual insertion of
hard line breaks <br/> every n-th ref marker, or something more dynamic
such as hiding most of the ref markers when they are more than, say, 5,
and showing them on hover.

Suggestions? Comments?

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ce6e8f6..bb9648b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1524,10 +1524,10 @@ sub format_subject_html {
 		$long =~ s/[[:cntrl:]]/?/g;
 		return $cgi->a({-href => $href, -class => "list subject",
 		                -title => to_utf8($long)},
-		       esc_html($short) . $extra);
+		       esc_html($short)) . $extra;
 	} else {
 		return $cgi->a({-href => $href, -class => "list subject"},
-		       esc_html($long)  . $extra);
+		       esc_html($long)) . $extra;
 	}
 }
 
-- 
1.6.3.rc1.192.gdbfcb

Re: [PATCH] gitweb: pull ref markes pull out of subject <a> tag

[Jakub Narebski]

On Sun, 23 Aug 2009, Giuseppe Bilotta wrote:

> Since 4afbaefffa9095fe1391b4b61289a7dc954e9f7b ref markers that
> accompain the subject in views such as shortlog and history point to
> something different from the subject itself. Therefore, they should not
> be included in the same <a> tag.
> 
> Benefits of the change are:
> * better compliance to the XHTML standards, that forbid links within
>   links even though the restriction cannot be imposed via DTD; this also
>   benefits visualization in some older browsers;

Yes, some older browsers (like Mozilla 1.7.12, Gecko/20050923) did 
_enforce_ that requirement when served document with XHTML DOCTYPE,
and application/xml+xhtml Content-Type, by moving inner link (A element)
just outside (just after) outer, containing <a> element.

For format_subject_html which you are fixing, and which is used by 
'shortlog', 'history' and 'tags' views this didn't cause much changes
in layout.  But the way gitweb uses git_print_header_div in views such
as 'tree', 'blob' etc., where the outer (containing) link is made into
*block* element[1] by the way of CSS (display: block) makes layout 
(visualisation) very screwed up in older browser.  But I don't expect
you to fix that.

[1] Originally so the area to click is larger.

> * when hovering the subject, only the subject itself is underlined; when
>   hovering the ref markers, only the text in the hovered ref marker is
>   underlined; previously, hovering any written part of the subject
>   column led to complete underlying of everything at the same time,
>   with unpleasing effects.

Signoff?

Acked-by: Jakub Narebski <jnareb@gmail.com>

> ---
>  gitweb/gitweb.perl |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> The next step would be to find a way to layout decently the case when
> some shortlog entries have a _humongous_ amount of ref markers. See
> for example http://git.oblomov.eu/acecad/shortlog
> 
> I honestly doubt these cases happen in normal git repositories, but it
> might still be worth taking them into consideration. Possibilities
> include hard-limiting the title column maximum width (in browsers for
> which the corresponding attributes and rules work), manual insertion of
> hard line breaks <br/> every n-th ref marker, or something more dynamic
> such as hiding most of the ref markers when they are more than, say, 5,
> and showing them on hover.
> 
> Suggestions? Comments?

Perhaps limiting to heads and tags if there are too many refs?

> 
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index ce6e8f6..bb9648b 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1524,10 +1524,10 @@ sub format_subject_html {
>  		$long =~ s/[[:cntrl:]]/?/g;
>  		return $cgi->a({-href => $href, -class => "list subject",
>  		                -title => to_utf8($long)},
> -		       esc_html($short) . $extra);
> +		       esc_html($short)) . $extra;
>  	} else {
>  		return $cgi->a({-href => $href, -class => "list subject"},
> -		       esc_html($long)  . $extra);
> +		       esc_html($long)) . $extra;
>  	}
>  }
>  
> -- 
> 1.6.3.rc1.192.gdbfcb
> 
> 

-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: pull ref markes pull out of subject <a> tag

[Giuseppe Bilotta]

2009/8/23 Jakub Narebski <jnareb@gmail.com>:
> For format_subject_html which you are fixing, and which is used by
> 'shortlog', 'history' and 'tags' views this didn't cause much changes
> in layout.  But the way gitweb uses git_print_header_div in views such
> as 'tree', 'blob' etc., where the outer (containing) link is made into
> *block* element[1] by the way of CSS (display: block) makes layout
> (visualisation) very screwed up in older browser.  But I don't expect
> you to fix that.
>
> [1] Originally so the area to click is larger.

Fixing that really needs some kind of ridiculously complex
workarounds, or a totally different layout. That is actually one of
the situations where nested links make perfect sense, and it's a real
pity the standard wouldn't allow them, and that some client actually
altered the DOM to 'fix' it. But anyway.

> Signoff?

Aaaargh. Is it enough if I put it here:

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>

or should I resend?

(One would expect I actually learned to add it, finally, but noooo ...
gah, stupid me.)

>> The next step would be to find a way to layout decently the case when
>> some shortlog entries have a _humongous_ amount of ref markers. See
>> for example http://git.oblomov.eu/acecad/shortlog
>>
>> I honestly doubt these cases happen in normal git repositories, but it
>> might still be worth taking them into consideration. Possibilities
>> include hard-limiting the title column maximum width (in browsers for
>> which the corresponding attributes and rules work), manual insertion of
>> hard line breaks <br/> every n-th ref marker, or something more dynamic
>> such as hiding most of the ref markers when they are more than, say, 5,
>> and showing them on hover.
>>
>> Suggestions? Comments?
>
> Perhaps limiting to heads and tags if there are too many refs?

That wouldn't help at all in the case I linked:
http://git.oblomov.eu/acecad/shortlog due to the number of tags that
were imported from CVS.

-- 
Giuseppe "Oblomov" Bilotta

Re: [PATCH] gitweb: pull ref markes pull out of subject <a> tag

[Junio C Hamano]

Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:

> 2009/8/23 Jakub Narebski <jnareb@gmail.com>:
>> For format_subject_html which you are fixing, and which is used by
>> 'shortlog', 'history' and 'tags' views this didn't cause much changes
>> in layout.  But the way gitweb uses git_print_header_div in views such
>> as 'tree', 'blob' etc., where the outer (containing) link is made into
>> *block* element[1] by the way of CSS (display: block) makes layout
>> (visualisation) very screwed up in older browser.  But I don't expect
>> you to fix that.
>>
>> [1] Originally so the area to click is larger.
>
> Fixing that really needs some kind of ridiculously complex
> workarounds, or a totally different layout. That is actually one of
> the situations where nested links make perfect sense, and it's a real
> pity the standard wouldn't allow them, and that some client actually
> altered the DOM to 'fix' it. But anyway.
>
>> Signoff?
>
> Aaaargh. Is it enough if I put it here:
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>

I can manage.

Thanks, both.