Please add more information to your issue. Without test instructions and/or any description we will close this issue within 4 weeks. Thanks.
This is an automated message from the J!Tracker Application.

@dgrammatiko I completed what I said, I think the build fails to find the tinycolor becase we gave it a wrong path? perhaps the file name you suggested wasn't correct tinycolor.w-c.es6.js?

@dgrammatiko I completed what I said, I think the build fails to find the tinycolor becase we gave it a wrong path? perhaps the file name you suggested wasn't correct?

You have to run npm install @ctrl/tinycolor -S to bring the asset in the dependencies. This will update the package.json and the package.json.lock. Right now you're referring to a file that is not existing nowhere.

Hold on, I think I get it, I'm checking out this on my machine and try there to install and commit back to git.

Hold on, I think I get it, I'm checking out this on my machine and try there to install and commit back to git.

Exactly, and once yo'll there run also npm run lint:js to make sure the js is following the Code Style of the project

I'm now cleaning up everything minicolors, hold on.

What's this for administrator\components\com_admin\script.php it mentions minicolors and I just found it out. Is is automatically generated? or should I update it as well?

You have to add there the files you're deleting (media/vendor/minicolors... )

I will update that in the next commit to my repo, I'm now going to lint and build again.

Note: on install I got some minor error with dependencies. Probably there need to be some cleanup there.

@dgrammatiko I'm getting this error on npm run build:js

Error: ENOENT: no such file or directory, open '\Joomla SVN\media\system\css\joomla-toolbar-button.css'

right after

Transpiling Web Component file: \Joomla SVN\build\media_source\system\js\fields\tinycolor.w-c.es6.js

ideas?

Anyways, I've updated the package.json I should try and commit see what the online tools get, ei?

I'm still getting the same error (posted above) trying to do build locally. The online continuous-integration says something about [Error: ENOENT: no such file or directory, stat '/********/src/node_modules/@ctrl/tinycolor/tinycolor.js'] probably it's looking for a fie that doesn't exist.

So yea, I don't know how to fix this. This is beyond me.

So yea, I don't know how to fix this. This is beyond me.

Follow the path, you should find a dist folder with the file that you need. Point the settings.json to the right path

Reminder: tinycolor is Typescript sourced. How can we set the build script to not look for a source and just use our source that I've uploaded.

@thednp please check node_modules/@ctrl/tinycolor/dist. The JS ecosytem works like that for a decade...

Yes, that is true, however, perhaps I'm burned out working since Monday non-stop on this trying to finish it, I'm soo tired I can't figure out what to do. I appreciate any hint or suggestion. I tried everything, the build script stops trying to find some CSS file.

build/build-modules-js/settings.json

      "@ctrl/tinycolor": {
        "name": "tinycolor",
        "js": {
          "dist/index.js": "js/tinycolor.js" 
        },
        "dependencies": [],
        "provideAssets": [
          {
            "name": "tinycolor",
            "type": "script",
            "uri": "dist/index.js",
            "attributes": {
              "defer": true
            }
          },
          {
            "name": "tinycolor",
            "type": "preset",
            "dependencies": [
              "tinycolor#script"
            ]
          }
        ],
        "licenseFilename": "LICENSE.md"
      },

dist/index.js is actually the path to node_modules/@ctrl/tinycolor/dist/index.js

Run eslint --config build/.eslintrc --ignore-pattern '/media/' --fix --ext .es6.js,.es6,.vue . to fix most of the Code Style errors

Seems I need to do some lint work, I will get back to it tomorrow.

Thanks guys.

@dgrammatiko please how can I solve the build/build-modules-js/settings.json to make it compile TinyColor and to properly update the media/system/joomla.asset.json?

The build script skips the tinycolor compilation.

Do you still need help on that or did you just work it out?

@brianteeman yes, I need help.

In my local version those lines are not present.

Then you have a problem in your local branch

I think the problem you are having with minification is that the compilejs script does not look in the /media folder to find files to compress. @dgrammatiko should be able to help more on that as its above my payscale

This needs to await for #32315 to be merged and then do the simillar changes as the ones done in that PR for punycode and build/media_source/system/js/fields/validate.es6.js

This needs to await for #32315 to be merged and then do the simillar changes as the ones done in that PR for punycode and build/media_source/system/js/fields/validate.es6.js

That would hopefully help solve this

/********/src/build/media_source/system/js/fields/joomla-field-color-picker.es6.js
737:20  error  'TinyColor' is not defined  no-undef

737:20 error 'TinyColor' is not defined no-und

Yes but you have to revert the change were you deleted the import ... 6b0653d

So import is there to stay? Anyways, as you said it can wait.

Yes, but right now the build tools cannot resolve imports, they have to wait for #32315 to be merged

@dgrammatiko what about including some conversion functions within color-picker? We can have it fully support RGB(a), HSL(a), HEX without TinyColor, perhaps not 100% the best solution, but it will work and will be alot faster, IE10+ supported.

We might actually have it ready much before the other commit comes into place.

IE10+ supported.

Joomla 4 will NOT support IE10

@dgrammatiko what about including some conversion functions within color-picker

No. In general things that are widely available should be brought to the project through NPM. There's no reason for the project to support code that can just be imported. Just test the other PR and wait till ot gets merged

@dgrammatiko if import is there to stay, then on compile it will include TinyColor into color-picker bundle and will no longer be required in both build/build-modules-js/settings.json and build\media_source\system\joomla.asset.json. Then the PHP layout file will just ->useScript() instead of ->usePreset()->useScript().

