Closed
Bug 552647
Opened 14 years ago
Closed 14 years ago
The search-direction arrows need some CSS fixes
Categories
(Bugzilla :: Query/Bug List, enhancement)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.6
People
(Reporter: mkanat, Assigned: mkanat)
References
Details
Attachments
(2 files, 3 obsolete files)
99.84 KB,
image/png
|
Details | |
1.37 KB,
patch
|
LpSolit
:
review+
|
Details | Diff | Splinter Review |
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.
Flags: blocking3.6+
Assignee | ||
Comment 1•14 years ago
|
||
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.
Assignee: query-and-buglist → mkanat
Status: NEW → ASSIGNED
Attachment #432780 -
Flags: review?(LpSolit)
Comment 2•14 years ago
|
||
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.
Attachment #432780 -
Flags: review?(LpSolit) → review-
Comment 3•14 years ago
|
||
(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
Assignee | ||
Comment 4•14 years ago
|
||
(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.
Assignee | ||
Comment 5•14 years ago
|
||
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.)
Attachment #432780 -
Attachment is obsolete: true
Attachment #432981 -
Flags: review?(LpSolit)
Comment 6•14 years ago
|
||
In this example the down arrow indicates that the highest number is at the top and the smallest number is at the bottom.
Comment 7•14 years ago
|
||
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.
Assignee | ||
Comment 8•14 years ago
|
||
Oh, indeed you are right, pyrzak. :-) I will just do he style fixes, then.
Summary: The search-direction arrows are backwards → The search-direction arrows are styled unclearly
Assignee | ||
Comment 9•14 years ago
|
||
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.
Assignee | ||
Comment 10•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Summary: The search-direction arrows are styled unclearly → The search-direction arrows are unclear
Assignee | ||
Comment 11•14 years ago
|
||
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.
Attachment #432981 -
Attachment is obsolete: true
Attachment #433012 -
Flags: review?(LpSolit)
Attachment #432981 -
Flags: review?(LpSolit)
Assignee | ||
Comment 12•14 years ago
|
||
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.
Assignee | ||
Comment 13•14 years ago
|
||
Oh, Bugzilla supports Unicode, I can just paste in what I chose: ↓ and ↑ (but somewhat bigger in the actual buglist).
Comment 14•14 years ago
|
||
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.
Attachment #433012 -
Flags: review?(LpSolit) → review-
Assignee | ||
Comment 16•14 years ago
|
||
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.
Summary: The search-direction arrows are unclear → The search-direction arrows need some CSS fixes
Assignee | ||
Comment 17•14 years ago
|
||
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.
Attachment #433012 -
Attachment is obsolete: true
Attachment #435487 -
Flags: review?(LpSolit)
Assignee | ||
Comment 18•14 years ago
|
||
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 19•14 years ago
|
||
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
Attachment #435487 -
Flags: review?(LpSolit) → review+
Updated•14 years ago
|
Flags: approval+
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8
Updated•14 years ago
|
Severity: minor → enhancement
Assignee | ||
Comment 20•14 years ago
|
||
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.
Flags: approval3.6?
Target Milestone: Bugzilla 3.8 → Bugzilla 3.6
Assignee | ||
Comment 22•14 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•