Patrick Brosset <:pbro> Reporter
	Description • 8 years ago

+++ This bug was initially created as a clone of Bug #1277079 +++

Steps to reproduce:

Open CSS filter property on any element. Click the filter button.

A slider with visual representation of changes would make the most sense.

	Patrick Brosset <:pbro> Reporter
	Comment 1 • 8 years ago

This came from @Una, in this twitter conversation: https://twitter.com/Una/status/737759824776073216

This was brought up in the past a few times. Let's review the various filter functions and see:

- blur is a CSS length that can go from 0 to anything.

==> Having a slider for this isn't really possible because there is no upper limit.

- brightness is expressed in a percentage (or unitless where 0 is 0% and 1 is 100%), and can go from 0 to Infinity. Well, not really Infinity, but setting a brightness of 500% really is different than 100%. 100% is actually the default brightness of the image, and you can use lower values to make it darker and higher values to make it brighter. In practice, in my test, anything above 1500% didn't seem to make a visible difference anymore, but that is not the point, as long as the value is a valid percentage and ends up giving a valid CSS filter, then the filter tooltip should allow it.
For instance, filter: brightness(50000000%); is valid.

- contrast, saturate and sepia work like brightness.

==> Having a slider for these isn't really possible because there is no upper limit.

- invert is also a percentage that goes from 0 to Infinity (as in, values above 100% are valid), but unlike the above, anything above 100% has no visible effect.
So even if filter: invert(200%); is valid, the value is really capped at 100%.

- Same for grayscale and opacity.

==> Having a slider for these could be an option if you just limited the value to 100%, which is what users are going to need anyway.

- hue-rotate is a CSS angle, expressed in any angle unit (grad, rad, deg, turn), and can go from -Infinity to +Infinity. That is you can enter any value because it just cycles back after 360deg/1turn/...
Not that you'd do this in many cases, but things like filter: hue-rotate(1000turn); are valid.

==> Having a slider for this isn't really possible because there is no lower or upper limit.


This is why, when the tooltip was implemented, we chose to have input fields to let users type in numbers instead.
Having said this, we also added mouse interaction to change those numbers. It isn't very intuitive perhaps, but if you drag (click and hold) on a label (i.e. the word "blur" in the UI) and start moving your mouse along the X axis, then that will change the value (you can even hold shift and alt to alter the rate at which the value changes).
Some are bound between 0 and 100, some are only bound to 0 but can go to any positive value, etc...
Because you don't have a slider  UI that's constrained between 2 limits, that makes it a better fit for this particular UI.

If we really wanted slider inputs in the UI, then I think we'd have to come up with sensible limits. Like maybe 0% to 1000% for brightness, and so on.
And I think we'd still have to keep the text input fields next to them because there are cases where users are going to want to enter numbers by hands. As the range of possible values gets higher, sliders get less and less useful.

@Helen: your input on this would be nice. I know we can make the UX of this tooltip better, but for the reasons explained above, I don't think just adding sliders to all functions is as simple as it seems. I know when you first open the tooltip, you immediately feel like there should be sliders so you can play around with things. But sliders are pretty limiting compared to what you can do with filters.

	Helen V. Holmes (:helenvholmes) (:✨)
	Comment 2 • 8 years ago

I have a version already designed + built with sliders here: http://helenvholmes.com/devtools-ux/css-filter/ (I think it only works in Nightly). I held off on it since I know we're doing the work in Bug 1258390 and wasn't sure how I would translate it all yet.

While the sliders don't capture the precision of spec exactly, they do surface how filters work pretty well. I'll go through the properties anyway though:

blur: while the upper bound can be limitless, it's relative to the size of the thing it's blurring—that is to say, at a certain point, the blur will cease to do anything. This gives us a range for our blurs in my opinion, which is probably the large-end of web-safe image sizes.

brightness, contrast, saturate sepia: our slider could go to 200% as a default just to illustrate that higher bounds are allowed. Alternatively, the range on these sliders could be 1500%, although that would get finnicky if you were actually trying to use the slider so I wouldn't recommend that.

invert, grayscale, opacity: sliders will work well for these, moving on

hue-rotate: this is the one where I felt bad having a slider, since design editors normally represent this in a different way: http://cl.ly/2k3w1b2M2V0v I imagine that we'll want to share design elements with bug 711942 since we'll want to display angle editors in the same way in different places.

We definitely need to keep the text field inputs. Right now in my demo only a few of the (...) next to the fields work (blur does).

Speaking to philosophy of the editors: yeah, sliders are pretty limiting compared to what you can do with filters. Filters encourage play, though, and quick experimentation. Having the sliders with reasonable upperbounds would still probably be an improvement.

	Patrick Brosset <:pbro> Reporter
	Comment 3 • 8 years ago

Inspector bug triage (filter on CLIMBING SHOES).

	Patrick Brosset <:pbro> Reporter
	Comment 4 • 8 years ago

Definitely not a P1 enhancement at this stage. Let's demote this to P2. 2016 Q4 doesn't contain goals for us to work on this. Maybe 2017 Q1.