On another note, I've been thinking about developing on the $keywords, by default it would have inherit, currentColor, transparent as default values, but devs can set keywords="false" to disable and explicitly ask from the user a real color to be used, as I explained above. Devs can set a plethora of keywords, TinyColor should work fine with all web safe colors EG: navy, lime, etc (256 of them I think).

This means that our color picker will have 2 dropdowns: one for color-dropdown (the picker itself) and one for keyword colors. You did mention something about buttons and stuff.

Ah another thing, I haven't implemented saveFormat. It should be easy peasy.

Let me know what you think.

@dgrammatiko as to your concerns, here is my proposal for keywords:

As shown in the image:

• By default keywords is set to currentColor,transparent,inherit like in the first example, color-picker will use white for the displayed chosen color, but the inputs will use the chosen keyword. This keyword value is NOT to be used in SCSS transformations like darken(), desaturate(), etc.
• The second example keywords="false" disables the color-menu and explicitly request a valid color from the user, these values MUST be safe for SCSS transformation;
• In the third example, keywords are set by devs, TinyColor kicks in and replace for instance navy with the appropriate rgb(0,0,128). These keywords are "safe" for SCSS transformations.

I think color-picker can and should replace any and all previous color input field layouts. As shown in this screenshot, there is nothing better to work with our system IMO.

I don't actually know what $keywords were originally supposed to do, this is the best use I can think of. What you see in the screenshots is working fine on my local install.

@brianteeman your input? In fact anyone is welcome to provide any feedback.

It is not normal practice in Joomla to introduce any file that is not copyright Joomla or GPL licenced if it is not a vendor supplied file and stored in a /vendor folder

You suggest we should rename License to GPL 2.0 for the joomla-field-color-picker.es6.js?

I think @dgrammatiko would like to say something about it, I only took the file as is and developed the rest of the features.

With that last commit, color-picker is pretty much complete, should I attempt to write a documentation draft?

Also, @dgrammatiko what's up with the other layouts of the Color field? Pretty much unusable on my end. Should I share some screenshots?

If the file is part of core and dnot vendor then it should be copyright joomla and gpl

If the file is part of core and dnot vendor then it should be copyright joomla and gpl

That's not true, there are several places where the code was committed with the original docblocks...

I did what I've been instructed, I only added my name next to the original file author's name. I don't mind either way as long as it's all good for the community.

@dgrammatiko do you want to publish this to npm as a 3rd party source?

@thednp I can't publish your code, if you want to do that you have every right. As is the code is fine as you attribute both the other 2 other authors. Also it should be fine for Joomla as is because there are other instances with similar docblocks

It's fine for me man, just let me know what needs to be changed.

@brianteeman I've updated the file header as discussed, and the above section to include a documentation draft, but there are a few things that might need clarification for the simple and slider control. Also I've added some additional testing instructions.

Important: There are also some inconsistencies in the libraries\src\Form\Field\ColorField.php that seem to be disconnected from the layouts, for instance:

• line 39 protected $control = 'hue'; but only works with 'simple', 'slider' and 'advanced';
• you cannot set "layout" property for the <field type="Color"> since the ColorField sets it based on the control property.

@dgrammatiko as I've provided a documentation draft in the head of this thread, your supervision is required. I also have to point out there are some issues with the other layouts that need to be solved.

@dgrammatiko I'm sorry to bother you, where can I talk to you without upsetting Brian again, I need to ask you about SCSS compile stuff.

twitter DM @ dgrammatiko

@dgrammatiko I've followed you @ dnp_theme

@dgrammatiko @brianteeman and anyone following this development.
I've been thinking about integrating $colors into our color picker, make it have all possible features in one place, the advanced layout can actually become the default and only layout for the ColorField. What do you say?

@Quy / @brianteeman
I've added a documentation draft at the top of the page, please update PR tags.

@richard67 we have a minor conflict here. If I edit that file in this repository, will the conflict go away?

@thednp It seems to be an easy conflict so GitHub shows a button "Resolve conflicts" at the bottom of the PR. If you use that button, the same will happen here on GitHub in their web UI as what would happen if you do on your local environment a merge of the 4.0-dev branch of the CMS repo (upstream) into your branch for this PR. It will show the same conflict for that file.

If you then edit the file (either online by using their button or locally after starting the merge), you will see that conflicts are marked in a special way, e.g. here now in file administrator/components/com_admin/script.php:

<<<<<<< patch-1
			// Joomla 4.0 Beta 8
			'administrator/templates/atum/scss/vendor/minicolors/minicolors.scss',
			'templates/cassiopeia/scss/vendor/_minicolors.scss',
=======
			// Joomla 4.0 Beta 7
			'/media/vendor/skipto/js/dropMenu.js',
			'/media/vendor/skipto/css/SkipTo.css',
>>>>>>> 4.0-dev

In very rare cases it is easy and you either take your part (between <<<<<<< patch-1 and =======) or "their" part (between ======= and >>>>>>> 4.0-dev), and often you have such options to take "yours" or "theirs" in IDEs or Git clients with GUI. But in most cases that's not right, and you have to resolve the conflict with a manual edit.

For the conflict here that would be:

			// Joomla 4.0 Beta 7
			'/media/vendor/skipto/js/dropMenu.js',
			'/media/vendor/skipto/css/SkipTo.css',
			// Joomla 4.0 Beta 8
			'administrator/templates/atum/scss/vendor/minicolors/minicolors.scss',
			'templates/cassiopeia/scss/vendor/_minicolors.scss',

