Extend the link-property-form in CKEditor fields to allow link classes

[spackmat]

In sulu/sulu-demo#77 I accidentally opened a subject that I want to present here for discussion.

I have some cases where content editors usually add classes (or types if you want) to inline links inside of their content. Think of things like marking a link with a spoiler- or trigger-warning so that the frontend can catch up that class (or other attribute) of the a element and show whatever the frontend people decide to show to the readers for that. Or the most simple case: Highlight a link generically using a class and the css/js decides how that is implemented.

Basically @alexander-schranz answered on that, that in Sulu the default link class feature of the CKEditor is disabled on purpose for the reason that in Sulu content managers should not have impact on presentation / design of a website. From my point of view, allowing content editors to select one or more of some predefined classes for a link is a semantic decision and not a presentational. I.e. "what I want my link to represent" vs. "what I want my link to look like/behave".

So what I would love is an extension to Sulu's own link-property-form for the CKEditor to allow content editors to select one or more classes of a configurable list of link classes just like the existing selection of the link target. Or more generic a way to extend that helpful link-property-form with custom form elements. (Or that Sulu just doesn't replace CKEditor's own link class feature with its opinionated and thus on purpose not extensible link property UI).

What do others think? Maybe we are the only content editors that use link classes to differentiate between several types of links