[meta] Rule-view inline editor widget

NEW
Unassigned

Status

P2
enhancement
3 years ago
3 months ago

People

(Reporter: pbro, Unassigned)

Tracking

(Depends on: 3 bugs, Blocks: 1 bug, {meta})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [btpp-fix-later])

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
Helen designed the first inline editor for editing colors:
https://projects.invisionapp.com/d/main#/console/5476602/143217180/preview
(Reporter)

Comment 2

3 years ago
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
(Reporter)

Comment 3

3 years ago
(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?
(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.

Updated

3 years ago
Assignee: nobody → gl
(Reporter)

Updated

3 years ago
Status: NEW → ASSIGNED
Created attachment 8743846 [details]
example-inline-editor-spec-sheet.jpg
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1065210
See Also: → bug 990742
See Also: → bug 1001583
(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
Created attachment 8751485 [details]
example-inline-editor-spec-sheet.png

Updated the designs a little bit.
Attachment #8743846 - Attachment is obsolete: true
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.
(Reporter)

Comment 10

2 years ago
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)
(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.)
(Reporter)

Updated

2 years ago
See Also: → bug 1275029
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?
Flags: needinfo?(pbrosset)
Created attachment 8758765 [details]
inline-editor-color-picker-spec.png

Added in color contrast check to the designs.
Attachment #8751485 - Attachment is obsolete: true
(Reporter)

Updated

2 years ago
Depends on: 1277352
(Reporter)

Comment 14

2 years ago
(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.
Assignee: gl → nobody
Severity: normal → enhancement
Status: ASSIGNED → NEW
Component: Developer Tools: Inspector → Developer Tools: CSS Rules Inspector
Flags: needinfo?(pbrosset)
Keywords: meta
(Reporter)

Updated

2 years ago
No longer blocks: 1217301, 1272148
Depends on: 1217301, 1272148

Comment 15

2 years ago
I suggest you also add colors: Analogous, Compound, Complementary, Shades, Triad, Monochromatic like e.g. on  https://color.adobe.com
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
Flags: needinfo?(hholmes)
Created attachment 8777900 [details]
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?
Attachment #8758765 - Attachment is obsolete: true
Flags: needinfo?(hholmes)
Attachment #8777900 - Flags: review?(gl)
Comment on attachment 8777900 [details]
inline-editor-color-picker-spec.png

Looks good Helen!
Attachment #8777900 - Flags: review?(gl) → review+

Updated

2 years ago
Depends on: 1307193

Updated

2 years ago
Depends on: 1307481

Updated

2 years ago
Summary: Rule-view inline editor widget → [meta] Rule-view inline editor widget

Comment 19

2 years ago
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?
(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.
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
No longer blocks: 1242029

Updated

3 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.