Bug 1637843 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Taking a closer look at this control there's a few things that could be improved specifically to make the numbers more meaningful.

* Ideally the number value would correspond to the font size similar to Google Docs or other tools where a users adjusts font size. The numbers provide value in a few ways. 1. As mentioned they give a reference to the bottom limit (and could do something similar for an upper limit if they better matched a traditional font size scale). 2. They provide a reference to users who want a quick way to find/return to a setting they preferred in the past. 3. In a potential future version we can allow users to type their size preference avoiding the need to click multiple times to find find their font size of choice.

* The value between increase/decrease width should be a percentage (e.g. 60%, 70%, etc) not a number value which would make it more meaningful.

* For line height the numbers should correspond to a multiplier of the default line height. So, we'd have something like 1, 1.15, 1.5, and 2.

Looks like there's also a minor bug for the vertical alignment of the number and another I'm encountering where the line height doesn't change and menu closes when pressed.
Taking a closer look there are a few things that could be improved. Specifically making the numbers more meaningful.

* Ideally the number value would correspond to the font size similar to Google Docs or other tools where a users adjusts font size. The numbers provide value in a few ways. 1. As mentioned they give a reference to the bottom limit (and could do something similar for an upper limit if they better matched a traditional font size scale). 2. They provide a reference to users who want a quick way to find/return to a setting they preferred in the past. 3. In a potential future version we can allow users to type their size preference avoiding the need to click multiple times to find find their font size of choice.

* The value between increase/decrease width should be a percentage (e.g. 60%, 70%, etc) not a number value which would make it more meaningful.

* For line height the numbers should correspond to a multiplier of the default line height. So, we'd have something like 1, 1.15, 1.5, and 2.

Looks like there's also a minor bug for the vertical alignment of the number and another I'm encountering where the line height doesn't change and menu closes when pressed.
Taking a closer look there are a few things that could be improved. Specifically making the numbers more meaningful.

* Ideally the number value would correspond to the font size similar to Google Docs or other tools where a users adjusts font size. The numbers provide value in a few ways. 1. As mentioned they give a reference to the bottom limit (and could do something similar for an upper limit if they better matched a traditional font size scale). 2. They provide a reference to users who want a quick way to find/return to a setting they preferred in the past. 3. In a potential future version we can allow users to type their size preference avoiding the need to click multiple times to find their size of choice.

* The value between increase/decrease width should be a percentage (e.g. 60%, 70%, etc) not a number value which would make it more meaningful.

* For line height the numbers should correspond to a multiplier of the default line height. So, we'd have something like 1, 1.15, 1.5, and 2.

Looks like there's also a minor bug for the vertical alignment of the number and another I'm encountering where the line height doesn't change and menu closes when pressed.

Back to Bug 1637843 Comment 4