in administrator/language/en-GB/en-GB.com_fields.ini no changes are made. Haven't looked further.

@franz-wohlkoenig i have no idea what you mean

@brianteeman i looked in all files starting from first File if all changes are made after apllying Pull Request.

in File administrator/language/en-GB/en-GB.com_fields.ini the deleted Lines are shown:

no idea what you did wrong as the PR clearly removes those lines

Tried it ones more: Reverted PR, applied PR again > same Result. The File en-GB.com_fields.ini isn't changed.

So hopefully anotherone can test successfully.

@franz-wohlkoenig i have no idea why but patchtester is not pulling all the files. If i check the PR manually with git
$ git fetch origin 4.0-dev pull/19285/head:useless
then it works perfectly

Question: Could there be a case where a 3pd needs to use a description (for example if label is too long to be self-explanatory)?

Anything could be possible.

Anything could be possible.

In that case it looks like it will be impossible because of (example)

-		$elements = $data->xpath($xpath . 'action[@name][@title][@description]');
+		$elements = $data->xpath($xpath . 'action[@name][@title]');

and

 					'title' => (string) $action['title'],
-					'description' => (string) $action['description'],

or do I mistake?

Yes it would be impossible. Just as many things are.

The most complicated ACL settings page I have ever seen is the one for Flexicontent. There must be 50 different permissions and not a single one of those requires anything more than a label to be understood

What we could do to have the option to explain it in more details is to set the Langunge Tag to an empty string, so we get rid of the long message. The downside is that Joomla show then the text of the label twice, but I would say that is not correct and should be changed anyway.

The only situation I can think of that someone will have a longer message is when you allow the client to touch the option but make sure he understand what this option is about

Why remove the option to show a tooltip? Why not just remove the description for core and leave the option to show a tooltip for 3rd parties in case it is needed?

@Bakual this is part of the a11y recommendations

Plus its just really bad conceptually. If you cant describe it in the label then you are doing something fundamentally wrong.

a11y says to not use explanations/description? Doesn't sound right to me.

If you cant describe it in the label then you are doing something fundamentally wrong.

That may be true in most cases. But this generalisated statement certainly isn't true.

Remove the descriptions from core if you think they have no value (which I can agree to), but removing the possibility for 3rd party extension to add descriptions just doesn't make sense to me.

a11y says to not use explanations/description? Doesn't sound right to me.

NO you got it wrong: The DESCRIPTION IS THE LABEL!

So you want to remove all tooltips from all forms? Because the same argument would apply to all form elements, not just permissions.

Honestly, I don't get why you want to remove that feature. It may not be useful for core, but there is no reason to take it away from all. If an extension developer thinks a tooltip is helpful, who are we to tell them they are wrong? That's just arrogant for no reason. There is no gain at all if we remove that feature.

who are we to tell them they are wrong?

Right, we, as joomla cms, agreed that version 4 will be accessible out of the box! This means a lot of misconceptions will have to be fixed once and for good.

Personally I tend to believe that such rules that would be applied to core should, to the extend that’s possible also be forced to 3rd pd code!
This might sound a bit like dictatorship, and in some form it is, but this moves everybody a level up. I see zero point to roll out the core as fully accessible and by the time you install any module/plugin/component you get degradation on accessibility.

If you don't mind getting a non-programmer but daily user of Joomla. Tooltips are great.
There has been several times that I missed those, and I find it awesome when developers take the time to add small explanations through tooltips to their extensions settings page.

You still have to explain to me how a meaningful tooltip degrades accessibility that much that it warrants degrading UX for everyone. I can't imagine that being the case.
If the tooltips itself aren't accessible, fix them. Don't remove them.

And yes, as soon as you install an extension, a11y may be broken. The tooltips likely are the least concern here honestly. We only can do if for core itself.
Also I'm strongly against dictatorship.

I totally agree with @Bakual

RANT:
As I wrote before, the systematic decision to remove some tooltips is a mistake.
Example:

1. The label and tip concerning the URL Language Prefix when editing a Content Language:

The label should remain URL Language Code (and NOT Prefix) since we implemented the feature in 1.6 and the tip explained why precisely as it is NOT a prefix but used as part of a suffix when SEF is off!!!!!

COM_LANGUAGES_FIELD_LANG_CODE_DESC="This Language Code will be appended to the site URL. When SEF is enabled, you will get http://example.com/en/. If SEF is disabled the suffix &amp;lang=en will be appended at the end of the URL. Note <em>the Language Code must be unique among all the languages</em>."

2. In the same UI the tip for the Image field did explain where to change the image and how it is used.

And, please, do not reply that users have to go find this on docs, that is NOT user friendly at all!!!
Adding a ? to click on to display the tips would solve many issues and really make it fully user friendly by letting it know there is one for a specific field.

Adding the ? where needed has already been discussed and will be implemented

On 10 Jan 2018 7:44 a.m., "infograf768" notifications@github.com wrote:

I totally agree with @Bakual https://github.com/bakual

RANT:
As I wrote before, the systematic decision to remove some tooltips is a
mistake.
Example:

