That is an interesting approach, not exactly what I want. One can also add the format list to a custom config key (which I have working at the moment). The only problem with this is that one is stuck with a single list in ALL RTE instances - removing the ability to customise for different property editors.
Unfortunately, that is not possible on a per-instance basis like you want. The Umbraco interpretation of a CSS document only processes a ver limited set of behaviours. You'd have to examine the core and how it processes the meta information about a style and see if you can extend it to add additional handling.
If you did, I'm certain it would be appreciated as a pr.
As a workaround, you could add classes and then pass the processed IHtmlString through your own parser to remove the class and add the represented attribute. Eg give your class the name attrib-lang:zh-Hans to indicate language attribute and value
I wouldn't mind trying to extend the core to handle a stylesheet correctly. I have a good idea of what it is being transformed into (init config for the tinymce instance), but not where that transformation is taking place.
I'll look into making that pr (how hard can it be?)
I think it would be quite a bit of work. There is kinda the issue of the wide level of flexibility that TinyMCE has with regards to that configuration, but I'm sure it would be a cool PR.
Even a PR to allow for an element and a class, e.g. h1.big would be a starting point.
My understanding is that a class name applied directly to an element (like h1.big) works, but only if it's a block level element. If you try to do a.big it won't work.
That's correct, yes? I was recently poking at this myself.
RTE - adding attributes to elements
What is the correct syntax for adding an attribute to an element in the CSS for the RTE?
I have read: https://our.umbraco.com/documentation/getting-started/backoffice/property-editors/built-in-property-editors/Rich-Text-Editor/RTE-Styles/ but it provides no direction.
This works:
If I use
h4.bluein the css, the RTE dutifully adds<h4 class="blue">as expected.This DOES NOT work
However,
h4[lang="zh-Hans"]causes the format menu to simply not appear.NB:
h4[lang='zh-Hans']andh4[lang=zh-Hans]also do not work.Hi! The only way I've found to do this is by implementing Templates instead of using the Formats dropdown.
I've used this blog post to set up my own implementation of them before: https://www.wiliam.com.au/wiliam-blog/adding-enhanced-styling-to-the-umbraco-tinymce-editor. Hopefully that can help you do what you want? :)
That is an interesting approach, not exactly what I want. One can also add the format list to a custom config key (which I have working at the moment). The only problem with this is that one is stuck with a single list in ALL RTE instances - removing the ability to customise for different property editors.
Hi Ault,
Unfortunately, that is not possible on a per-instance basis like you want. The Umbraco interpretation of a CSS document only processes a ver limited set of behaviours. You'd have to examine the core and how it processes the meta information about a style and see if you can extend it to add additional handling.
If you did, I'm certain it would be appreciated as a pr.
As a workaround, you could add classes and then pass the processed IHtmlString through your own parser to remove the class and add the represented attribute. Eg give your class the name attrib-lang:zh-Hans to indicate language attribute and value
I wouldn't mind trying to extend the core to handle a stylesheet correctly. I have a good idea of what it is being transformed into (init config for the tinymce instance), but not where that transformation is taking place.
I'll look into making that pr (how hard can it be?)
I think it would be quite a bit of work. There is kinda the issue of the wide level of flexibility that TinyMCE has with regards to that configuration, but I'm sure it would be a cool PR.
Even a PR to allow for an element and a class, e.g.
h1.bigwould be a starting point.Nik
Actually,
h1.bigworks exactly as one would expect. There are 2 issues with the process (that I have found):My understanding is that a class name applied directly to an element (like
h1.big) works, but only if it's a block level element. If you try to doa.bigit won't work.That's correct, yes? I was recently poking at this myself.
is working on a reply...