I could solve that here, but I thought I explain you a bit so maybe you can learn that. Handling conflicts in software development is a useful knowledge (as long as you not always only develop alone on only one thing).

Let me know if I shall fix it for you, or if you prefer to try it yourself.

@thednp See also:

• https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-merge-conflicts
• https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github
• https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-using-the-command-line

Thanks @richard67 I think I managed.

@thednp Well done. Next conflict of the same kind will come when PR #31838 will be merged before this one. Then you can just solve it in the same way.

I've been thinking about integrating $colors into our color picker,

Please don't do that, smaller scripts solving particular problems are more efficient and maintainable than monolithic cover all cases scripts. Obviously, the Unix philosophy is proven to be the best one (small apps that do 1 thing ONLY) against the Windows philosophy one script that does gazzilion of things.

With that last commit and last update to the PR info, this baby is ready to test and hopefully RTC next week.

This requires merging of #32315

Have a good one.

I'm unsubscribing here, as all my comments are ignored

@thednp since the other PR was merged please do the following changes here:

• rename the file build/media_source/system/js/fields/joomla-field-color-picker.es6.js to build/media_source/system/js/fields/joomla-field-color-picker.w-c.es6.js
• copy the contents of the <style> to a new file build/media_source/system/scss/fields/joomla-field-color-picker.scss
• replace the <style> tag with <style>{{CSS_CONTENTS_PLACEHOLDER}}</style>

The content of the new file build/media_source/system/scss/fields/joomla-field-color-picker.scss should be:

:host {
   position: relative;
   display: flex
 }
 .color-dropdown {
   width: 100%;
   max-width: calc(100% - 1rem);
   background: rgba(0,0,0,0.75);
   color: rgba(255,255,255,0.8);
   box-shadow: 0 6px 12px rgba(0, 0, 0, 0.4);
   position: absolute;
   padding: 0.5rem;
   border-radius: 0.5rem;
   display: none;
   left:0;
   z-index: 50
 }
 .color-dropdown.show {
   top: calc(100% + 5px);
   display: block
 }
 .color-dropdown.show-top {
   bottom: calc(100% + 5px);
   display: block;
   top: auto
 }
 .color-controls {
   display: none;
   flex-wrap: wrap;
   justify-content: space-between;  
 }
 .color-preview {
   border: 0;
   outline: none;
   box-shadow: 0 0 1px 1px rgba(120,120,120,0.33) inset;
   line-height: 1.5;
   font-size: 1rem;
   border-radius: 0.25rem;
   appearance: none;
   width: 100%;
   height: 1.5rem;
   padding: 0.6rem 1rem;
   direction: ltr; /* color value can never be rtl */
 }
 .color-preview.dark {
   color: rgba(255,255,255,0.8);
 }
 .color-preview.dark::placeholder {
   color: rgba(255,255,255,0.6);
 }
 .color-preview.light {
   color: rgba(0,0,0,0.8);
 }
 .color-preview.light::placeholder {
   color: rgba(0,0,0,0.6);
 }
 .menu-toggle {
   position: absolute;
   height: 100%; width: 3rem;
   top: 0; right: 0;
   background: none;
   display: flex;
   border: 0;
   outline: none;
   border-radius: 0 .25rem .25rem 0;
   transition: all 0.33s ease;
   cursor: pointer
 }
 .color-preview.light + .menu-toggle {
   background: rgba(0,0,0,0.5);
 }
 .color-preview.dark + .menu-toggle {
   background: rgba(255,255,255,0.33);
 }
 .menu-toggle svg {
   width: auto;
   height: 100%
 }
 .color-menu {
   list-style: none;
   padding-inline: 0;
   margin: 0;
   flex-wrap: wrap;
   flex-flow: column;
   display: none;
   max-height: 160px;
   overflow-y: auto
 }
 .color-menu::-webkit-scrollbar {
   width: 10px;
 }
 .color-menu::-webkit-scrollbar-track {
   background-color: transparent;
 }
 .color-menu::-webkit-scrollbar-thumb {
   background-color: transparent;
   border-radius: 10px;
   border: 0;
   background-clip: content-box;
 }
 .color-menu:hover::-webkit-scrollbar-thumb {
   background-color: rgba(255,255,255,0.2);
 }
 .color-menu::-webkit-scrollbar-thumb:hover {
   background-color: #fff;
 }
 .color-dropdown.menu .color-menu,
 .color-dropdown.picker .color-controls {
   display: flex
 }
 li {
   padding: 0.25rem 0.5rem;
   cursor: pointer
 }
 li:hover {
   background: #fff;
   color: #000
 }
 .color-form {
   font: 12px Arial;
   display: flex;
   flex-wrap: wrap;
   flex-direction: inherit;
   width: 100%;
   align-items: center;
   padding: 0.25rem 0
 }
 .color-form > * {
   flex: 1 0 0%;
   max-width: 17.5%;
   width: 17.5%
 }
 .color-form label {
   text-align: center;
   max-width: 7.5%;
   width: 7.5%
 }
 label.hex-label {
   max-width: 12.5%;
   width: 12.5%
 }
 input.color-input-hex {
   max-width: 87.5%;
   width: 87.5%
 }
 .color-input {
   background: transparent;
   border: 1px solid rgba(255,255,255,0.15);
   text-align: right;
   outline: none;
   color: inherit
 }
 .color-input:active,
 .color-input:focus {
   background: rgba(0,0,0,0.25);
   border: 1px solid rgba(255,255,255,0.33);
 }
 .color-control1 {
   cursor: crosshair;
 }
 .color-control2,
 .color-control3 {
   cursor: ns-resize;
 }
 .color-control {
   position:relative;
   display: inline-block
 }
 .color-control:focus canvas:active {
   cursor: none;
 }
 .color-pointer,
 .color-slider {
   position:absolute;
   background: #000;
   border: 1px solid #fff;
   height: 5px;
   cursor: inherit;
   user-select: none;
   pointer-events: none
 }
 .color-pointer {
   width: 5px;
   border-radius: 5px
 }
 .color-slider {
   left: 0;
   width: calc(100% - 2px);
 }
 .visually-hidden { display: none }
 :host([dir="rtl"]) .color-preview { text-align: right }
 :host([dir="rtl"]) .menu-toggle {
   right: auto;
   left: 0
 }
 :host([dir="rtl"]) .menu-toggle {
   border-radius: .25rem 0 0 .25rem;
 }

