I’m working on a Pali-English ebook of the DN and I’m finding some <j> tags that are breaking the epub validation.
"dn14:3.7.1": "Then that Great Brahmā, knowing what the Buddha Vipassī was thinking, addressed him in verse: ",
"dn14:3.7.2": "‘Standing high on a rocky mountain, ",
"dn14:3.7.3": "you can see the people all around. ",
"dn14:3.7.4": "In just the same way, all-seer, wise one, ",
"dn14:3.7.5": "having ascended the Temple of Truth, ",
"dn14:3.7.6": "rid of sorrow, look upon the people ",
"dn14:3.7.7": "swamped with sorrow, <j>oppressed by rebirth and old age. ",
"dn14:3.7.8": "Rise, hero! Victor in battle, leader of the caravan, ",
"dn14:3.7.9": "wander the world without obligation. ",
"dn14:3.7.10": "Let the Blessed One teach the Dhamma! ",
"dn14:3.7.11": "There will be those who understand!’ ",
"dn14:3.7.12": "Then the Buddha Vipassī addressed that Great Brahmā in verse: ",
"dn14:3.7.13": "‘Flung open are the doors to the deathless! ",
"dn14:3.7.14": "Let those with ears to hear commit to faith. ",
"dn14:3.7.15": "Thinking it would be troublesome, Brahmā, <j>I did not teach ",
It’s odd because in the official epub and html file there is a corresponding close tag, but it’s not there in the translation json.
I have also searched for the <j> tag online and can’t find anything. What is it supposed to be doing?
In Java it could denote a parametrized data type, in other words could be any non-primative data type ( a class/object ). Perhaps the author was trying to communicate the conviction that despite all of our superficial differences we are only going through the same functions.
Browsers want to be future-compatible and flexible, so most browsers will silently treat unknown tags like this as spans, but the HTML spec explicitly reserves the right to make an e.g. j tag at any time in the future. That’s why, as your linked article says:
prefixing is a best-practice. It solves the risk of colliding tags and it’s a helpful visual distinguisher between standard and custom tags.