677929 - Style Inspector: show color swatch

Status: RESOLVED INVALID

(DevTools :: Inspector, defect, P3)

Description

[Mihai Sucan [:msucan]]

When the user hovers a color value we should show the color in a tooltip.

Comment 1

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

I would say that we should include color, image and font-family tooltips. This will mean obtaining the type for each property ... color, url or font.

Comment 2

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

I have logged bugs 702576 & 702577 for the image and font tooltips.

Comment 3

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: Color swatches

Actually, I saw this in chrome and think it is cool. The swatches are always added before a color and clicking on the swatch cycles through the different color types. This is better than a tooltip because you can visually match a CSS property to a node's color.

Comment 4

[Kevin Dangoor]

I agree that the swatches are nicer. I think it would be cool (but out of scope for this bug :) if clicking the swatch actually displayed a color picker rather than cycling through the color values.

Comment 5

[Joe Walker [:jwalker]]

(In reply to Kevin Dangoor from comment #4)
> I agree that the swatches are nicer. I think it would be cool (but out of
> scope for this bug :) if clicking the swatch actually displayed a color
> picker rather than cycling through the color values.

If only we had someone around who knew about writing color addons for Firefox.

Comment 6

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

A color picker would be good for the rule view or style editor, but at the moment the style inspector is completely read-only.

Comment 7

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

After some discussion we have decided that we will create a color swatch similar to chrome's. Clicking the swatch will toggle the color display type for that property.

Updated bug title as appropriate.

Comment 8

[bobi]

And what you guys decided for images or webfonts ? 
Should i open other bugs ? 

----------
http://twitter.com/signap

Comment 9

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

I have logged bug 702576 & bug 702577 for the image and font tooltips

Comment 10

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: Simple proof of concept html file

This html file parses plain text and adds a cycle-able color swatch. I will move the color object into a JSM and implement the color search feature before this is implemented.

Comment 11

[Paul Rouget [:paul]]

I am not convinced that this UI pattern is the one we want. This looks like a color picker. I know we won't have a color picker in the property view, but we will have some in other tools (rule view for example), and we will probably use this kind of pattern.

Introducing this UI pattern as the way to cycle through the color notations could be a problem in the future.

I would ask someone from the UX team before implementing anything.

Comment 12

[Rob Campbell [:rc] (:robcee)]

see also bug 706427, which is apparently for search.

I think this is a neat idea, but like Paul says, I don't think this is the behavior we're after. We should have some kind of "cycle" button to show that you can flip through the different color spaces, assuming we want to do that. Should we do that for spaces without alpha channels?

E.g., given hsla(214, 80, 20, 0.5) do we want to convert that to hsl(214, 80, 20) and lose the alpha channel? They're not really equivalent.

I also agree that if we're introducing clicks on the color swatch it should probably invoke a color picker.

Comment 13

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

I like Rob's idea ... a color cycle at the top of the screen that cycles all colors makes sense. Also, when a color would lose information e.g. hsla to hsl we do not convert them. The same for nicknames when colors do not have them.

A bunch of people have mentioned to me that they want to see the colors so they are visually easier to find. I will put some thought into how we could accomplish this without displaying misleading color swatches.

Comment 14

[Rob Campbell [:rc] (:robcee)]

(In reply to Michael Ratcliffe from comment #13)
> I like Rob's idea ... a color cycle at the top of the screen that cycles all
> colors makes sense. 

Not sure I understand what you mean here, but I didn't mean to include a switch at the top of the screen.

I meant the color display could look something like:

color: [ ] rgb(255, 255, 255) @
        ^                     ^
        +- swatch             +- cycle button

and when the user clicks the cycle button, the value changes to:

white, #FFF, #FFFFFF, rgba(255, 255, 255, 1), hsl(0, 0, 255), hsla(0, 0, 255, 1), ...

I guess you could have a single button on the page that changes all of them at once, but I'm not sure what that would be like. It might be less busy.

> Also, when a color would lose information e.g. hsla to
> hsl we do not convert them. The same for nicknames when colors do not have
> them.

yeah, this.

> A bunch of people have mentioned to me that they want to see the colors so
> they are visually easier to find. I will put some thought into how we could
> accomplish this without displaying misleading color swatches.

I don't think it was the swatches were misleading, I think it was the behavior of using it to cycle color spaces when most people would expect that to bring up a color picker. The swatches are fine as long as they're read only.

Comment 15

[Joe Walker [:jwalker]]

+1 change all the swatches at the same time.
If the sequence was:
- original
- named colors or rgba()
- rgba()
- hsla()
Then we wouldn't need to worry too much about loss of alpha channel info, and the rgb()/hsl() values would be fairly obvious.

Also +1 shorlander involvement.

Comment 16

[Kevin Dangoor]

As a first step, I think that just having a color swatch is beneficial, even if clicking it does nothing.

Here's another option for the click behavior: ideally, our color picker will allow the user to see/edit the color in the common color formats. If the color picker has a read-only mode, clicking the swatch could display the color picker with the different color formats displayed in the dialog.

Comment 17

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

I am inclined to agree with Kevin. We should probably use this bug for "rotate color type" and log another bug for the color swatch.

I will ping shorlander and see what he thinks.

Comment 18

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Bug triage, filter on PEGASUS.

Comment 19

[barryvan]

Personally, I would like to see a drop-down menu ("View colours as...") with options such as "As authored", "hex", "rgb(a)", "hsl(a)", and "shortest". It doesn't, in my opinion, make sense to cycle all the colour values, because authors tend to use mixed colour forms (hex and rgba, for example) in the same stylesheet.

Alternatively, if colour cycling is desired on a per-rule basis, then I would suggest that the up and down keys cycle when the cursor is over the prefix ("#", "rgba", "hsl", etc.).

Comment 20

[sys.sgx]

yep, i agree with this implementation.

Comment 21

[Paul Rouget [:paul]]

(sys, I see your "I agree" comments all over the devtools bugs, please use the "vote" button instead)

Comment 23

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

This bug is a mess containing 2 enhancements.

Splitting it into:
Bug 775130 - Show color tooltip with swatch in rule view, Show color tooltip without swatch in computed view
Bug 775135 - Add color type dropdown to rule and computed views