The tools will do the rest.

Sweet. Thanks @dgrammatiko I'm going to update my local repo, I have some accessibility updates for the color-picker.

Congrats on a well done job.

@dgrammatiko is there a --fix option for CSS lint?

try stylelint --config build/.stylelintrc.json -s scss "build/media_source/**/*.scss" --fix (although I have no clue if stylelint supports it)

Thanks man, check back in a couple minutes.

@dgrammatiko for some reason the js is loaded, looks good, but it doesn't work.

Ah it's a module, forgot to change that.

The joomla.asset.json should look like:

  {
       "name": "field.color-picker-es5",
       "type": "script",
       "uri": "system/fields/joomla-field-color-picker-es5.min.js",
       "attributes": {
         "nomodule": true,
         "defer": true
       },
       "dependencies": [
         "wcpolyfill"
       ]
     },
  {
       "name": "field.color-picker",
       "type": "script",
       "uri": "system/fields/joomla-field-color-picker.min.js",
       "attributes": {
         "type": "module"
       },
       "dependencies": [
         "field.color-picker-es5"
       ]
     },

Check some other field

@dgrammatiko now that we're "done" would you care to provide some feedback on how it actually works as implemented as well as for the documentation draft I posted.

I'm interested to know your take on how the dropdown is resizing to full width, IMO, it's great to have all the accuracy possible, but on wide screens with one column options page it looks a bit silly.

@Fedik this thing is ready for you.

Which color-picker is this? Built in TinyMCE?

@richard67 sorry to bother, we have a conflict here which I'm not sure I can 100% manage.

Also guys, is there any chance we can get this to next J4.0 beta release please?

Also guys, is there any chance we can get this to next J4.0 beta release please?

I don't think this will make it into 4.0, but finally it is not my decision

@richard67 sorry to bother, we have a conflict here which I'm not sure I can 100% manage.

Too much even for me now. @dgrammatiko can you advise what he shall do with his package-lock.json?

Also guys, is there any chance we can get this to next J4.0 beta release please?

@rdeutz Is this here a new feature so it has to be moved to 4.1?

@rdeutz this isn't a new feature per say, it's a replacement for minicolors, with a couple of usability and accessibility improvements.

@thednp probably this is a naive way of solving the conflict but try copying the contents of package-lock.json from the 4.0-dev repo into your local file, then run npm install so the file gets the updates for the resources you added. Then push that and hopefully, everything will be in-sync again. btw this is not the proper way to deal with conflicts...

Conflict solved. Guys what do we need to get this through?

@thednp Why are you asking if you know the answer? A PR needs at least 2 successful tests before it can be RTC.

@richard67 because nobody is testing, providing any feedback, like people think this is WIP/draft or are undecided if we push it to 4.0 or 4.1. Maybe people think this needs more polish. I don't know anything.

This PR not going to dev, I always have to solve these nasty conflicts over and over.

please fix code style here with the indentions

Copyright and license

I note that there is neither of these in the main js file. The only thing is a reference to two codepens both of which are MIT licenced

This is a really unusual UI - not sure its intuitive at all

From an accessibility perspective this is worse than the field it is replacing.

The screenreader does not announce the field label.
The screenreader does not announce the (crazyUI) dropdown menu

All you hear is the "#f66e55# which is meaningless

This is invalid markup. You are creating a list but you have no list items

What are inputlabels and inputlabel? I dont recognise these attributes or see where they are used

ah - i see what they are for now. unfortunately they do not work. As you can see they are not exposed to the accessibility tree so a screenreader will never announce them

All the above comments were for the advance (default) layout

Testing the simple layout now.
Thankfully this is fairly accessible.

But do you really think that it is obvious what to do here

Brian the simple layout was done by me and you some years ago, it’s not part of this pr?

@dgrammatiko yes I was just about to type that this was not part of this PR - wasnt obvious until I dug into the code. The example documentation gave e the wrong impression. PS where did we define which colours were used in that

There should be an attribute in the xml and should be on the docs (we just rewrote the code to be a11y)

I will dig into that tomorrow and create a new issue so as not to pollute this one. There are enough issues with this advanced picker

Finally! Thanks.

@brianteeman inputLabel was used in a previous version for the visible input inside the ShadowRoot, I will bring it back. Should I add ARIA to elements of the Shadowroot items?

There should be an attribute in the xml and should be on the docs (we just rewrote the code to be a11y)

@dgrammatiko to which attribute you are referring to?

I will update the code base and make all adjustments today.

It s named colors

Which is something we discussed not to include in the advanced layout.

