Closed Bug 1102084 Opened 7 years ago Closed 7 years ago
We need more contrast for the currently-hovered node in the dark theme
I think in order for the dark tjeme to be usable the currently-highlighted node should be *more* noticeable than the clicked node, not less noticeable. See the attached screenshot
note: this isn't so important when the currently-highlighted node is highlighted because the mouse cursor hovers over the html, but it is important when the cursor is over the dom node in the content pane, as the user is explicitly hunting for the matching HTML.
So increasing the visibility of the highlighted node (for dark and light themes) feels like a good goal, but I don't think we need to invert the visibility WRT the selected node.
Implementation note: this uses the theme-bg-darker css class, which is only used here and in computed-view on hover: http://dxr.mozilla.org/mozilla-central/search?q=theme-bg-darker&redirect=true. I'm not sure if hover should be *more* noticeable than the selected node, but it could clearly be more noticeable than it is. We've been trying to stick to this palette in general: https://developer.mozilla.org/en-US/docs/Tools/DevToolsColors.
(In reply to Joe Walker [:jwalker] (overloaded - needinfo me or ping on irc) from comment #2) > So increasing the visibility of the highlighted node (for dark and light > themes) feels like a good goal, but I don't think we need to invert the > visibility WRT the selected node. Eh, right - but it does need to be visually differentiated from it, we all seem to agree on that.
Here's an idea - use the selection color with some transparency
This is using the new capability of CSS variables from 1102369 (and thus should wait to make sure that sticks). This makes the computed view use a new more specific class for zebra striping (which is all it ever wanted with this class anyway), which allows it to be taken over and become to be more contrast-y. Notes: * I don't know if theme-bg-darker is a good name for this anymore. Maybe theme-bg-contrast-2? Naming things is hard... * I wish we could do math on the colors to mix an existing theme color with transparency, but I don't think we can so I just duplicated it in each theme.
Attachment #8526358 - Flags: review?(vporof)
(In reply to Brian Grinstead [:bgrins] from comment #6) > * I wish we could do math on the colors to mix an existing theme color with > transparency, but I don't think we can so I just duplicated it in each theme. I guess this is in the CSS 4 draft: http://dev.w3.org/csswg/css-color/#modifying-colors
Let me indulge in a vision science aside just because I rarely get to do it anymore (you can ignore this if uninterested) I agree that it doesn't matter which contrast is higher than the other in most cases -- the fact that the highlighted line changes quickly as the mouse cursor moves means that as long as the contrast is easily detectable, it will be noticed. (there's an exception if the two lines are very close to each other but i'll skip that). The problem with the currrent colors from a psychophysical "technical" point of view is that the contrast in the light theme was roughly 2-3 JND (Just Noticeable Difference), which can be found by the "low-effort" attention system automatically. In the dark theme, I would gauge it at roughly 1 JND -- meaning in a two-alternative forced choice, people will identify it correctly > 50% of the time, but at that level of difference the load on the attention system is much harder -- when things are just detectable rather than popping out, the brain appears to engage in a serial hunting process rather than the difference popping out. In particular, the time to find that line will likely shift from being a constant quick time to a linear longer time as you increase the # of lines displayed. That difference is probably in part because even if the RGB delta between the two colors might the same across the two themes, luminance changes (measured in photons) don't map to lightness changes (measured in perceived lightness) linearly across the intensity axis. The good news is as long as you make it easy for the brain to see that there has been a change, the eye will find it. You could bold, you could underline, almost anything detectable will work. </science>
(In reply to David Ascher (:davida) from comment #8) > Let me indulge in a vision science aside just because I rarely get to do it > anymore (you can ignore this if uninterested) Interesting - do you have any links for how to find out more?
Comment on attachment 8526358 [details] [diff] [review] markup-hover-style.patch Review of attachment 8526358 [details] [diff] [review]: ----------------------------------------------------------------- Sure
Attachment #8526358 - Flags: review?(vporof) → review+
Comment on attachment 8526344 [details] hover-contrast.png So does this proposed change look better with regard to comment 8? It's actually easier for us to tweak the background color than to do bold/italic/underline in this case.
Attachment #8526344 - Flags: feedback?(davida)
> Interesting - do you have any links for how to find out more? Will send email, as we're getting off topic =).
Comment on attachment 8526344 [details] hover-contrast.png seems better yes.
Attachment #8526344 - Flags: feedback?(davida) → feedback+
Realized we were using nearly identical colors for hover in the webconsole, so made it a variable to be consistent there as well.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
You need to log in before you can comment on or make changes to this bug.