What is the <j> tag?

Feedback
1

I’m working on a Pali-English ebook of the DN and I’m finding some <j> tags that are breaking the epub validation.

E.g.:

"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?

2

The answer is here:

See also:

But yeah if Google Play doesn’t like it we should fix it. It’s not really relevant in ereaders anyway (because the reading environment is arbitrary) so we should probably just strip them from there.

2 Likes
3

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. :slight_smile:

4

Ah, thanks! I swear I searched for <j> and found nothing. But now I do remember reading about it a while back.

1 Like
5

That is such a beautiful answer, thank you! Way better than reality!

1 Like
6

Yes, it seems like this is a problem with the epub validator.

If I’m understanding correctly, then this css should render the j tag as intended?

j {
display:block;
margin-left:1em
}
7

Something like that, yes.

I think I mentioned before, but we should strip those tags for EPUBs. On the 2-do list!

1 Like
8

Is there some centralized documentation for all the Bilara quirks?

The j tags seem to work fine. It’s just a broken validator.

9

I don’t think that’s true.

Some epub readers can handle it, but it’s technically not spec. HTML allows custom tags, but EPUB does not.

1 Like
10

Hmm. I thought that the latest epub spec just included the html spec, but obviously I don’t know what I’m talking about.

So it sounds like they should be converted to spans with a class.

11

The j tag isn’t even valid HTML, as custom HTML tags are supposed to include a hyphen.

And EPUB offers only a subset of HTML functionality. For example, no script tags.

1 Like
12

It’s really just a placeholder, an easy-to-write sign that says “do what you need to do to make an enjambment here”.

But yeah, given the nature of the EPUB context, just delete them.

If you want to make a web component then yes. If you just want to include a styling hook, then for web purposes it’s not an issue.

https://dev.to/jfbrennan/custom-html-tags-4788

1 Like
13

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.

2 Likes