<div class="kanji"><br>{{Vocab}}<br><br></div>
<div id="typeans" class="radical-name">{{type:Reading}}</div>
<script src="https://unpkg.com/wanakana@5.3.1/wanakana.min.js"></script>
<script>
document.addEventListener("DOMContentLoaded", function () {
var input = document.getElementById('typeans'); // Input field for typing
if (input) {
wanakana.bind(input); // Enables real-time romaji-to-katakana conversion
input.addEventListener("input", function () {
input.value = wanakana.toKatakana(input.value); // Ensures that typing is converted to Katakana in real time
});
}
});
</script>
If the objective in the card is to type in the hiragana you have in the field Reading field, was there some reason that installing a Japanese keyboard on each device you review on is not an option?
Otherwise, try adding back the original {{type:Reading}} into the card front and then inspect with the Webview inspector. You’ll be able to find out exactly what class or id the <input> element generated by Anki has so you can then query it correctly like in your current working example.
First of all, thank you for your input, which provided needed direction for solving the issue.
The reason I don’t want to install Japanese IME is that I already have 2 different IMEs installed which I switch constantly; If I were to install 3rd one, it would’ve been included into IME switching roster hotkey and I would have to cycle through all 3 IMEs as it’s not really possible to exclude single IME from the roster and leave it on a manual turn-on in Windows. Compounding that with the fact that percentage of Japanese input from PC is currently negligibly low compare to other IMEs, I consider it detrimental to install Japanese keyboard as IME.
Using the Inspector addon I was indeed able to confirm the id of the element and fix the script: