[5.2] Adding Color Picker re-re-based #35639

thednp · 2021-09-22T12:44:59Z

Due to some complications, the previous commit didn't work.

Pull Request for Issue #32494.

Demo page of the color-picker component right here.

Summary of Changes

removed most minicolors assets
added tinycolor asset
added the new joomla-field-color-picker.es6.js as described in [NEW] The future color picker for Joomla is here #32494
updated the layouts/joomla/form/field/color/advanced.php file
updated 3 language files
updated most assets related json files with the new assets
updated the build scripts

Testing Instructions

JavaScript Testing
The most important test for me, please report any error in the console along with the following info:

Machine Operating System + Version
Browser Name + Version

Existing Extensions Testing

Open an extension that uses a <field type="Color" control="advanced"> field;
Check if the <color-picker> updates the background of the visible input with the value stored in the database; if not the script is missing, not initialized or something happened, see below;
If the above fails, check the browser console and check for any ColorPicker or TinyColor related errors; Report back here any error you encounter; I really hope there won't be;
If however no error is reported in the browser console, click on the visible input to open the .color-dropdown then click anywhere outside of it, the .color-dropdown should close;
Click on the visible input and pick a new color;
Save the extension settings and check if the value is the one you have previously set in the above step;
While the .color-dropdown element is visible try and resize the window, see if the console pops any error;
While the window is under 768px wide and under 600px high, click the visible color input field and check where the .color-dropdown element is rendered (above or below the visible input), then scroll the window up/down while open to check if the .color-dropdown element should be re-positioned where it has the most available space;

Color Picker Options Testing

Open /templates/cassiopeia/templateDetails.xml, find the <fieldset name="advanced"> tag and paste inside the following code:

<field
	name="advanced-color-hex"
	type="Color"
	format="hex"
	keywords="false"
	hint="Type in a valid hexadecimal colour value"
	default="#069"
	label="Text Color" />

<field
	name="advanced-color-rgb"
	type="Color"
	required="true"
	format="rgb"
	default="rgb(0,102,153)"
	label="Primary Color" />

<field
	name="advanced-color-hsl"
	type="Color"
	required="true"
	format="hsl"
	keywords="navy,lime,crimson,chocolate"
	default="hsla(265,100%,50%,.8)"
	label="Secondary Color" />

