TYPO3 Core

Just to be clear: the RTE linkbrowser works fine ok. I'm talking about the non-RTE-linkbrowser.

IMO a field like tt_content.header_link is providing "typolink" functionality which does include the class attribute as its 3rd (?) parameter. Thus, I think, the linkbrowser should offer a pre-configured list of classes instead of allowing the BE users to just enter whatever they want.

I also think that all link browsers, whether TCA field or RTE, should work / look the same and be configurable...
It would be great if the NOT RTE link browser could get its own config.yaml in which you could configure your own CSS classes (just like the RTE link browser).

I wonder why there are 2 different ones anyway... Both actually do the same thing, why are there 2 different implementations here?

@Georg Ringer
For example, if you want to style links, then it is nicer for the editor if he can do everything at once - in one window (setting the link and its attributes).
If this is solved via the RTE style field, the editor must first set the link in the link browser and then select the correct class again in the RTE via the style select field. <- I find this a bit cumbersome.

Some technical background:

The "RTE modal popup" is implemented via typo3/sysext/rte_ckeditor/Classes/Controller/BrowseLinksController.php - and the "TCA modal popup" is done via typo3/sysext/backend/Classes/Controller/LinkBrowserController.php (Note how the naming has some, let's say, discrepancy).

Both PHP classes inherit from typo3/sysext/backend/Classes/Controller/AbstractLinkBrowserController.php

That abstract base class doesn't know much about implementation details for dropdowns. The RTE extension of the abstract class does a lot of (quite hard to read) YAML config loading to offer dropdowns. The TCA extension however is much more readable and "simple".

A lot of BrowseLinksController could be transplanted to LinkBrowserController, and be adapted to TCA config instead of YAML config. The appropriate TCA keys would all need to be implemented, and the ones in the YAML config are already quite deeply nested and hard to read.

Probably that would need some more unification so that everything is put into the Abstract Class then, but just be fed by differend config providers. This again would make the abstract class then bloated.

So.... who's willing to take a stab at this? :D