Hello
I am trying to apply a simple CSS class to a link inserted into the editor.
I have used the custom style menu approach from the docs, which works well in that I can add different header types to insert H1 → H6 and other elements.
I am trying to highlight a link in the TipTap editor that I insert with the toolbar and then use the style dropdown menu approach to then try and apply a CSS class to the <a> tag.
When doing so it applies the CSS class to the parent element in this case a <p> tag as well as the <a> tag.
Video
Configuration
Have I defined the configuration for this incorrectly, or is this a bug or is it intended to work like this?
Hi @warren I think this might be a bit of both according to the docs though the anchor tag isn’t supported as a HTML tag for the style menu. In-comparison if I was to target the span instead it applies the class correctly to the span within the anchor.
It’s odd that it does partially work but annoying that anchor isn’t supported as it’s such a commonly styled element for the RTE.
Perhaps as a workaround you may have to do some sort of custom extension specifically for targeting anchors?
I missed that part of the docs that an <a> tag is not supported.
That is very odd in my opinion that a very common element can not have a class element added to it.
Curious to know how other people are solving this and hoping that I don’t need to write a custom TipTap extension to achieve this.
Hoping some more people see this and have some thoughts on it.
Found the source code for this part with the Styles Dropdown in the CMS.
There is no mention of the <a> tag in it.
The docs mention this:
Due to Tiptap’s strict rich-text schema, only supported HTML tags are allowed in the style select menu, (arbitrary markup will be excluded).
But I would say an <a> is not arbitrary markup IMO. I would be curious to hear from the dev gang at HQ who may be able to give deeper context as to why we are not allowed and what the alternative/solution is to apply a simple class to an anchor is (without it applying to other elements)
As to me in my mind it applying to other elements and not just the <a> is a bug, what do you think @jawood1 ?
Yeah I would agree but this may also just be an issue with how TipTap works as well.
As TipTap uses a schema with nodes and marks a link is classed as a mark but with the umbraco styles implementation it’s also a mark but the rules around TipTap is that marks can’t be nested so it bubbles up and applies it to the parent element.
Just curious: why is this so important? Because it’s really needed, or because we feel that is should work? Or simply because it worked in Umbraco 13 and we want to do the same? I mean this really as an open question, I have no specific opinion (yet ;))
TipTap is a different editor than TinyMCE and more strict. It does some things we are not used to. For instance, it adds p-tags to li-tags. TinyMCE didn’t do this, but from what I gathered, a lot of other editors actually do.
I see a lot of discussions on the forum like: this ‘does not work’ compared to TinyMCE, but isn’t it just different? In other words: do we really need to go through all kinds of hoops to get styling on a tags working because we are used to? Or should we work with what TinyMCE does? Is it bad if the styling is on the container? I mean, stylesheets can be changed to target the container instead of the a itself?
That’s fair. And not to suggest that you’re concerns aren’t valid, but I would offer an alternative:
I personally really REALLY think we should stop adding classes to links. In TinyMCE this would sometimes also cause some weird issues and get HTML message up. It also mattered a lot what you have actually selected to work properly. I really like using inline blocks for things like buttons. It’s very intuitive and it allows for the opening of a modal for setting all kinds of properties on the button.
In the past we’ve used both approaches, but inline blocks is the approach we take now, especially if the button/link markup needs to be a little more complex than just using an <a> tag with some text inside.
It also gives our users some control on how these links are displayed via a toggle or dropdown. For example, if want them in a row or as a list (and need finer control over the spacing between them) and also allows us to control the spacing before and after the link(s) itself, rather than just inheriting the spacing of the <p>.
Endless possibilities with the Inline block approach.
We are facing the same issue while using Tiptap. Earlier, this was working fine with TinyMCE, and we were able to achieve this without any problem. It would be really helpful if this can be fixed or handled in Tiptap as well.
Same problem here when we upgraded from 13 => 17.1. It feels a bit cumbersome to insert a block instead of just adding a class to a link via a custom style dropdown.
It looks like a solution is on its way for v17.2 in case anyone not already aware ^^
The v17 documentation has already been updated to include the a-tag in the supported list. Though as of v17.1 trying to add a class to an a-tag still adds it to both the link element and its parent.
Big thanks to Lee and the testers! Can’t wait to try it out.