Disable the icon transformation by default

Development
#1

Hi devs,

We have for quite a while now an Icon Transformation which job is to transform something that looks like emoticon ASCII syntax into an actual emoticon.

The fact that it’s a transformation always caused some problems, mainly:

  • you cannot really escape it
  • it applies to any content, whatever the source is even some for which it’s really not expected (for example when you explicitly use plain/1.0 to be sure nothing is interpreted…)

@MichaelHamann pointed out that nowadays (with UTF-8 support of emoticons, utf8mb4 in MySQL/MariaDB) this transformation also became very close to useless

So my proposal is disable it by default. If someone requires it, it’s easy to enable it back in xwiki.properties (rendering.transformations property).

WDYT ?

#2

+1.

The icon transformation also doesn’t follow the icon theme and doesn’t work in the WYSIWYG editor, it is therefore disabled, causing unexpected differences between viewing and editing. On the other hand, the WYSIWYG editor already includes an Emoji picker. I therefore assume that most users are already using Emojis.

1 Like
#3

Some thoughts:

  1. Would be interesting to ask our users if they’re using the feature
  2. If we disable it by default, we might as well move it as a contrib extension
  3. Re its application to any markup syntax, that would be very easy to fix
  4. Re the fact that it doesn’t follow the icon theme, that’s also easy to fix (we just haven’t done it, not sure why, maybe because the transformation is in rendering and the icon apis are in platform
  5. I personally find it much simpler to use than emojis (since I use the wiki editor). I use it regularly for (/), (x). If I need to use an emoji, I need to google it and copy paste it.
  6. It provided easy consistency, whereas you’ll find several emojis for the same concept. For example:
    Screenshot 2024-05-03 at 10.36.36
  7. We’ll need to enable it to xwiki.org for sure. And I guess a lot of users will be in this situation since they’ve used it (since it’s enabled by default). See point 1). This is going to cause some support friction probably.
  8. The argument with the WYSIWYG editor is more generic (there are other transformations that exist or that can be written) and that editor would need support for transformations.

Globally, I’m +0 to disable and move to contrib.

Thanks

#4

I guess it should not be too hard to add the emoji picker to the wiki editor bar.

What would be the criteria to decide for which source syntax it’s applied by default ?

#5

That’s easy to fix, we can include an emoji picker in the wiki editor. There is no reason to not have an emoji picker in the toolbar of the wiki editor. I think pretty much all operating systems also include an emoji picker, e.g., on Mac, Windows or Linux with KDE or Ubuntu and GNOME in general.

Regarding the checkbox use case, I think the answer is to either use a task macro (as provided by the Task Manager Application (Pro)) or if we think checkboxes are important enough, to simply include support for checkboxes in a future version of XWiki syntax (similar to how Markdown, e.g., on GitHub, supports checkboxes).

#6

yes ofc (that’s Loading...), but it wouldn’t fully fix it. The main point of the wiki editor is to be able to type text in a flow, without using the mouse or even shortcuts. To give you an example, in 16 years of wiki editing, I have never used the toolbar to use bold, lists, etc. It’s much simpler to just type away when you know the syntax.

#7

Sure and I agree that we should add what’s currently in the icon transformation as syntax in the future but we know it’s not going to happen overnight (we’ve been waiting for the next syntax for about 10 years now).

More generally, that’s the reason why transformations exist: to be able to extend the syntax after the syntax has been finished :slight_smile: There’ll always be thing that is not in the syntax. We also have macros for that but they’re more cumbersome to use for simple use cases such as ticks, smileys, etc.

#8

We could also add quick actions support and other shortcuts to the wiki editor I assume. For example, just type :check and select the checkmark in the completion that pops up (it works this way in the WYSIWYG editor). It’s just that we never put much work in the wiki editor as - I assume - it is hardly used.

#9

By checking the source syntax of the Block to transform. For example it wouldn’t make sense probably to support icon transformation when the content is plain/*. It could be configurable.

BTW one nice thing of the icon transformation over a syntax for ticks in xwiki/2.2 for example, is that we the transformations works for any syntax (right now, you can use icons in any syntax even if that syntax doesn’t have a way to express it). Otherwise that would means extending the syntaxes and that’s often hard or even impossible (if we use a parser than cannot be extended).

#10

That’s not a criteria. I know how to get the source syntax, just not how to decide which one is OK by default (not talking about configuration).

#11

yes that would be nice. I had mentioned this when we added the quick action feature but as you said, improvements to the wiki editor are always put low in priority. The same applies for the [[ completion, it would be so nice to have it in the wiki editor to find the reference of the page you want to link to (Loading...).

#12

What about:

#13

So your proposal is to have a black list system, with plain/* in it by default ?

#14

yes. I haven’t thought if we should add more syntaxes or not to it by default but most likely. For example xdom+xml/* should probably be added.

In any case, I guess this becomes less important/urgent if we disable/remove the icon transformation by default.

#15

I was under the impression that you were proposing ways to avoid disabling it. If we disabled it by default there is a very high chance that we never touch it again, yes.