Brian, I have no idea why the screen readers won't read the visually-hidden labels, I'm thinking its because we're not using delegatesFocus, (which is not supported on Safari).

<label for="rgb_color_red">R: <span class="visually-hidden">RGB colour format - Red component</span></label>
<input id="rgb_color_red" name="rgb_color_red" value="0" type="number" placeholder="[0-255]" min="0" max="255">

I have to admit accessibility isn't my sharpest blade, I'm open to your accessibility team suggestions. I'm investigating all other options meanwhile.

I am not on the accessibility team.

There are lots of articles online about the issues with accessibility and the shadow dom

Yes, it seems our component will require additional Language strings.

It needs a lot of work

Eh I was using the incorrect visually-hidden style. Now the screen reader will read everything.

I only have to handle the placeholders and other non-form elements.

Listening to the screen reader trying to pronounce hsla or rgba is hilarious. I'm going to feed it a custom aria-label for almost every visible element of the color picker. According to my research on a general WAI-ARIA guideline, it will go like this:

• The <joomla-field-color-picker> element will use aria-labelledby -> the field label and aria-describedby -> the field description
• The visible input will use a special set of aria attributes inspired by Radial Color Picker as well as aria-expanded
• While for controls like Alpha or (HSL) - Saturation we could normally use an <input type="slider">, we don't have anything for the first control, where we would need a 2D slider which doesn't exist yet. So the canvas elements will have an aria-label each, as follows: Lightness and Saturation Control, Hue Control for HEX + Alpha Control for RGB(a) OR Hue and Lightness Control, Saturation Control and Alpha Control for HSL(a) format, good enough to understand that they serve as a graphical representation of the colour's properties (hue, lightness, etc) .
• the button toggling the $keywords menu will have an aria-labelledby -> span.id -> Colour presets and aria-expanded -> true/false
• the $keywords menu itself will be separate, will no longer share same wrapper with the color picker and will use its own set of aria attributes.
• As for the other inputs of the color picker, the aria-hidden and the fixed visually-hidden will do the job.

Click LIKE if you agree.

Alright Brian, what is your objection?

Listening to the screen reader trying to pronounce hsla or rgba is hilarious.

That is not for a non-screen reader user to decide. Every screen reader is different.

I'm going to feed it a custom aria-label for almost every visible element of the color picker. According to my research on a general WAI-ARIA guideline, it will go like this:

The first rule of Aria is not to use Aria.

• The <joomla-field-color-picker> element will use aria-labelledby -> the field label and aria-describedby -> the field description

There is no field description currently so there is no need for the aria-describedby

• The visible input will use a special set of aria attributes inspired by Radial Color Picker as well as aria-expanded

That might appear to be good but as it announces the same colour name for a wide range of colours it is not helpful at all. For example you would never be able to be sure you have the correct green

• While for controls like Alpha or (HSL) - Saturation we could normally use an <input type="slider">, we don't have anything for the first control, where we would need a 2D slider which doesn't exist yet. So the canvas elements will have an aria-label each, as follows: Lightness and Saturation Control, Hue Control for HEX + Alpha Control for RGB(a) OR Hue and Lightness Control, Saturation Control and Alpha Control for HSL(a) format, good enough to understand that they serve as a graphical representation of the colour's properties (hue, lightness, etc) .
• the button toggling the $keywords menu will have an aria-labelledby -> span.id -> Colour presets and aria-expanded -> true/false
• the $keywords menu itself will be separate, will no longer share same wrapper with the color picker and will use its own set of aria attributes.
• As for the other inputs of the color picker, the aria-hidden and the fixed visually-hidden will do the job.

fixed??

Click LIKE if you agree.

Brian, don't worry about it. The final version will be 100% accessibility valid. Now back to work.

So why waste my time asking for an opinion ?

Your feedback provides clarity and confirmation for my development plan and I thank you.

@dgrammatiko quick question: can I send the color-picker attribute values with JSON data for strings? Or via JavaScript options?

My current comma separated strings just won't do.

I don't really understand the question but in general custom elements get their inputs from attributes and in general attributes are strings. You could expect JSON but there need to be checks and fallbacks

For instance, currently we have

$inputLabels = Text::_('JFIELD_COLOR_ADVANCED_FORMAT_HSL_HUE_INPUT_LABEL');
$inputLabels .= ',' . Text::_('JFIELD_COLOR_ADVANCED_FORMAT_HSL_SATURATION_INPUT_LABEL');
$inputLabels .= ',' . Text::_('JFIELD_COLOR_ADVANCED_FORMAT_HSL_LIGHTNESS_INPUT_LABEL');
$inputLabels .= ',' . Text::_('JFIELD_COLOR_ADVANCED_ALPHA_INPUT_LABEL');

I want to make an array and add it to the attributes list as json_decode($that_array).

Or more like $this->escape(json_decode($that_array)).

Is this allowed?

Is this allowed?

Technically yes but it's a really bad implementation, use individual attributes and have a setter/getter

btw I just checked your template inside the web component and realised that the label of the color field is not in there. That will never work, either include the label in the webomponent (shadow root) or use a custom element (no shadow root)

In my local WIP version I already took care of that since Brian exploded with feedback.

Bonus note: I'm adding the functionality of role="slider" to the color-picker controls and I added some more language tags.

I'm using the default Windows 10 screen reader, which seems to work really well with labels and ARIA attributes, the Chromium extensions suck real bad, I want to know how is the Windows 10 screen reader compared to that from MAC OS.

In my local WIP version I already took care of that since Brian exploded with feedback.

