Right now, the search-direction arrows face upward for an ascending search, and downward for a descending search, which is the opposite of what they should be. Also, the arrows change color depending on whether they're ascending or descending--I think they become part of the link in one case, and not part of the link in another case.
Created attachment 432780 [details] [diff] [review] v1 This orients the arrows in the proper direction, gives them proper coloring, and removes them from the link so that they won't be underlined.
Comment on attachment 432780 [details] [diff] [review] v1 Arrows should remain in <a></a>. I always click on them when I want to reverse the order of the column (by habit), and there is no reason not to do so. This is especially true when (like me) you configured your browser to not underline links. You would have a part of the column header which wouldn't be clickable, and this would be confusing.
(In reply to comment #0) > Right now, the search-direction arrows face upward for an ascending search, and > downward for a descending search, which is the opposite of what they should be. why is this the opposite of what it should be? At least on my mail app the arrows reflect the direction of the search, up for ascending and down for descending. My assumption is that you want to show the direction it will be in if you click the arrow but that's actually backwards. We should show the current state over the future state if you click arrow
(In reply to comment #3) > why is this the opposite of what it should be? In every app I've ever used, ascending (meaning, the lowest numbers at the top and the highest numbers at the bottom) is a down arrow. It indicates the direction that values go.
Created attachment 432981 [details] [diff] [review] v2 Okay, this moves them back inside the link, but removes the underline from them, so you can still click on them. However, due to a known bug in Gecko and Webkit, the underline still appears in browsers based on those rendering engines. (It works properly in IE8.)
Created attachment 432987 [details] Mail and YUI doing it the way most apps do it. In this example the down arrow indicates that the highest number is at the top and the smallest number is at the bottom.
URL to YUI's example of the direction things should go. We should do what YUI and presumably everything else does. http://developer.yahoo.com/yui/examples/datatable/dt_clientsorting.html If this is what you are saying max then i'm in agreement, but it sounds like you're saying the opposite.
Oh, indeed you are right, pyrzak. :-) I will just do he style fixes, then.
Ohhh, it's not that you are right and that I am wrong, it's that we're both familiar with different platforms. For example, on Thunderbird on Linux, when I sort the Date column, it points *down* when the highest number is at the bottom. To me, this makes sense, because it's indicating the direction that the numbers are going. I think that we should stick with my patch, because it makes the arrows point in the direction of the sort.
Oh, I know what's going on. OK: * On OS X, they're not arrows, they're *pyramids*. Same for Windows. Same for YUI. Small at the top, large at the bottom. * I think of them as arrows, not pyramids. So, the best solution is probably to change to arrow glyphs instead, which is unambiguous.
Created attachment 433012 [details] [diff] [review] v3 Okay, these are arrows now. Since they're a little small, I made the header a little bigger so that the arrows are at least a little bit easier to see. (If we make just the arrows bigger, the headers with arrows get unaligned with the headers that don't have arrows, and there's no way to fix their vertical alignment with CSS.) Also, I moved the "align=left" off the tr (where it doesn't work in IE8) and into CSS.
By the way, here's all available Unicode arrow glpyhs: http://en.wikipedia.org/wiki/Arrow_(symbol) I picked the one that was clearest and most readable.
Oh, Bugzilla supports Unicode, I can just paste in what I chose: ↓ and ↑ (but somewhat bigger in the actual buglist).
Comment on attachment 433012 [details] [diff] [review] v3 I agree with pyrzak about these arrows. What we currently have is consistent. This is was we observe on Windows (e.g. the Windows Explorer), but also with YUI. There are much more Windows users than Linux (and Mac) ones, and they are familiar with the current UI. As we later plan to use YUI to sort dynamic tables, we should also be consistent with what it provides, which is the current UI as well. So it doesn't make sense to reverse the arrows simply because Linux users have it the other way. Moreover, replacing well known arrows which look like pyramids, which is what all 3 platforms use, by thin arrows which are used nowhere is not consistent with what everybody is used to see. So this bug is WONTFIX to me.
Not a blocker.
Okay, I can accept the pyramids if they're standards (although they aren't on Linux). I think the CSS fixes I did would still be good, though.
Created attachment 435487 [details] [diff] [review] v4 Okay, this makes the primary arrow black (so that there's a proper relation with the gray arrow), gives the arrows a little spacing away from the words, and fixes the alignment of buglist headers on IE8.
Also, on CSS2.1-conformant browsers (only IE8, of the ones I tested), the attached patch removes the underline from beneath the arrow, while still keeping it clickable as part of the link.
Comment on attachment 435487 [details] [diff] [review] v4 Only IE 8 and Opera don't underline the arrows. On other browsers, the difference is really minor. r=LpSolit
I think the current coloring of the primary arrow and the alignment of the table headers in IE8 are bugs, so this seems appropriate for 3.6.
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/ modified skins/standard/buglist.css modified template/en/default/list/table.html.tmpl Committed revision 7117. Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/3.6/ modified skins/standard/buglist.css modified template/en/default/list/table.html.tmpl Committed revision 7076.