I have tested this item ✅ successfully on 01a02ab

Works like a charm.

@infograf768 please add pointer-events: none;, see https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events

@dgrammatiko Why? There isnt anything using pointer events then as far as I can tell

@brianteeman if I m not wrong devs can append links and buttons in that position as well. This is just a fail-safe for any appended link that needs to be disabled but the dev thinks that the reduced opacity also means not working links. In a perfect world that wouldn't be needed but let's be realistic here...

I think you are confusing cursor and pointer

The cursor is all about the visual representation of the cursor, the pointer-events is about removing the click functionality. Probably both are needed but the essential is the pointer-events as it will trully disable the functionality of those btns/links

How are they not disabled now?

So, shall I add:

cursor: not-allowed;
pointer-events: none;

I do not see the need for the pointer-events line - that's disabling something that is already disabled

that's disabling something that is already disabled

It's already disabled for the core but what I'm suggesting will also disable, by default without extra code, 3rd PD buttons/links published in that position. It's about dev ergonomics

It should be the responsibility of the dev to choose if their stuff is enabled or disabled not just because it is in position x

@brianteeman the problem is that if they have a link (and obviously they wanted to tight it to the hiddenMenu) their course of action could be either:

• not echoing the link at all
• add some js to actually disable the link

By having this simple css you make peoples life easier by simply disabling tap/clink on links and buttons. Also, it's not that it gonna make any difference the delivered css in the backend is already around 1/2 a meg, so adding one more line won't make a difference

The problem is that you are forcing it to be disabled - it should be the developers choice. They might have a very good reason for it to be enabled

The problem is that you are forcing it to be disabled

You're missing the point mate. This behaviour is coupled to a class disabled. Now tell me that the disabled class should be interpreted as visual-disabled and not as actually disabled... (it doesn't affect the normal links/button in that position header)

I have tested this item ✅ successfully on ead86c5

@brianteeman @dgrammatiko so the proposition as i understand is that if a developer chooses to have their content disabled, by using the disabled class (e.g. here https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/modules/mod_user/tmpl/default.php#L21 ) then in the SCSS block response for disabled here https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/templates/atum/scss/blocks/_header.scss#L109-L115 we'd add pointer-events: none; which would stop any special treatment whilst modules still choose if they want to allow clicks or not by choosing whether they are using the disabled class or not?

If i understand correctly then it makes sense to do it for me?

@wilsonge you got it, that was my proposal

The correct way to disable a button is with the element disabled not the class disabled
A button with a class disabled and pointer-none is not really disabled. It is still has focus. It is still in the accessiblity tree. It will still be announced as a button (with no mention that it is disabled.

For the button what Brian wrote is correct, but the rule also covers plain links and for those pointer-events is required

Links

AFAIK focus cannot be controlled by CSS, so I don't even understand why are we arguing here...

You are saying that you can just disable something with a class. I am proving that you cannot

What you are proving is that the platform doesn't provide any way to do it (only with CSS) in an accessible way. The functionality is disabled but to make it accessible you need to remove the tabindex as well

All of which makes your suggestion pointless

Common sense is not that common, I guess. Have it your way. Unsubscribe

@wilsonge
Please decide if I should modify the PR to any of the proposed suggestions or not.
If not this can be merged.
Imho, if anyone is not happy, another PR can be done later and discussion can be done there.

You don't control what elements (<button> or <a>) are added to the top menu and cannot disable a link with the disabled attribute, so pointer-events: none; should be added just incase a user decides to use <a>

As stated before

1. The creator of the link might want it to be enabled
2. It fails accessibility

@brianteeman in which case at leatst use a:not([target=_blank]) { pointer-events: none; }. If an a user is editing an article and accidentally clicks a link that opens in the same tab, they'll lose their changes

pointer-events none only has an effect on mouse users

Yup, but better than nothing. You'd have to use JS (event.preventDefault()) if you wish to cater for keyboard users

i still say it should be the 3pd problem to solve, there is no issue in core

Modify it please @infograf768

@wilsonge
Done.

Note: when pointer-events: none; is present, then cursor: not-allowed; does not work. Therefore I did not add it.