The expected behaviour of a label is: on click it should focus the input element. Since joomla-color is not a field (according to form children) this is broken and unfixable unless if the label is part of shadow root or the custom element doesn't have shadow dom so the linking between label and input is not broken

That behavior is already "handled" if you check the current version online (equivalent with the one in my fork repo) https://codepen.io/thednp/pen/yLVzZzW you will have exactly that.

However I'm considering options: to hide the Joomla form field label, via hideLabel="true" and add its most important attributes into a label close to the color-preview input, which is not 100% Joomla, but it's a more consistent behavior that doesn't have to be handled manually like we do it now with JS.

The following is a sample markup of the new color-picker version

<joomla-field-color-picker name="jform[params][advanced-color-rgb]" id="jform_params_advanced_color_rgb" value="rgb(49, 49, 173)" class="required dark open" format="rgb" required="" autocomplete="off" alphalabel="Alpha" hexlabel="Hexadecimal" redlabel="Red" greenlabel="Green" bluelabel="Blue" huelabel="Hue" saturationlabel="Saturation" lightnesslabel="Lightness" formatlabel="RGB format" redinputlabel="Set Red level" greeninputlabel="Set Green level" blueinputlabel="Set Blue level" control1label="The Saturation and the Lightness of the current colour." control2label="The Hue of the current colour." alphainputlabel="Set Alpha level" control3label="The alpha transparency of the current colour." togglelabel="Colour presets" menulabel="Choose colour preset:" inputlabel="Set a colour by typing a value or by using the color picker" dialoglabel="Color Picker" keywords="navy,lime,crimson,chocolate" spellcheck="1" tabindex="0" role="button" aria-expanded="true" aria-haspopup="true" aria-labelledby="jform_params_advanced_color_rgb-lbl">

<SHADOWROOT>
<label for="color-input" class="visually-hidden">Set a colour by typing a value or by using the color picker</label>
<input id="color-input" name="color-input" type="text" class="color-preview" autocomplete="off" spellcheck="false" required="true" style="background-color: rgb(49, 49, 173);">
<div class="color-dropdown picker show" role="dialog" aria-labelledby="dialog-label format-label">
  <label id="dialog-label" class="visually-hidden">Color Picker</label>
  <span id="format-label" class="visually-hidden">RGB format</span>
  <div class="color-controls">
    <div class="color-control">
  <canvas class="color-control1" height="230" width="373" role="presentation" aria-label="The Saturation and the Lightness of the current colour." tabindex="-1"></canvas>
  <label id="control1-lbl" class="visually-hidden">Red Green &amp; Blue</label>
  <div class="color-pointer" role="slider" aria-labelledby="control1-lbl" tabindex="0" aria-live="polite" aria-valuetext="Red 49, Green 49 &amp;amp; Blue 173" style="transform: translate3d(264.353px, 70.9608px, 0px);"></div>
</div>
<div class="color-control">
  <canvas class="color-control2" height="230" width="21" role="presentation" aria-label="The Hue of the current colour." tabindex="-1"></canvas>
  <label id="control2-lbl" class="visually-hidden">Hue</label>
  <div class="color-slider" role="slider" aria-labelledby="control2-lbl" tabindex="0" aria-live="polite" aria-valuetext="240°" style="transform: translate3d(0px, 150.333px, 0px);"></div>
</div>
<div class="color-control">
  <canvas class="color-control3" height="230" width="21" role="presentation" aria-label="The alpha transparency of the current colour." tabindex="-1"></canvas>
  <label id="control3-lbl" class="visually-hidden">Alpha</label>
  <div class="color-slider" role="slider" aria-labelledby="control3-lbl" tabindex="0" aria-live="polite" aria-valuetext="100%" style="transform: translate3d(0px, -3px, 0px);"></div>
</div>
  </div>
  <div class="color-form">
    <label for="rgb_color_red"><span aria-hidden="true">R:</span><span class="visually-hidden">Set Red level</span></label>
<input id="rgb_color_red" name="rgb_color_red" value="0" class="color-input" type="number" min="0" max="255" autocomplete="off" spellcheck="false">

<label for="rgb_color_green"><span aria-hidden="true">G:</span><span class="visually-hidden">Set Green level</span></label>
<input id="rgb_color_green" name="rgb_color_green" value="0" class="color-input" type="number" min="0" max="255" autocomplete="off" spellcheck="false">

<label for="rgb_color_blue"><span aria-hidden="true">B:</span><span class="visually-hidden">Set Blue level</span></label>
<input id="rgb_color_blue" name="rgb_color_blue" value="0" class="color-input" type="number" min="0" max="255" autocomplete="off" spellcheck="false">

<label for="rgb_color_alpha"><span aria-hidden="true">A:</span><span class="visually-hidden">Set Alpha level</span></label>
<input id="rgb_color_alpha" name="rgb_color_alpha" value="1" class="color-input" type="number" min="0" max="1" step="0.01" autocomplete="off" spellcheck="false">
  </div>
</div>

<button id="presets-btn" class="menu-toggle" aria-labelledby="presets-btn-label" aria-expanded="false" aria-haspopup="true">
  <span id="presets-btn-label" class="visually-hidden">Colour presets</span>
</button>
<div class="color-dropdown menu">
  <span id="presets-label" class="visually-hidden">Choose colour preset:</span>
  <ul aria-labelledby="presets-label" class="color-menu" role="listbox">
    <li role="option" tabindex="0" value="navy">navy</li>
    <li role="option" tabindex="0" value="lime">lime</li>
  </ul>
