1258390 - [meta] Rule-view inline editor widget

Status: NEW

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

Description

[Patrick Brosset <:pbro>]

As agreed at the Visual Tools work-week in Toronto (March 2016), we want to introduce "inline-editors" in the rule-view that expand within the view itself, below a given property or fragment that is being edited.

For example, clicking on a color in the rule-view would expand an area below the property containing the color. This area would contain the color-picker widget as we know it today (but in time would also contain color palettes, etc.).

We want this to become a common UX pattern for visually editing values in the rule-view.
This includes editing: colors, gradients, backgrounds, fonts, filters, blend-modes, borders, shadows, angles, etc.

An extra requirement for this is to design the API in such a way that it's easy to register/unregister new editors too, so it's easy to write firefox addons for adding more editors. There are so many CSS properties or values that can benefit from a more visual editing experience that we want addons to help.

Comment 1

[Patrick Brosset <:pbro>]

Helen designed the first inline editor for editing colors:
https://projects.invisionapp.com/d/main#/console/5476602/143217180/preview

Comment 2

[Patrick Brosset <:pbro>]

There's a bunch of properties and values we might want inline editors for, here are a few examples that lead to different use cases:

color: ⬤ red;
Probably the simplest example, with 1 value only. Clicking on the circle next to the color name would open the color inline editor.

background: linear-gradient(⬤ red, ⬤ blue);
A little more complex, there are 2 editable values here.
After having open one color editor, should clicking on a second one open a second editor below that, or should it replace the first one.

box-shadow: ⬛ 1px 2px 0 2px ⬤ red;
A little more complex again. There's a color in there, but we might also want an inline editor for the whole shadow property.
Should the color be editable independently still (by clicking on the circle next to it), or should the shadow only be editable as a whole (by clicking on the square at the beginning)?
A shadow visual editor would be useful because it makes it obvious to edit the spread or blur without remembering which one comes first. Also, x/y offset could also be edited in a more visual way, by dragging with the mouse.
Another example for this is filter: ⬛ hue-rotate(⬤ 12deg);
Do we want to have both an inline editor for the angle (which is useful for other properties too) and another one for the filter property as a whole?

box-shadow: ⬛ 1px 2px 0 2px ⬤ red,
            ⬛ 0 0 20px 0 ⬤ blue;
Even more complex, many CSS properties accept multiple values like box-shadow.
It may make sense to have the shadow inline editor be able to edit all shadows as a whole. This way, it's easier to add new ones (by just clicking on a + button inside the inline editor, instead of having to edit the css value by entering code), but also easier to delete one, or even drag/drop shadows to change the order in which they apply.
This also applies to filter, background-image, transform, ...

font-family: arial;
Another complex case is changing fonts. I think it makes a lot of sense to have an inline editor that allows to edit: font-family, font-size, letter-spacing, word-spacing, line-height, font-style, text-decoration, etc... all at once in a panel that looks like what you might find in Photoshop for instance.
But doing this requires being able to edit more than 1 property at once.
Should the editor add new properties if needed? If yes, should it try to find inherited rules that might define these properties already and set the values there?

So, to conclude, inline-editors should be able to edit:
- fragments (single values)
- entire properties
- properties that accept a list of properties (e.g. shadow)
- multiple properties at once

Comment 3

[Patrick Brosset <:pbro>]

