Deprecate <rp> element

[NagayamaToshiaki]

I'd like to issue the deprecation of <rp> element because of the following reasons.

• Most Browsers imprement <ruby> and <rt> elements.

https://caniuse.com/ruby
https://caniuse.com/mdn-html_elements_rt

• It doesn't make sense as the element itself doesn't convey any means other than separation of <rt>'s content and <q> elements' quotation marks, which has simular purpose, is not hard coded in html. If necessary, like the browsers' implementation of <q> elements' quotation marks, using css' rt::before and rt::after pseudo elements is more consistent.

[NagayamaToshiaki]

@Yay295 Would you please tell me why you thumbed down? Your opinion surely will improve the issue.

[Yay295]

The purpose of <rp> is to provide a fallback if Ruby elements aren't supported. If Ruby elements are supported it shouldn't be visible. <q> is always visible. Also the semantics are different: <rp> represents fallback content, while <q> represents a quote.

[NagayamaToshiaki]

@Yay295 Thank you a lot for response. I was afraid you were a troll and I'm sorry for that. I understand what you mean and now I'm sure <rp> and <q> is different in design.
I thought CSS should be responsible for the parenthesis presentation if rubies can't be rendered, but this is problematic when you want to copy the sentence because the words coalesce.

(FYI Chrome or Edge doesn't copy the <rp> element when you copied both <ruby> and <rt> with <rp> simultaneously while Firefox copies the starting parenthesis if you copy somewhere inside the <rt>. If you copy the <ruby> element and its outside, Chrome copies <rt> element successfully without <rp> and FF only copies ruby base text and ongoing text)

My main subject doesn't change much though: fallback isn't necessary now.

[domenic]

Disclaimer: the below is based off of an amateur understanding and I would greatly appreciate any corrections from domain experts, such as @fantasai, @frivoal, or @whatwg/i18n.

My take on this is that the <rp> element is not well-documented in the spec. It says it's "to be shown by user agents that don't support ruby annotations", and it talks about how in "conforming user agents" it won't be rendered.

So on first reading it does seem like, this is an element that should not exist, all modern browsers support ruby, and we should just get rid of it. We shouldn't be suggesting authors clutter their document with <rp>s, just like we don't suggest they clutter their document with <span style="some-css-hack-that-only-shows-this-in-browsers-from-2015-onward">stuff</span>.

(On the other hand, <noscript> and nomodule="" exist...)

However, my understanding is that it's actually intended for a broader use case than "content which works in pre-2015 browsers". It's also useful for giving the desired parentheses placement (or other fallback content) for plaintext-only contexts. A prominent example of such a context is pasting into a code editor, or "paste as plain text".

It's also the case that some tools store ruby markup in plaintext format, e.g., some Japanese-learning flashcard apps I have used have you enter the words in a form like "漢（かん）字（じ）", which they translate to appropriate <ruby> and <rt> elements at display time. Although this case doesn't directly need <rp> elements to exist, it does indicate there's a shared semantic meaning and value in the parentheses, and you could imagine how consistently-marked-up words could be useful for more advanced versions of this tool (e.g. ones that try to scrape existing content and use them to create flashcards automatically, while maintaining the plaintext storage format).

[tabatkins]

It's also useful for giving the desired parentheses placement (or other fallback content) for plaintext-only contexts. A prominent example of such a context is pasting into a code editor, or "paste as plain text".

Note, tho, that the rp is display:none'd in supporting UAs, which means it's not put into the clipboard, and so wouldn't be useful for this case anyway.

(e.g. ones that try to scrape existing content and use them to create flashcards automatically, while maintaining the plaintext storage format).

I'm not certain how this would work - if it's plaintext it won't want the markup, but if it doesn't have any markup then it's trivial to add parentheses at the same time as you're extracting the text. I suppose this lets people do text extraction with nothing more than a .textContent on the ruby, but this isn't something you can do generally anyway (if you're translating to plaintext, you'll want to add indicators for em/etc too, which have to be done manually).

---

I believe I'm on the same train, with rp being a funky legacy thing that we could relegate to the deprecated-but-supported section now that ruby is widely supported, with just an rp { display: none; } required UA style rule.

[Yay295]

Would visibility: collapse work better? I think that would allow it to be hidden but still selectable. It looks like only Firefox might support that right now though.

[zcorpan]

Also see #1801 where this was discussed in the context of the innerText getter. The special handling of rp (which was implemented in Gecko at the time) was removed in #2129

[acli]

q is poorly designed; IMHO deprecating rp would result in the same kind of poor design.

The whole purpose of rp is to mark up parentheses that will fall back correctly on browsers that don’t implement ruby (e.g., text browsers). If you take out all the tags, the resulting text is still valid. The reverse is useful when teaching HTML, because we can tell people that HTML is just normal text with markup added.

The problem with q is that using q requires the quotation marks to be removed, so q really isn’t markup. Similarly, if we depended on :before and :after to insert parentheses, it means we can’t start with a piece of text (e.g., a piece of news wire) and just add markup; we’ll have to remove text in order to make the result valid.

[NagayamaToshiaki]

@acli I had no idea of plain-text viewer.
But I disagree with you. In your rhetoric, <a> doesn't make sense too.

The purpose of <q> is its contents are somebody's words quoted by the author of the document, so as <rt> is the ruby annotation of the text before. The quotation mark or parenthesis are just the visual indication and doesn't convey any meanings. Also, you can insert gibberish in <rp> which will bother text browser users. Those simple yet pesky tasks should be the job for browsers, which interprets HTML and display it to be comprehensive to humans.

[tabatkins]

If you take out all the tags, the resulting text is still valid.

This is already violated by a number of HTML tags - as @NagayamaToshiaki says, a definitely qualifies, as does sub/sup (how many times have you seen something like 106 in a text version of a scientific PDF and had to realize it meant 10<sup>6</sup>?), a lot of the block elements like li or details, etc.

HTML adds semantics to text; it is not necessarily separable from text, and we absolutely don't optimize for that naive "just display all the text content" case. If we did, then we'd have things like 10<op>^</op><sup>6</sup>, with user-agent CSS saying that if you support sup you should display:none a preceding op element; we'd have <li><bu>* </bu>first item; we'd have <a href=http://example.com>click here<nolink>(http://example.com)</nolink></a>; etc. An actual text-only browser that wants to display HTML needs to know how to display textual equivalents of all the tags; such a browser can and absolutely should render <ruby>foo<rt>bar</ruby> as "foo(bar)", without needing the author to add parens themselves; otherwise it would simply be broken.

rp was a markup hack to handle inconsistent ruby support across rendering engines. It was clever, but it serves no useful purpose beyond that. We do not (and should not) recommend that people author their ruby with rp today. As far as I can tell, it can be safely relegated to the deprecated-but-supported appendix with other now-obsolete elements.

[acli]

@NagayamaToshiaki q is terrible. It does not exhibit “graceful degradation” — a quality we used to highly value in HTML — and it’s absolutely the only element in HTML (maybe other than table) that behaves like this. Let me show you.

Let’s start with this notice from the W3C’s home page:

The Web Real-Time Communications Working Group has published a First Public Working Draft of MediaStreamTrack Insertable Media Processing using Streams.

To make it HTML you mark up the paragraph with tags (and in particular with a, which you claim to “not make sense”). That’s all. No deletions:

<p>The <a href="https://www.w3.org/groups/wg/webrtc">Web Real-Time Communications Working Group</a> has published a First Public Working Draft of <a href="https://www.w3.org/TR/2022/WD-mediacapture-transform-20220210/">MediaStreamTrack Insertable Media Processing using Streams</a>.</p>

This means if a researcher is writing a piece of ad hoc software that analyzes a collection of texts, the software can retrieve the plain text contents simply by stripping all tags away. You’d get exactly what you started with.

q behaves completely differently. Consider this piece of source text:

According to the W3C, the Web Real-Time Communications Working Group “has published a First Public Working Draft of MediaStreamTrack Insertable Media Processing using Streams.”

The sensible way to mark up the meaning of this sentence would be:

(Invalid example) <p>According to the W3C, the Web Real-Time Communications Working Group <q>“has published a First Public Working Draft of MediaStreamTrack Insertable Media Processing using Streams.”</q></p>

but it produces inconsistent results depending on what kind of browser you’re using and whether you’ve disabled the CSS for q (e.g., through reset.css). Instead, you need to delete the quotation marks:

<p>According to the W3C, the Web Real-Time Communications Working Group <q>“has published a First Public Working Draft of MediaStreamTrack Insertable Media Processing using Streams.”</q></p>

This produces correct results on recent browsers by default, but produces incorrect results if the CSS for q has been disabled (e.g., through reset.css), on text browsers, or on user agents that are not browsers (e.g., ad hoc research software written to analyze text content).

There is absolutely no way to mark up a piece of text with q that produces consistent results. No matter how use q, some software will see quotation marks sometimes (even most of the time, but you can’t guarantee it); other software will never see any quotation marks.

rp is a much better designed element. The whole purpose of rp is to provide “graceful degradation”. It does exactly what it was designed to do and the purpose is precisely to avoid the problem with q.

(PS: One of the most well-known text browsers was written by a Japanese researcher. It’s sad to know text browsers are no longer well-known by Japanese people.)