1. The label and tip concerning the URL Language Prefix when editing a
   Content Language:

[image: screen shot 2018-01-10 at 08 25 02]
https://user-images.githubusercontent.com/869724/34760599-c9120532-f5e0-11e7-984d-e44873fb0f6d.png

The label should remain URL Language Code (and NOT Prefix) since we
implemented the feature in 1.6 and the tip explained why precisely as it is
NOT a prefix but used as part of a suffix when SEF is off!!!!!

COM_LANGUAGES_FIELD_LANG_CODE_DESC="This Language Code will be appended
to the site URL. When SEF is enabled, you will get http://example.com/en/.
If SEF is disabled the suffix &lang=en will be appended at the end of
the URL. Note the Language Code must be unique among all the
languages."
2. In the same UI the tip for the Image field did explain where to change
the image and how it is used.

[image: screen shot 2018-01-10 at 08 35 36]
https://user-images.githubusercontent.com/869724/34760802-7b0ca062-f5e1-11e7-8abc-65a5d3fb6f2b.png

And, please, do not reply that users have to go find this on docs, that is
NOT user friendly at all!!!
Adding a ? to click on to display the tips would solve many issues and
really make it fully user friendly by letting it know there is one for a
specific field.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#19285 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8VMCgpCSLiwSpjGXytAWaXvYjAEqks5tJGprgaJpZM4RS6Hu
.

Adding the ? where needed has already been discussed and will be implemented

So can we then keep the possibility to add descriptions here? This can be changed to said "?" then as well to meet a11y standards.

The code would be completely different so it might as well be removed here. You can create a new issue as a reminder that the ability to render a ? For tips needs to be added to this view.

The ability to render a ? should be first implemented all over.
Then we can look at less urgent issues like this one as it modifies some libraries which I guess should not be modified this way after it is implemented.
Again, let's not put the cart before the horse...

The code would be completely different

The code to fetch the description would be exactly the same. The only part that changes would be the HTML.
There is no point removing that current code now. It can be changed when the new functionality is introduced. That's how we do this things and J4 should be no different.
I don't understand why you resist that much.

You still have to explain to me how a meaningful tooltip degrades accessibility that much that it warrants degrading UX for everyone.

So I have to explain you that the internet is not about desktop computers anymore and tooltips on hover is a thing of the past

But anyways if people resist so much the needed changes then let's keep bootstrap tooltips revert all the Custom Elements and vanilla JS changes, just convert the old templates to BS4 and release J4 next month!

Let's just stick with Joomla 3 and never move into the 20th century

So I have to explain you that the internet is not about desktop computers anymore and tooltips on hover is a thing of the past

I don't care if it's a "tooltip on hover" or a popup that comes with a click/touch or a small text that is below the label. Of course it doesn't have to be a tooltip if something else works better.
My concern is that this PR removes the ability to add any (optional) description at all to the permission field actions. It makes no sense to remove that ability now.

But anyways if people resist so much the needed changes then let's keep bootstrap tooltips revert all the Custom Elements and vanilla JS changes, just convert the old templates to BS4 and release J4 next month!

Let's just stick with Joomla 3 and never move into the 20th century

You guys both should calm down, don't jump to conclusions and read what is written.

Would help if your ears were open too

It's actually great to see people so invested, that the temperaments get a bit high.

But with all due respect, can someone explain to me how removing this feature is an advantage to the users. As a user, I don't see it, so what exactly am I missing?

Would help if your ears were open too

I try. But hard to do if my question doesn't get an answer and instead I'm getting attacked.
Please explain your reasons to completely remove that (optional) feature and not only the strings for core. Imho, the changes in the XML and INI files are fine. The PHP changes are not.

I have made an executive decision here - I've reverted the part in the Access.php file (between 28ef4b1 and b0dab18 ) which will allow a description to be set still. HOWEVER I have left it out of the form field. As at some point we will move the form field into a layout it means extension developers must make a proactive choice to override the layout to display the description and for 99% of people there will be no description

HOWEVER I have left it out of the form field.

I still don't get what improvement we get here when we completely remove the ability to show descriptions (be it tooltips or whatever) natively.

@wilsonge

If you want to remove tooltips for core ACL, then OK
but please do not force this to 3rd party extensions !

they may have some useful to say in the tooltip for their custom ACL rules !

Please revert the code change at
libraries/src/Form/Field/RulesField.php

and check if there is a non-empty description, and if it is non-empty then add the tooltip

The html in that file will be moved into a JLayout which any 3rd party can override if they want to like our other form fields

But why create a need for an override

the description was removed from the core XMLs
so if the layout checks if description is empty then it can skip the tooltip

the above will not only benefit 3rd party

• but also CORE, because what if you decide to re-add tooltip for an ACL rule ?

then editting the XML file to add description will not be enough

Please test #19356 which will restore that functionality without reverting the intention of this PR here.

@wilsonge Honestly, it's quite stupid if 3rd parties have to override (and maintain) the whole field layout just to be able to add a description. It doesn't hurt anyone if we keep that code line and will make lifes of devs much easier.