706102 - [rule view] Show gradient editor tooltip

Status: NEW

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

Description

[bobi]

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).

Comment 1

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

Bug triage, filter on PEGASUS.

Comment 2

[Patrick Brosset <:pbro>]

This is part of our Q4 goal on doorhangers (tooltips).
See the roadmap here: https://gist.github.com/captainbrosset/6681978

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.

Comment 3

[Patrick Brosset <:pbro>]

Bug 889638 is ongoing, and will add, when it lands, a color picker tooltip that look somewhat liks this: http://people.mozilla.org/~pbrosset/tooltips/color-picker.png

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: http://people.mozilla.org/~pbrosset/tooltips/gradient-editor.png

Comment 5

[Patrick Brosset <:pbro>]

Attachment: webkit-gradient.gif

A pretty amazing gradient editor tooltip landed in webkit nightly.

Comment 6

[Patrick Brosset <:pbro>]

While looking at Tooltip.js, I realized that it contains some left over code that isn't used:

https://github.com/mozilla/gecko-dev/blob/master/browser/devtools/shared/widgets/Tooltip.js#L1065
and
https://github.com/mozilla/gecko-dev/blob/master/browser/devtools/shared/widgets/Tooltip.js#L1073

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.

Comment 7

[Brian Grinstead [:bgrins]]

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.

Comment 8

[alexharris6]

After discussing with bgrins, I am interested in working on this

Comment 9

[alexharris6]

I have put together a basic plan for this here: https://pastebin.mozilla.org/5221306

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"

Comment 10

[Brian Grinstead [:bgrins]]

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: http://jsfiddle.net/bgrins/9MxNS/.

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: [
      {color:"red",position:0},
      {color:"yellow",position:1}
    ]
  }

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: [
      {color:"red",position:0},
      {color:"orange",position:.333},
      {color:"yellow",position:.666},
      {color:"green",position:1},
    ]
  }

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

Comment 11

[Jonathan Watt [:jwatt]]

I think what you really need is a DOM for CSS gradients. Tab, is there any work on that?

Comment 12

[Jonathan Watt [:jwatt]]

(nsComputedDOMStyle::GetCSSGradientString shows iteration over the internal structures.)

Comment 13

[Jonathan Watt [:jwatt]]

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:

  http://wiki.ecmascript.org/doku.php?id=strawman: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.

Comment 14

[Jonathan Watt [:jwatt]]

I suppose the tricky bit may be getting the 'gradient box' ( http://dev.w3.org/csswg/css-images-3/#gradient-box ). I'm not sure the size of getBoundingClientRect gets you what you need.

Comment 15

[Tim Nguyen :ntim]

Attachment: gradient_picker_i03.png

Mockup

Comment 16

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

Maybe we could use something like this as a start point:
https://github.com/rafaelcaricio/gradient-inspector/blob/master/gradient_inspector.js

Comment 17

[Tim Nguyen :ntim]

Found this design : http://static.tumblr.com/8dw0uyw/RpOnh3de2/feature_4.jpg
It looks really cool, I think we could use an UI like that as well.

Comment 18

[Tim Nguyen :ntim]

Here's what can be used to parse the gradient : https://github.com/rafaelcaricio/gradient-parser

Comment 19

[Patrick Brosset <:pbro>]

Chrome DevTools recently posted a set of ideas about what they call "devtools for designers". One of the entries is about editing gradients: https://trello.com/c/30RNIE2J/2-gradient-designer
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.

Comment 20

[Patrick Brosset <:pbro>]

Alex, do you still plan to work on this bug? It's been a while.

Comment 21

[Patrick Brosset <:pbro>]

(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:
> https://trello.com/c/30RNIE2J/2-gradient-designer
> 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: http://codepen.io/captainbrosset/full/XJqQwV/

Comment 22

[Tim Nguyen :ntim]

It's been 10 months now, let's unassign this.

Comment 23

[Patrick Brosset <:pbro>]

Inspector bug triage (filter on CLIMBING SHOES).