<field name="advanced-color-hex"> sets the keywords="false" which disables the usage of presets and restricts the color-picker to only use format="hex" colors (in this particular case); the reason for this behavior is the need to send SCSS compilers real and valid HEX/RGB(a)/HSL(a) color values to be used for mixins, eg. darken($primary,15%) (darken('inherit',15%) won't work); this field should use a placeholder;
<field name="advanced-color-rgb"> does not set the keywords option and will use the default keywords: transparent, curentColor, initial and inherit; as a result, the color-picker will display a button on the right side of the visible input to open a color options menu; these "non-color" values are valid CSS values; this field is required;
<field name="advanced-color-hsl"> sets the keywords="navy,crimson.." and enables the usage of user defined presets based on web safe color names; because none of the above "non-color" keywords is present in the setting value, color-picker will again restrict values to only valid HSL(a) format colors for the same known reasons.

Keyboard Events Testing

While the .color-dropdown is displayed, hit the ESC key of your keyboard, it should close/hide the element;
While viewing a Joomla form page with a <field type="Color">, try and navigate the page with your keyboard, when you focus a color-picker it should open its .color-dropdown and allow you to navigate inside;
For the <field type="Color" keywords="false"> delete the current value in the visible input first then try typing "inherit", "transparent" or "currentColor", it should set #000000 value;
For the <field type="Color" keywords="navy,crimson.."> delete the current value in the visible input first then try typing "inherit", "transparent" or "currentColor", it should set a valid HEX/RGB(a)/HSL(a) value;
For the <field type="Color"> which uses no keywords option. delete the current value in the visible input first then try typing "inherit", "transparent" or "currentColor", it should set that value;
Test the visible input(s) of the .color-dropdown (where format is either "rgb" or "hsl"), focus one of them and try and change values by using the up/down buttons of the keyboard, it should instantly update the color picker on every change;
Test the visible input(s) of the .color-dropdown (where format is either "rgb" or "hsl"), focus one of them and try and type 0-255 for "R", "G" or "B" for the <field type="Color" format="rgb"> field or 0-359 for "H", 0-100 for "S" or "L" for the <field type="Color" format="hsl"> , it should update the color picker on every change after a short delay (TinyColor will validate that color first);
For the <field type="Color" format="hsl">, if the "L" (Lightness component) is 100, the "S" (Saturation component) and the "H" (Hue component) both should be locked at 0, then decrease lightness to 99 and this will unlock Saturation control, ultimately if you set Lightness to less than 100 and Saturation to at least 1, this will ultimately unlock Hue control (this will be explained in the documentation).

Testing the "onchange"
The implementation is similar with fancy-select, so you as tester, as well as third party devs should have a familiar feeling about color picker. For any of your <field type="Color" control="advanced"> make sure to also test "onchange":

when typing values into inputs;
when you slide the color-picker controls.

Mobile Testing

Tap the visible input to open the color-picker and check if the visible input, the .color-dropdown and the mobile keyboard all are displayed on the mobile device screen; the color-picker will decrease its height by around 25% to fit most mobile devices;
Try and reproduce all the tests explained above except everything to do with checking the browser console; we're interested in the behavior of the color-picker, it should feel snappy and accurate; it should dismiss the opened .color-dropdown popup on taping outside the element itself;

Accessibility Testing
Check the labels of all the visible inputs, find any ARIA related issues, report back anything you think it's not good enough in terms of accessibility, ARIA and so on.

The main focus:

while the <joomla-field-color-picker> element is focused, hit Enter/Space to toggle the color picker visibility
while closed, try Tab key, it should go to the next form field
while open, try Tab key, it should navigate all focusable elements
while open, try changing the visible pointers/sliders as well as the visible text inputs with arrow keys
open your screen reader and try all the above with the screen reader scanning all your values and everything ARIA related.

Actual result BEFORE applying this Pull Request

All type="color" fields that use control="advanced" are outdated in terms of accessibility, usability and jQuery dependency.

Expected result AFTER applying this Pull Request

All your type="Color" fields that use control="advanced" are super awesome on any device and any user.

Documentation Changes Required

This documentation section mentions nothing about the control property/setting of the Color field, the following is a draft to provide guidance for this Joomla form field type as coded in libraries\src\Form\Field\ColorField.php in Joomla 4.0. Some parts of it need to be updated by their developer or some Joomla intern knowledgeable of this particular form field.

Documentation Draft

Provides a flexible form field that allow you to set a colour, with controls ranging from simple to advanced.

name (mandatory) is the unique name of the parameter.
type (mandatory) must be "Color".
default (optional) provides a colour value when not set.
format (optional) allows you to select the type of colour format, you can select "rgb", "rgba", "hsl", "hsla" or "hex".
control (optional) allows you to select the type of controls the user need to set a colour, you can select "simple", "slider" or "advanced". The default is "advanced."
colors (optional) allows you to set a list of colours to be used for the "simple" control. Shorthand HEX colors are not supported ("#fff"). Eg. colors="#ff0000,#0000ff".
display (optional) allows you to display a single component for the "slider" control. You can set "hue", "saturation", "light" or "alpha".
keywords (optional) allows you to set color presets for the "advanced" control. The default value is keywords="initial,inherit,currentColor,transparent", however you can disable the feature by using keywords="false" which will restrict the color picker to only use valid HEX, RGB(a) or HSL(a) values. If you include any of the default value (eg. "inherit") in the keywords list, it will remove the restriction.
label (mandatory) (translatable) is the descriptive title of the field.
description (optional) (translatable) allow you to provide more details for the form field.

Note on HSL(a) Format and Advanced Control

TinyColor is the script behind the color picker of the "advanced" control. This script will understand that values like hsl(0, 0%, 100%) and hsl(150, 0%, 100%) are visually identical, it will use the hsl(0, 0%, 100%) value. In addition, if the L (Lightness component) is 100% then the S (Saturation component) and the H (Hue component) both should be locked at 0 in the inputs of the color picker; if you decrease Lightness to 99% it will unlock Saturation control, ultimately if you set Lightness to less than 100% and Saturation to at least 1%, this will unlock Hue control.

Example XML Definition for Simple Control:

<field name="backgroundcolor"
	type="Color"
	format="hex"
	default="#ff0000"
	control="simple"
	colors="#ff0000,#008000,#0000ff"
	label="TPL_BEEZ3_FIELD_HEADER_BACKGROUND_COLOR_LABEL"
	description="TPL_BEEZ3_FIELD_HEADER_BACKGROUND_COLOR_DESC" />

Example XML Definition for Slider Control: (this part need to be updated by its developer)

<field name="backgroundcolor" 
	type="Color" 
	default="#ff0000" 
	format="hex"
	control="slider"
	display="hue"
	label="TPL_BEEZ3_FIELD_HEADER_BACKGROUND_COLOR_LABEL"
	description="TPL_BEEZ3_FIELD_HEADER_BACKGROUND_COLOR_DESC" />

Example XML Definition for Advanced Control:

<field name="backgroundcolor" 
	type="Color" 
	format="rgb"
	control="advanced"
	default="rgb(250,0,0)"
	keywords="initial,inherit,transparent,navy,lime" 
	label="TPL_BEEZ3_FIELD_HEADER_BACKGROUND_COLOR_LABEL"
	description="TPL_BEEZ3_FIELD_HEADER_BACKGROUND_COLOR_DESC" />

thednp · 2021-09-22T12:48:22Z

@dgrammatiko this is a completely rebased commit, still DART-SASS issues. As you can see, all changes are all about removing minicolors and replacing it with our color-picker. There is nothing wrong here.

dgrammatiko · 2021-09-22T13:00:43Z

still DART-SASS issue

That's weird. The SASS package is the one that is defined in the package.json on the root of the repo and it doesn't throw any errors for the same files. Maybe an app like https://www.sourcetreeapp.com can help you here (figure out the point that your branch is created, normally if this is a new PR that should be the tip of the 4.1-dev.)

thednp · 2021-09-22T13:06:37Z

Probably changing the SCSS sources too much will result in the issue, but I found another problem.

In my local repository, I didn't do the composer install action yet and npm install will always fail because many scss files from templates import stuff from the media folder which doesn't exist, which makes me think the official 4.1-dev branch is missing something. Something that I didn't have to deal with when I previously commited to 4.0-dev branch before.

dgrammatiko · 2021-09-22T13:14:43Z

I didn't do the composer install action yet

The composer install needs to be done before the npm install. That's expected

thednp · 2021-09-22T13:17:01Z

Something isn't right.

EDIT: I just did a composer install then npm install and got the exact same error as the online build testing.
I think something is wrong with the 4.1-dev build.

EDIT 2: it must be related to what @brianteeman said yesterday, there were some files changed unrelated to my commit.

thednp · 2021-09-22T14:18:22Z

Guys, I can nail down these pesky SCSS issues real quick ($font-size: $some-var / 2 => $font-size: $some-var * .5). I think it's the expected SCSS format in the future and probably SCSS lint will also consider that in the future.

Just let me know.

dgrammatiko · 2021-09-22T14:23:20Z

@thednp please make another PR that will change the division according to SASS docs: https://sass-lang.com/documentation/breaking-changes/slash-div

So your example

$font-size: $some-var / 2;

should be written as:

$font-size: math.div($some-var, 2);

thednp · 2021-09-22T14:43:09Z

That won't work with our medialize/sass unfortunately. and Bootstrap devs still count on it, see their variables.scss. My solution I posted above is the better one, for now, at least for the front-end side of things, since the back-end SCSS is compiled on build via node_modules/sass (dart-sass).

thednp · 2021-09-22T15:16:27Z

@dgrammatiko 5min into the job: $fa-fw-width: (20em / 16); file joomla-cms\media\vendor\fontawesome-free\scss_variables.scss as well as font-awesome repository.

Do we fix/resolve 3rd party code quality?

dgrammatiko · 2021-09-22T15:18:24Z

Do we fix/resolve 3rd party code quality?

Not in this repo. We can either do a PR to their repo or wait till someone else fixes it...

thednp · 2021-09-22T15:19:48Z

We can just override the value with $fa-fw-width: (20em * .0625); (width * 1/16).

For instance joomla-cms\build\media_source\com_media\scss\components_media-infobar.scss overrides $fa-css-prefix: fa;

dgrammatiko · 2021-09-22T15:21:32Z

We can just override the value with $fa-fw-width: (20em * .0625); (width * 1/16)

If you can override it then should be fine, we already overriding the path, etc

thednp · 2021-09-22T16:06:20Z

We may have to override the entire variables.scss file because $fa-fw-width is not marked with !default and the compiler does not like it.

brianteeman · 2021-09-22T16:09:15Z

You can not remove the minicolors css or js as they may be used by extensions and they have not been marked as deprecated

thednp · 2021-09-22T16:17:30Z

So instead of removing minicolors assets and references in the asset json files, we have our color-picker separate?

dgrammatiko · 2021-09-22T16:22:27Z

So instead of removing minicolors assets and references in the asset json files, we have our color-picker separate?

No that's not what Brian meant. The js+css needs to be in the media/vendor folder but not in the assets.josn. Basically you need to revert some of the changes in the build/settings.json...

package.json

build/media_source/system/js/fields/color-field-adv-init.es5.js

administrator/components/com_admin/script.php

build/build-modules-js/init/recreate-media.es6.js

build/build-modules-js/settings.json

build/media_source/system/joomla.asset.json

layouts/joomla/form/field/color/advanced.php

thednp · 2021-09-23T19:46:00Z

Thanks @PhilETaylor

Reverting deletion of minicolors in templates.

dgrammatiko · 2021-09-25T10:29:19Z

@thednp the CI failure will be fixed once #35518 and #35666 are merged

thednp · 2021-09-25T10:32:07Z

@dgrammatiko man, I put back minicolors and still no go. I think the problem is very much related to the build/media_source/system/scss/fields/joomla-field-color-picker.scss.

It may be a problem with the SCSS + JS compile function in the build folders.

dgrammatiko · 2021-09-25T10:34:03Z

@thednp has nothing to do with your code, the failure is in bootstrap.scss

FWIW if you apply both the PRs from #35639 (comment) CI will be fine

thednp · 2021-09-25T10:42:22Z

Alright buddy, what about my fixes in #35648?

Also, any news on the TinyMCE improvements? Anything I can give it a try or input?

dgrammatiko · 2021-09-25T10:53:37Z

Alright buddy, what about my fixes in #35648?

That is valid (I think I'm not a SCSS person)

Also, any news on the TinyMCE improvements?

There will be a POC PR today, I'm just trying to introduce all the changes without an B/C breaks or a bazzilion of cryptic options

thednp · 2021-09-25T10:58:47Z

Alright buddy, what about my fixes in #35648?

That is valid (I think I'm not a SCSS person)

To my research, those fixes are absolutely needed in dart-sass 2.0, it would be a waste of somebody's time someday to find and nail them down like I did.

Also, any news on the TinyMCE improvements?

There will be a POC PR today, I'm just trying to introduce all the changes without an B/C breaks or a bazzilion of cryptic options

Sweet, please tag me in.

HLeithner · 2022-06-27T13:07:21Z

This pull request has automatically rebased to 4.2-dev.

HLeithner · 2023-05-02T16:43:02Z

This pull request has been automatically rebased to 5.0-dev.

HLeithner · 2023-09-30T22:52:21Z

This pull request has been automatically rebased to 5.1-dev.

HLeithner · 2024-04-24T09:10:01Z

This pull request has been automatically rebased to 5.2-dev.

thednp and others added 2 commits September 22, 2021 12:14

Update package.json

211ad17

Re-commit

1a43912

joomla-cms-bot added Language Change This is for Translators NPM Resource Changed This Pull Request can't be tested by Patchtester PR-4.1-dev labels Sep 22, 2021

thednp mentioned this pull request Sep 22, 2021

[4.1-dev] Fixing SCSS issues with division deprecation and math.div() #35645

Closed