(In reply to Patrick Brosset [:pbro] from comment #2)
> box-shadow: ⬛ 1px 2px 0 2px ⬤ red;
Another thing I forgot to note about this case (and other similar cases):
If we have an editor for box-shadows, it will most probably contain a way to edit the color, so does that mean that from within the shadow-editor, you'll be able to open the color editor? Should it appear below, or inline somehow?

Comment 4

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Patrick Brosset [:pbro] from comment #2)
> background: linear-gradient(⬤ red, ⬤ blue);
> A little more complex, there are 2 editable values here.
> After having open one color editor, should clicking on a second one open a
> second editor below that, or should it replace the first one.
> 
> box-shadow: ⬛ 1px 2px 0 2px ⬤ red;
> A little more complex again. There's a color in there, but we might also
> want an inline editor for the whole shadow property.
> Should the color be editable independently still (by clicking on the circle
> next to it), or should the shadow only be editable as a whole (by clicking
> on the square at the beginning)?
> A shadow visual editor would be useful because it makes it obvious to edit
> the spread or blur without remembering which one comes first. Also, x/y
> offset could also be edited in a more visual way, by dragging with the mouse.
> Another example for this is filter: ⬛ hue-rotate(⬤ 12deg);
> Do we want to have both an inline editor for the angle (which is useful for
> other properties too) and another one for the filter property as a whole?
> 
> box-shadow: ⬛ 1px 2px 0 2px ⬤ red,
>             ⬛ 0 0 20px 0 ⬤ blue;
> Even more complex, many CSS properties accept multiple values like
> box-shadow.
I think that all of these might just merit one editor (an editor for filters, an editor for box-shadow, etc). Rules where it would be appropriate to have a color editor will need one planned into the editor.

> But doing this requires being able to edit more than 1 property at once.
> Should the editor add new properties if needed? If yes, should it try to
> find inherited rules that might define these properties already and set the
> values there?
I think that the editor should just add new properties to the class the user has the inline editor open on to avoid confusion. Yes, I also think they should be able to add new properties.

Comment 5

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: example-inline-editor-spec-sheet.jpg

Comment 7

[Sebastian Zartner [:sebo]]

(In reply to Patrick Brosset <:pbro> from comment #0)
> As agreed at the Visual Tools work-week in Toronto (March 2016), we want to
> introduce "inline-editors" in the rule-view that expand within the view
> itself, below a given property or fragment that is being edited.

Can you please explain the reasoning behind that? I believe a big advantage of having tooltips for this case is that they don't interfere the panel layout.
I imagine it would be pretty annoying for people if there was an inline editor opened for their 'color' property and they'd have to scroll down the panel to see the the properties following it.

(In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #4)
> (In reply to Patrick Brosset [:pbro] from comment #2)
> > background: linear-gradient(⬤ red, ⬤ blue);
> > A little more complex, there are 2 editable values here.
> > After having open one color editor, should clicking on a second one open a
> > second editor below that, or should it replace the first one.

I'd say, replace the first one. Same reasoning as above, to avoid scrolling, but also to keep the reference between color and widget.

> > box-shadow: ⬛ 1px 2px 0 2px ⬤ red;
> > A little more complex again. There's a color in there, but we might also
> > want an inline editor for the whole shadow property.
> > Should the color be editable independently still (by clicking on the circle
> > next to it), or should the shadow only be editable as a whole (by clicking
> > on the square at the beginning)?
> > A shadow visual editor would be useful because it makes it obvious to edit
> > the spread or blur without remembering which one comes first. Also, x/y
> > offset could also be edited in a more visual way, by dragging with the mouse.
> > Another example for this is filter: ⬛ hue-rotate(⬤ 12deg);
> > Do we want to have both an inline editor for the angle (which is useful for
> > other properties too) and another one for the filter property as a whole?

Keep both to have a better UX when only wanting to edit the angle or color.

> > box-shadow: ⬛ 1px 2px 0 2px ⬤ red,
> >             ⬛ 0 0 20px 0 ⬤ blue;
> > Even more complex, many CSS properties accept multiple values like
> > box-shadow.
> I think that all of these might just merit one editor (an editor for
> filters, an editor for box-shadow, etc). Rules where it would be appropriate
> to have a color editor will need one planned into the editor.

Agree, only one for the list of values. (But the doorhangers for the colors should still be kept for the reasoning above.)

> > But doing this requires being able to edit more than 1 property at once.
> > Should the editor add new properties if needed? If yes, should it try to
> > find inherited rules that might define these properties already and set the
> > values there?
> I think that the editor should just add new properties to the class the user
> has the inline editor open on to avoid confusion. Yes, I also think they
> should be able to add new properties.

Agree.

Sebastian

Comment 8

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: example-inline-editor-spec-sheet.png

Updated the designs a little bit.

Comment 9

[Nicolas Chevobbe [:nchevobbe]]

Helen, could you try to mockup how it would be like to edit a single color for a long gradient value (thus, that wrap across multiple lines). 

Something like : `
  background: linear-gradient(
      to right, 
      rgba(183,222,237,1), 
      rgba(33,180,226,1), 
      rgba(31,170,217,.5), 
      #F06, 
      #f00
    );
`

So here, what would it looks like if we edit the first color stop of the gradient.

Comment 10

[Patrick Brosset <:pbro>]

My 2 cents:
I wouldn't allow editing a single color in a linear-gradient, but instead have a gradient editor that opens up below the value (after the last line), and that let's you quickly edit colors (but also positions and angle)

Comment 11

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #9)
> Helen, could you try to mockup how it would be like to edit a single color
> for a long gradient value (thus, that wrap across multiple lines). 
> 
> Something like : `
>   background: linear-gradient(
>       to right, 
>       rgba(183,222,237,1), 
>       rgba(33,180,226,1), 
>       rgba(31,170,217,.5), 
>       #F06, 
>       #f00
>     );
> `
> 
> So here, what would it looks like if we edit the first color stop of the
> gradient.

I was thinking along the same lines as Patrick—I was thinking for gradients, it would probably merit its own separate editor. (Most GUIs for editing gradients allow you to create tops and edit the color of those stops, and I think that this editor wouldn't capture that very well.)

Comment 12

[Helen V. Holmes (:helenvholmes) (:✨)]

Patrick, this bug currently only has the mockup for the color picker in it but the discussion and title are more general. Should we repurpose it to make it a metabug for all the rule inline editors now that we have bug 1272148, bug 1277182, bug 1151468, and will probably have more in the future?

Comment 13

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: inline-editor-color-picker-spec.png

Added in color contrast check to the designs.

Comment 14

[Patrick Brosset <:pbro>]

(In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #12)
> Patrick, this bug currently only has the mockup for the color picker in it
> but the discussion and title are more general. Should we repurpose it to
> make it a metabug for all the rule inline editors now that we have bug
> 1272148, bug 1277182, bug 1151468, and will probably have more in the future?
Yes, making this a meta bug seems fine.
Gabriel is assigned here for Q2 to work on this bug, but there are no patches applied yet, so we can totally make this a meta bug and file child bug as needed.

So I filed bug 1277352 for the color picker. And assigned Gabriel to it.
Making this one a meta.

Comment 15

[Łukasz]

I suggest you also add colors: Analogous, Compound, Complementary, Shades, Triad, Monochromatic like e.g. on  https://color.adobe.com

Comment 16

[Gabriel Luong [:gl] (ΦωΦ)]

As we implement these inline editors or refreshed editors for css properties, we should also consider how they would look if the container was a popup.

There are some scenarios where we might have a swatch inside a source editor, and in these cases we might want to open up a popup while an inline widget is usually also possible. An example of this can be seen in Chrome's color picker in Sources https://twitter.com/addyosmani/status/757661766255939586/photo/1

Comment 17

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: inline-editor-color-picker-spec.png

(In reply to Gabriel Luong [:gl] (ΦωΦ) from comment #16)
> As we implement these inline editors or refreshed editors for css
> properties, we should also consider how they would look if the container was
> a popup.
> 
> There are some scenarios where we might have a swatch inside a source
> editor, and in these cases we might want to open up a popup while an inline
> widget is usually also possible. An example of this can be seen in Chrome's
> color picker in Sources
> https://twitter.com/addyosmani/status/757661766255939586/photo/1

That's a good point. I've updated the spec to have a popup version of the color picker near the bottom.

I think in places where we have popups we don't need to expose all of the functionality we have in the inline editors; super large popups can grow unwieldy. Popups are unwieldy enough as it is, really!

Can you look over this Gabe?

Comment 18

[Gabriel Luong [:gl] (ΦωΦ)]

Comment on attachment 8777900 [details]
inline-editor-color-picker-spec.png

Looks good Helen!

Comment 19

[shkamaru]

Hi, I would like to work on this, as GSoc applicant. Kindly provide me access  to the screenshots above. Also where can I start solving bugs?

Comment 20

[Gabriel Luong [:gl] (ΦωΦ)]

(In reply to singhi.pramit from comment #19)
> Hi, I would like to work on this, as GSoc applicant. Kindly provide me
> access  to the screenshots above. Also where can I start solving bugs?

Hi Singhi,

You can find the respective bugs and screenshots for each tool in the "Depends on" category. Also, here: https://bugzilla.mozilla.org/showdependencytree.cgi?id=1258390&hide_resolved=1

The current state is that we have students already working on the new color widget that you see in the project. The point of the GSoC project is that you would select a widget or a number of features and break it down similar to how you can see the color widget is broken done to easily implementable and landable pieces in your proposal.

Comment 21

[Sebastian Zartner [:sebo]]

I believe the implementation of the inline editor is independent of the implementation of individual widgets. The widgets could also first be implemented as tooltips and later on be turned into inline editors. So this bug should not block bug 711942 and bug 1242029.

Sebastian