</div>
</SHADOWROOT>
	<input type="hidden">
</joomla-field-color-picker>

Will commit changes tomorrow, feel free to comment.

Will commit changes tomorrow, feel free to comment.

Can't comment until you do ;)

There you go. Have fun :)

Still not accessible to keyboard users using a screen reader. For example a button must be able to be activated using both the space bar and the enter key. So you can't even find out what the already selected colour is

I have tested this item ? unsuccessfully on 0e7cc53

Is that the only problem? It's an easy fix I will handle asap.

I doubt it is an easy fix but good luck

That was so easy fix, I took some time for polish. I've done everything I ever wanted for a color picker.

I need to update the testing methodology.

Using a keyboard how are you expected to select an item in the dropdown menu

Sorry but this is full of accessibility errors. I'm afraid I just dont have the time or patience to test this any further. Perhaps @chmst will be able to help.

Turn on a screen reader and listen as you tab around both this picker and the previous one in the admin template style page

For example the previous one will will immediately announce "Dark Text and then the color"
This one only announces "Dark Text, menu item, collapsed"

for a keyboard user its also about 8 key presses to move to the next field

Brian, these things are little fixes, far from "full of accessibility problems". This form field layout uses shadowRoot. for which every property and functionality has to be coded to behave like a form field.

My most concern is the fact that until the script satisfies all accessibility, which it will, in a matter of minutes thanks to your feedback, I will have to deal with the conflicting package-lock.json again, over and over. I don't afford that time.

This form field layout uses shadowRoot. for which every property and functionality has to be coded to behave like a form field.

Just one of the many reasons that this approach is non sustainable (if you ever test it before asking others to)

My most concern is the fact that until the script satisfies all accessibility, which it will, in a matter of minutes thanks to your feedback, I will have to deal with the conflicting package-lock.json again, over and over. I don't afford that time.

Retested. Issues reported are not resolved.

Sorry Brian, I haven't completed the requests you made yet, the above commits were about solving the package-lock.json conflict. I wasted a lot of time with it, I will leave those for someone else to solve.

I will let you know when I'm done, thanks for sticking to it.

Brian, some notes:

• you can now navigate between fields freely without getting inside the shadowRoot elements, but if you open the colorPicker, you will go there first;
• the field label now has a human understandable label, the screen readers will read exactly what is what, all translatable.
• We need someone to fix the package-lock.json file according to my version of the package.json which was updated this morning; perhaps @richard67 can lay a hand here I hope.

Brian, please check the above, and also: should I attempt to fix the package-lock.json again? There seem to be some more changes.

Later edit: I've updated the testing instructions.

@thednp Your PR deletes the packages lock, and that's definitely not the right way:

Please revert that deletion before you try to solve it.

Should I add a 4.0-dev version there?

revert the deletions by using revert this commit

Cannot do that, will attempt to add mine again.

Brian, build ready to test.

@richard67 thanks for the assist.

@thednp These should be alphabetically sorted:

https://github.com/joomla/joomla-cms/pull/32510/files#diff-db7eb77540ff419bd7e6557d2779f4cf1e31158c20cb4b63dbbe8d6c426385adR5051-R5055

I.e. wrong sorted

			// Joomla 4.0 Beta 8
			'/administrator/templates/atum/scss/vendor/minicolors/minicolors.scss',
			'/templates/cassiopeia/scss/vendor/_minicolors.scss',
			'/administrator/components/com_admin/postinstall/htaccess.php',
			'/administrator/components/com_admin/postinstall/updatedefaultsettings.php',

should be changed to

			// Joomla 4.0 Beta 8
			'/administrator/components/com_admin/postinstall/htaccess.php',
			'/administrator/components/com_admin/postinstall/updatedefaultsettings.php',
			'/administrator/templates/atum/scss/vendor/minicolors/minicolors.scss',
			'/templates/cassiopeia/scss/vendor/_minicolors.scss',

Beside this, please don't ask me for a review if it's related to javascript.

Brian, build ready to test.

It is now not possible to access the color picker using the keyboard. Please test your changes before asking others to test

https://github.com/joomla/joomla-cms/pull/32510/files#r598165347

You have marked this as resolved but you have not corrected it

Brian, this is a test with #32510 using the keyboard navigation.

• Google Chrome Canary latest
• Windows 10 latest

Can somebody else please confirm this test. @dgrammatiko ?

This is using the keyboard to change control sliders:

You testing with Safari on MAC? It doesn't support event.which I will correct that.

Brian, I don't have a MAC or a Safari browser, but I'm sure this build works.

I've updated the testing methodology.

I am testing on chrome with windows.

I can see now what the problem is but I'm afraid I have no idea what the fix is. It is almost certainly related to javascript emulating keys instead of using native behaviour.

When you navigate to the input field with your keyboard and press the enter key then the options open - exactly as you showed in your recording.

