Progress bar layout of Milestone is invalid.

[anonymous]

Hi. all.
I used Trac-0.9pre revision 2053.

If the number of tickets(closed and active) of milestone is same,
Progress bar layout is not wrong.

For example

In proper case.

closed tickets

active tickets

In wrong case.

closed tickets	(blank)
active tickets	(blank)

[anonymous]

capture image.

[anonymous]

This problem appears in IE and Mathon, not FireFox?.

[asmodai@…]

Which version of IE did you test this with?

[markus]

The screenshot is most likely an image of IE6, because it looked the same when I tried to reproduce the problem.

Note that there's a problem with Firefox, too. When IE displays the progress bar like in the screenshot, Firefox cuts the right border of it.

So, to me this does not seem like a browser bug. It looks more like the widths of the inner divs are bigger than the width of the outer div. While IE puts the second inner div in a new line, Firefox draws it on top of the outer div and so paints over its right border. However, this seems to depend on the relation between closed and active tickets as it is not always reproducible.

[markus]

For the record: With the latest versions (from trunk) I've never seen a milestone layout like the one in anonymous' screenshot. Unfortunately the layout in IE is still bad, when the progress bar is the topmost (next to the Show already completed milestones box). I'll attach a screenshot.

[jan]

The invalid layout still exist with IE in Trac 0.9b2!

[cboos]

It seems that, for some reason, the floating blocks
constituting the progress bar behave as if they sometimes
get a clear: left constraint, in IE.
Forcing that property to be none won't work, but forcing it to right
does the trick.

This addresses the problem examplified by attachment:capture.bmp​

The other problem, visible on Trac's Roadmap (attachment:ie6-1.jpg​)
can't be reproduced, and is likely due to the presence of the IFRAME
of Google ads (saving that /roadmap page with Firefox, then viewing
it with IE will show correct interaction between the progress
floating block and the prefs floating block)

roadmap.css

@@ -5 +5 @@
  border: none;
  display: block;
  float: left;
+ clear: right;
  height: 1.2em;
 }
 div.progress :link:hover, div.progress :visited:hover { background: #fff }

[cboos]

After some further investigations,
it appears that the intermittent stacking of the floating blocks
is due to the
​rule 7.

A left-floating box that has another left-floating box to its left may not have its right outer edge to the right of its containing block's right edge.

For some reasons, IE thinks that 50% + 50% will exceed 100%…
That's why it works well when the sum isn't 100% (e.g. the 1/3, 2/3 case).

Therefore, an alternative fix would be:

roadmap.cs

@@ -46 +46 @@
          if:#stats.total_tickets != #1 ?>s<?cs /if ?> closed"></a>
        <a class="open" href="<?cs
          var:milestone.queries.active_tickets ?>" style="width: <?cs
-         var:#stats.percent_active ?>%" title="<?cs
+         var:#stats.percent_active - 1 ?>%" title="<?cs
          var:#stats.active_tickets ?> of <?cs
          var:#stats.total_tickets ?> ticket<?cs
          if:#stats.total_tickets != #1 ?>s<?cs /if ?> active"></a>

milestone.cs

@@ -126 +126 @@
         if:#stats.total_tickets != #1 ?>s<?cs /if ?> closed"></a>
       <a class="open" href="<?cs
         var:milestone.queries.active_tickets ?>" style="width: <?cs
-        var:#stats.percent_active ?>%" title="<?cs
+        var:#stats.percent_active - 1 ?>%" title="<?cs
         var:#stats.active_tickets ?> of <?cs
         var:#stats.total_tickets ?> ticket<?cs
         if:#stats.total_tickets != #1 ?>s<?cs /if ?> active"></a>

[cboos]

I just noticed that the above trick was already used
for the progress bars shown in the milestone stats,
so this is probably the way to go…

[trac@…]

The above trick is already being used for the progress bars, but I do not think that is the way to go. It would be much preferable to use css to get it correct than to hack the percentages due to a bug in IE. Hacking the percentages already causes other problems because they do not add to 100% anymore (like the width of the percent_active bar no longer being correct).

I was looking at correcting this in my implementation of milestone stat extension points, which I am nearly finished (This is the last issue I was going to solve before submitting it).

— Justin

[cboos]

I don't think it's a big deal, as the percent_active value is not presented
as such to the user but only used for the visual cue.
Do you simply favor using the clear: right trick,
or do you have a better solution?

(Also, I checked the 1/3 closed and 2/3 opened situation,
the percentages are 33% and 67%, so no idea why it works
in this case and not for the 50%/50% case)

[cmlenz]

cboos proposed fix looks good IMHO. The difference between a width of 49% and 50% shouldn't be noticable visually.

[cboos]

Fixed by r2411.

Justin, feel free to come up with a better alternative
for a later milestone…
The fix is good enough for 0.9.

[trac@…]

I agree it is a good solution for 0.9. I explored another way of doing it for my milestone extension point changes by simulating a border using background-color and 1 pixel padding, but the results were inconsistent. Instead I guess I will use the same solution, except make it more specific to apply only in the case of 50%/50%.