Open Bug 706102 Opened 9 years ago Updated 2 years ago

[rule view] Show gradient editor tooltip


(DevTools :: Inspector: Rules, enhancement, P2)



(Not tracked)


(Reporter: domi.papin, Unassigned)


(Blocks 1 open bug)


(Keywords: dev-doc-needed, Whiteboard: [ruleview][creative-tools])


(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111127 Firefox/10.0a2
Build ID: 20111127042022

Steps to reproduce:

When using a css gradient, hovering the value should show a tooltip. 
(a color swatch seems too minimal for gradients).
Bug triage, filter on PEGASUS.
Ever confirmed: true
Whiteboard: [computedview][ruleview]
Blocks: 711947
This is part of our Q4 goal on doorhangers (tooltips).
See the roadmap here:

The goal here is to display a gradient swatch next to the css gradient expression (depends on bug 918716 for this) and, when clicking on it, display a gradient editor doorhanger.
Depends on: 918716
Bug 889638 is ongoing, and will add, when it lands, a color picker tooltip that look somewhat liks this:

I suggest that we use the same color picker widget, but evolve the UI a little bit to show the gradient panel itself with color stops, and allow to add/remove/drag stops and change their colors with the same picker. A very very basic mockup:
Duplicate of this bug: 711943
Attached image webkit-gradient.gif
A pretty amazing gradient editor tooltip landed in webkit nightly.
While looking at Tooltip.js, I realized that it contains some left over code that isn't used:

These 2 functions were originally added because the logic to choose which tooltip should be shown when hovering over some element was in this file. But there are so many different consumers to the tooltip API that it didn't make sense to keep this there. These 2 functions should be removed.

I'm only mentioning this here because for this bug we'll have to detect gradient expressions in the style inspector, and this code used to deal with this.
Some information about possible implementation taken from a chat with pbrosset:

> In tooltip.js, we need a new SwatchBasedTooltip class - GradientEditorTooltip or something like this which inherits from the SwatchBased thing
> This takes care of linking a set of swatches to a tooltip and then up to you to put what you want in the tooltip
> I suggest focusing on the standlone editor first, like we have spectrum so that it's easy to work on it and test it individually
> And then embedding it in a tooltip is going to be a piece of cake - the famous "it should only take a minute"!

The takeaway was that we should focus on a gradient editor component outside of a tooltip at first to make development and testing easier, then we should add this to a tooltip later.
After discussing with bgrins, I am interested in working on this
Assignee: nobody → alexharris6
OS: Mac OS X → All
Hardware: x86 → All
Version: 10 Branch → Trunk
Component: General → Developer Tools: Inspector
Summary: Style Inspector: show gradient tooltip → [rule view] Show gradient editor tooltip
I have put together a basic plan for this here:

A few other things to keep in mind, from a conversation I had with bgrins:

1. How to correctly get CSS linear-gradient() properties from element. Regex? Bgrins: "we may be able to ask gecko about the position of the stops being used for a particular gradient."
2. Issues surrounding the position of colorstops that use pixels as opposed to percentages in the css. Perhaps by converting them to percentages when they are received.
2. Pre-populating new handles (ghost handles) with the color at that location. Bgrins: "use a canvas with the grad drawn and get the color from that"
Whiteboard: [computedview][ruleview] → [ruleview]
So when initially opening the tooltip, we will want to have a list of color stops prepopulated.  Parsing it with js seems pretty nasty, esp taking into account rules for old syntax gradients.

Jonathan, I was wondering if there was a function in the platform or if you had any ideas that could help converting a gradient string into a more structured interpretation of the gradient.

I've put together a demo of some of the gradient types that we care about at:

Here are some examples of the expected input and output from such a function (these are negotiable, just my current thoughts on what we would want returned).

1) Basic support for percentage based stops:

  Input: "linear-gradient(to bottom, red 0%, yellow 100%)"
  Output: {
    angle: "180deg",
    stops: [

2) It would be awesome if this included position information when it was not defined:

  Input: "linear-gradient(to right, red, orange, yellow, green)"
  Output: {
    angle: "90deg",
    stops: [

3) Handling unordered color stops.  I'm not actually sure how to best represent this in a gradient editor - it seems that it is solid red until 40%, then the interpolation from green 10% to yellow 100% takes over.  Regardless, I guess the function should just return them in order.

  Input: "linear-gradient(to right, red 40%, green 10%, yellow)"
  Output: {
    angle: "90deg",
    stops: [
      {color:"red", position: .4 },
      {color:"green", position: .1 },
      {color:"yellow", position:.9}

4) I *think* we would want to even include percentage based positional information when a non-percent unit was passed in, but if it came back as "10px", "5em", etc we should be to do the conversion on the client side.

  Input: "linear-gradient(to right, red 10px, yellow 5em, green 90%)"
  Output: {
    angle: "90deg",
    stops: [
      {color:"red", position: .05 }, // 10px converted to percentage
      {color:"orange", position: .25 }, // 5em converted to percentage
      {color:"green", position:.9}

5) Radial Gradients - I haven't dug in as much as to exactly what we need here, but probably something similar that includes <position>, <shape>, <size>, <extent-keyword> to go along with the stops instead of just <angle>.
Flags: needinfo?(jwatt)
I think what you really need is a DOM for CSS gradients. Tab, is there any work on that?
Flags: needinfo?(jwatt) → needinfo?(jackalmage)
(nsComputedDOMStyle::GetCSSGradientString shows iteration over the internal structures.)
So apparently there is no specification for a DOM for complex CSS values like the transform property because they're waiting on CSS Value Objects:

As far as I can tell the main bug on file related to implementing that is bug 749786.

It would be a fair bit of work to expose some temporary object model just for devtools, so the best path forward is likely to have your own parser written in JS for now.
Flags: needinfo?(jackalmage)
I suppose the tricky bit may be getting the 'gradient box' ( ). I'm not sure the size of getBoundingClientRect gets you what you need.
Attached image gradient_picker_i03.png
Found this design :
It looks really cool, I think we could use an UI like that as well.
Here's what can be used to parse the gradient :
Chrome DevTools recently posted a set of ideas about what they call "devtools for designers". One of the entries is about editing gradients:
The screenshot seems to show an in-content tool to create the gradient by dragging a line tool to set the angle and span of the gradient, just like in photoshop, which I think, is pretty awesome.
Alex, do you still plan to work on this bug? It's been a while.
Flags: needinfo?(alexharris6)
(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #19)
> Chrome DevTools recently posted a set of ideas about what they call
> "devtools for designers". One of the entries is about editing gradients:
> The screenshot seems to show an in-content tool to create the gradient by
> dragging a line tool to set the angle and span of the gradient, just like in
> photoshop, which I think, is pretty awesome.
Something like this:
It's been 10 months now, let's unassign this.
Assignee: alexharris6 → nobody
Flags: needinfo?(alexharris6)
Whiteboard: [ruleview] → [ruleview][creative-tools]
Severity: normal → enhancement
Component: Developer Tools: Inspector → Developer Tools: CSS Rules Inspector
Inspector bug triage (filter on CLIMBING SHOES).
Priority: -- → P2
See Also: → 1364380
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.