However when I have a screen reader enabled and I navigate to the same input then no keypress will open the options. I have tested this with both Navigator (built in to windows 10) and NVDA which is probably the most common screen reader for windows users (free and open source from https://www.nvaccess.org/)

My observations with keyboard navigation and NVDA:

• If you press ALT+SPACE or ALT+ENTER on the <joomla-filed-color-picker> while the NVDA screen reader is active, the dropdown will show up. Then you can Tab inside the dropdown.
• You can press ALT+UP / ALT + DOWN (arrows) to change color knobs but it will focus on the previous or next HTML node for some reason.

Thats because you are not changing the mode of the screenreader https://tink.uk/understanding-screen-reader-interaction-modes/

If it's a JavaScript issue, I'm gonna nail it down. If it's a NVDA + customElements issue, we gonna have to find some workaround.

I'm going to do some research maybe I can come up with something.

The answer/explanation was in the post I linked to

I've tested other form fields and came to the realization that most of them are an accessibility disaster unfortunately.

• the fancy select layout, radio buttons, checkboxes, the simple and slider controls of the Color field, probably others too, they don't expose to NVDA any field name, you're presented with "Yes, one of two, selected", no context, no aria, no idea what's what and what is for.
• only fields using native <input type="text"> and <select> are working properly as far as I tested.
• everything has to be reworked from an accessibility point of view, all fields need to check to have correct <label for="field_name"> <-> <input type="radio"> association.

In my little project here, I have some options:

• Since the color-dropdown is already role="application" I can just inform the keyboard user to use ALT key to change knobs or ALT + SPACE to open color picker, makes total sense to a user listening to NVDA instructions because it's an application and properly announced so. This is probably not the best solution, but it would make sense on an ever evolving web. Other examples are similar, in the sense that operating knobs require using the ALT key, but not include shadowRoot shenanigans.
• I can just replace all interactive elements with <button> or <input type="range">, <a>, it doesn't matter if it's inside the shadowRoot or not, they always work natively with keyboard events.
• I can have the <joomla-field-color-picker> element store all values, instance object, event handling & delegation, but only work with a markup outside shadowroot (something that would simplify the styling, a lot of the code base and @dgrammatiko would not approve of this), the focus is that we need to easily multiply the instance for repeatable fields more or less.

I would go for the second option, but time is ticking, I need to know what's your take on it before I go any further.

I can have the element store all values, instance object, event handling & delegation, but only work with a markup outside shadowroot (something that would simplify the styling, a lot of the code base and @dgrammatiko would not approve of this), the focus is that we need to easily multiply the instance for repeatable fields more or less.

Didn't I just propose you to do exactly that but then you went your own way and doing this weird dropdown?

Probably you did and I didn't understand, you wanted to have the form.onsubmit handler for a hiddenInput that I forgot about later on, something that won't make sense with markup outside the shadowroot.

No matter what, I'm going to make it work, I'm still experimenting to find the best there is to improve accessibility.

Brian, this is a demo with keyboard navigation and screen reader turned ON.

• the <color-picker> element is no longer a button, there is a native <button> to toggle the color picker visibility;
• as of now, screen readers and keyboard navigation do not 100% support control for elements with these attributes <div role="slider" aria-min="0" aria-max="360" aria-valuetext="360 degrees"> except if you interact with the ALT key, but even then, the narator focus will jump all over the place, so I've disabled the tabindex attribute for those elements and the associated keyboard events listeners, however they are still controllable via mouse; this behavior is the same regardless if the elements are inside shadowRoot or not.

I will prepare the files and commit as soon as I can.

so I've disabled the tabindex attribute for those elements and the associated keyboard events listeners

From my perspective thats a fail

Please explain. Because it doesn't work with the screen readers or why?

From my research: it's not recommended to detect screen readers or to code around them, also some features are simply not supported.

You think I should revert that change? It's easy to put back.

EDIT: I put it back, will commit shortly.

From my research: it's not recommended to detect screen readers or to code around them,

quite correct.

please remember my comments are just that, my own. If anyone else bothers to test this PR they may have other different views

Thanks Brian.

From your point of view do we need anything else for this PR to get RTC?

Some note from my experience working on this, I tried to replace all possible focusable elements with native elements:

• buttons can toggle things, natively, they only need to know what to execute;
• to enable native slider behavior I tried replacing slider knobs with actual sliders but there is no such thing in the current draft to enable double value sliders (vertical + horizontal);
• also about replacing knobs with native sliders, there are multiple concerns against vertical orientation sliders (not standardized across IE, Mozilla, Safari, Chromium), also screen readers won't be able to maintain focus on the thumb;
• not even <input type="number"> can handle the screen reader focus behavior, which is very strange.

don't get me wrong..
but this pr should be postponed to 4.0.x

What was the intention of adding aria-live=offf

As aria-live="off" is the assumed default for elements, it should not be necessary to set this explicitly, unless you're trying to suppress the announcement of elements which have an implicit live region role (such as role="alert").

The idea is that the reader is babbling when you change values, I'm still not 100% sure which methods is best.

I think aria-live="polite" is probably better.

Then you are definitely wrong and it must be polite

Cool, updating as soon as I get to my PC, thanks.

Thanks Brian.

From your point of view do we need anything else for this PR to get RTC?

As with all PR it needs at least two good tests. Personally I will not be marking a negative or positive test as I am not convinced it is an improvement on the current code which amongst other things doesnt need a degree in javascript to understand

Fair enough, I thank you for the assist regardless. From my viewpoint, one less jQuery dependency and SCSS required to include in template.css is awesome enough, this right here is far superior in every way, IMO.

Kind reminder: today I've resolved a quick and easy new package.json conflict.

Please test, RTC and merge somewhere, I cannot allocate any more time into this.

This branch has conflicts that must be resolved

Conflicting files
administrator/components/com_admin/script.php
build/media_source/system/scss/_jquery-minicolors.scss
package-lock.json

I think it should be moved to 4.1.

Yea. Call me when we're at 4.1 RC, I will revise the PR for hopefully last time.

This has been tagged milestone 4.0.1
It should be milestone 4.1

I'm closing this down, preparing a new PR. in the 4.1 branch.