Prevent Anki from adding <div>

OK, this is driving me insane.

Can someone please tell me how to prevent Anki from adding div HTML elements all over the place? It happens on both the iPad version and the desktop version (Mac). Then, when I open AnkiDroid on my phone, the edit fields are practically unreadable with the amount of junk fields Anki adds in there.

I realize that it’s probably AnkiDroid’s fields not properly escaping HTML and using plain text fields, but is there a way to make Anki use plain text as well, or rather prevent it from polluting the fields with div’s?

I can’t waste anymore time removing divs. This is ridiculous…

I’d appreciate your suggestions

1 Like

Try updating Anki. In the latest versions, Anki uses <br> instead of <div>, which should be more readable. However, it should also be noted that these <div> are there for a reason: Anki uses HTML for markup, so if you never use tags, you can’t have any markup.

2 Likes

Yes and no, right? You can wrap the field contents in whatever HTML structure you want on the template side, which, if you want cleaner and more consistent formatting in the cards can be a better option. The majority of my fields contain plain text free of any HTML tags; I can confirm this in the editor’s HTML display and by directly querying the collection.anki2 database and examining the flds field in the notes table.

To the OP, I share your frustration. I never ever ever ever want someone else’s HTML in my fields. And this is the origin of the <div> tags you are complaining about. The only way that I’ve been able to ensure that is to never paste formatted text into an Anki editor field. This is not easy. There is an Anki preference to paste only plain text without markup. It works +/- the last time I tried it.

Instead, I wrote a small shell script that runs inside a Keyboard Maestro macro. It essentially acts like a “Paste as plain text” command.

#!/bin/bash
#
# Convert contents of clipboard to plain text.
# and return to clipboard

pbpaste | textutil -convert txt -stdin -stdout -encoding 4 | pbcopy

exit 0

The next step in the macro is just a ⌘V to paste the modified text into Anki field. The entire macro is triggered with ⌃W. Using this setup, I have consistently markup-free contents in my fields. Then if I want formatting, I apply it in the template. Problem solved. I’ve written it up here but it’s basically what I’ve described here except for a description of what textutil is doing.

But, this solution is macOS-only due to the use of cli tools that are only on macOS. I’ve no doubt there are similar approaches one could take on another platform.

I’ll try downloading the new versions now and see how it goes.

Regarding your markup comment - thats not true. You can have a plain text editor where you can add HTML elements voluntarily (with shorthand buttons for common elements), in addition to a visual editor (e. G. similar to how WordPress does it), then work with the editor you prefer.

And for what it’s worth, I can’t remember a single instance where I used markup on any of my cards, and I’ve been using Anki for almost a year now on a daily basis. I use plain text virtually 100% of the time. I’m sure people use it, but I also know that the simplest use case isn’t adequately solved… Which is incredibly annoying =/

What I meant is: without HTML tags, you can’t have markup. You may well put it in the templates, but that will only provide generic markup (ie. nothing specific to one note). If you want to have, say, a bold text, no matter which editor you use, Anki has to insert a <b> tag somewhere. Then, if you use the HTML editor, you will see these tags. If you don’t want to see them, just use the regular editor.

I think the issue for the developers is that there are two camps of users:

  1. Users who want clean plain text and prefer to handle formatting on the template side only. Or in the rare case want to have plain text that they markup in the field editor. This group includes me and apparently @rafael777
  2. Users who want to grab formatted text from the web or other rich text source and have it appear as-is on their cards. This seems like the larger group.

So it’s a balancing act. The ⇧+paste functionality may work well for you, @rafael777 . The solution I presented above works 100% but is macOS only and requires a 3rd party app to trigger it. It was presented only as a concept for how to bypass Anki’s behaviour.

For kicks, here’s a comparison of three ways of getting content into a field. In each case, I copied the same rich text from ru.wiktionary.org:

Simple ⌘V paste:

HTML completely ported from the page.


⇧ ⌘V paste:

Strips most of the markup except for the pesky &nbsp;.


My solution described above:

Plain text with no residual markup.

1 Like

Bumping this, as this is still hella frustrating…I did however notice that indeed in the desktop version, the divs are replaced with "br"s. Unfortunately that’s not the case with the iPad version, which is what I use most of the time (alongside the android version, which doesn’t have this issue). Any idea when this will be fixed on iOS/iPad as well?

I have no clue :joy: maybe @dae has planned it?

The plan is to port the desktop editor over to AnkiMobile, but some of Henrik’s recent editor PRs need to be merged first before that will become feasible, and they’re currently held up while bugs in other areas are addressed.

1 Like

Correct. And I use bold for a single character within a word, so the field cannot be plain text and for me MUST support HTML markup.

(The use case is to show the stressed syllable within the word - using bold for that works well for me)

Bumping this again, as it’s still driving me nuts six months later. Any idea when the iOS version will receive this fix guys? It’s incredibly frustrating to have spent $30 on an app that I can’t even use without completely polluting my flashcards with <divs> that ruin the UX.

I’m afraid it will likely be some time yet - the PRs I mentioned above still haven’t been merged, and Henrik is no longer able to dedicate the time he was able to in the past, so I will need to take over this work, and I’m stretched quite thin, with my attention also being needed for the desktop, AnkiWeb and sometimes AnkiDroid components as well. Porting the editor changes to AnkiMobile is a fair amount of work, and not something I’ll be able to do in the next release - for now my priority is getting a new release out with the latest desktop changes like the scheduler updates, and addressing some other issues that are lower-hanging. Sorry it’s dragged out, and thank you for your patience.