The search-direction arrows need some CSS fixes

RESOLVED FIXED in Bugzilla 3.6

Status

()

Bugzilla
Query/Bug List
--
enhancement
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Max Kanat-Alexander, Assigned: Max Kanat-Alexander)

Tracking

Bugzilla 3.6
Bug Flags:
approval +
approval3.6 +
blocking3.6 -

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Assignee)

Description

8 years ago
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

8 years ago
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.
Assignee: query-and-buglist → mkanat
Status: NEW → ASSIGNED
Attachment #432780 - Flags: review?(LpSolit)

Comment 2

8 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

8 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

8 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

8 years ago
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.)
Attachment #432780 - Attachment is obsolete: true
Attachment #432981 - Flags: review?(LpSolit)

Comment 6

8 years ago
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.

Comment 7

8 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

8 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

8 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

8 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

8 years ago
Summary: The search-direction arrows are styled unclearly → The search-direction arrows are unclear
(Assignee)

Comment 11

8 years ago
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.
Attachment #432981 - Attachment is obsolete: true
Attachment #433012 - Flags: review?(LpSolit)
Attachment #432981 - Flags: review?(LpSolit)
(Assignee)

Comment 12

8 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

8 years ago
  Oh, Bugzilla supports Unicode, I can just paste in what I chose:

  ↓ and ↑ (but somewhat bigger in the actual buglist).

Comment 14

8 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-

Comment 15

8 years ago
Not a blocker.
Flags: blocking3.6+ → blocking3.6-
(Assignee)

Comment 16

8 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

8 years ago
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.
Attachment #433012 - Attachment is obsolete: true
Attachment #435487 - Flags: review?(LpSolit)
(Assignee)

Comment 18

8 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

8 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

8 years ago
Flags: approval+
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8

Updated

8 years ago
Severity: minor → enhancement
(Assignee)

Comment 20

8 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

Comment 21

8 years ago
ok
Flags: approval3.6? → approval3.6+
(Assignee)

Comment 22

8 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
Last Resolved: 8 years ago
Resolution: --- → FIXED

Updated

8 years ago
Blocks: 494652
You need to log in before you can comment on or make changes to this bug.