Note link cards disappear in reader mode, so I investigated the cause and sent a request for improvement

There is a mechanism called RSS (Really Simple Syndication) for distributing update information from websites. By registering blogs and the like in an RSS reader, you can conveniently check new articles from multiple sites all at once.

In the case of note, you can obtain it simply by adding "/rss" to the end of the creator page URL. Please refer to the help center for detailed specifications.

Displaying note on your own site using iframe or RSS - note Help Center

When reading RSS on Android, I use an app called Read You.

One day, while reading my own note articles on Read You, I noticed something concerning.

The link cards I placed in the articles are not being displayed.

I can read the main text. Images are displayed too.
Only the link cards have neatly disappeared.
At first, I thought, "Maybe it's a problem with Read You."

However, once I started investigating, the issue turned out to be broader than I thought.

To begin with, why can I read the full text of the articles?

First, what I was curious about was,

Why can I read the full text of articles on Read You even though note's RSS does not distribute the full text?

That is the question.

The RSS normally distributed by note only contains a portion of the article text. By the way, with the corporate "note pro" plan, you can also distribute the full text via RSS.

However, note pro costs 80,000 yen per month (excluding tax).

It is not a price that an individual would pay just for the reason of "I want to distribute full text via RSS." So, where is Read You getting the full text from?

Upon investigation, I found that Read You uses Mozilla's Readability to extract the main text from web pages.

Readability is a library used to extract what is considered the main body of an article from a web page and organize it into a readable format.

Firefox's Reader View also uses it. So, I opened the same note article in Firefox and tried out Reader View.

As expected, the link card was not displayed.

The link card also disappeared in Vivaldi

The browser I usually use, Vivaldi, also has a Reader View.

I tried the same article here as well.
The result was the same.

The link card was not displayed.

Looking into it, Vivaldi's Reader View also uses Mozilla Readability. This much is easy to understand. If they use the same mechanism, it is no surprise that the same parts disappear.

So, what happens if a different mechanism is used?

Chromium used a different mechanism

Next, I looked into Chromium.

Current Chromium has a "Reading Mode." This is not Readability, but a different mechanism called Read Anything.

As I continued my research, I learned that Chromium also has another text extraction mechanism called DOM Distiller.

At this point, I was thinking,

"If it's a different mechanism from Readability, maybe the link card will remain."

That was about as far as I had thought.

First, I tried the Reading Mode available in the current Chromium. I opened the same note article and displayed it in Reading Mode.

The result was,

the link card was still not displayed.
It disappeared even with an implementation different from Readability.

At this point, I started to think, "This doesn't seem to be just a Readability issue."

It doesn't display in Instapaper either

I also checked it in Instapaper, which is famous as a "read-it-later" service.

Instapaper uses its own proprietary text parsing technology.
However, the result was the same.

The link card is not displayed.

So far, I have checked:

• Read You

• Firefox

• Vivaldi

• Chromium

• Instapaper

.

The text extraction mechanisms used are not all the same. Yet, the note link cards still disappear.

Could it be that the note link cards themselves have a structure that is incompatible with text extraction?

That question came to mind.

Looking at the HTML after JavaScript execution

The first thing I thought was,

Since link cards are generated later via JavaScript, perhaps the text extraction side cannot retrieve them?

That was my hypothesis.

So, I used the Chromium developer tools to save and check the HTML after the page had loaded.

The link card exists.

In other words, it doesn't seem to be a simple case of 'it couldn't be retrieved because JavaScript hadn't executed yet'.

Looking at the area around the actual link card, the structure was generally as follows.

<div data-embed-service="note">
  <iframe
    class="note-embed"
    src="/https://note.com/embed/notes/...">
  </iframe>

  <a
    href="/https://note.com/..."
    style="visibility: hidden;">
  </a>
</div>

I see.

The visible link card is actually an iframe. On the other hand, there is an a tag on the parent page side that points to the link destination. However, although the link destination URL is set, the content is empty. Furthermore, it is hidden with visibility: hidden.

Come to think of it, there was something I had been wondering about for a while.

Note has a setting to change the article font to Mincho. However, even if you set the body text to Mincho, the text inside the link card does not become Mincho. Until now, I just thought, 'Maybe it's because the link card has a different design'.

After checking the HTML this time, it makes a bit more sense.

The link card is not rendered directly as part of the body text, but is displayed as a separate page inside an iframe. Therefore, it seems that the font settings of the article body, which is the parent page, are not inherited as they are into the link card.

The small differences I had noticed before have now connected with the HTML structure I confirmed this time.

From the perspective of the body text extraction side,

• the card itself is an iframe

• there is no link string visible on the parent page side

• the content of the a tag is empty

• and it is hidden

is the state.

If the iframe is excluded during body text extraction, nothing remains.

The reason why the link cards disappeared cleanly in multiple reader modes has become a little clearer.

Since I was at it, I also tried it with DOM Distiller-based tools.

DOM Distiller, which I found when researching Chromium. I'm curious about this one too.

However, I couldn't find an easy way to call DOM Distiller directly in the Chromium version I tried this time. Upon further investigation, I found something called Go-DomDistiller, which is a port of Chromium's DOM Distiller to Go.

I used the stable version for verification this time.

go get github.com/markusmobius/go-domdistiller@stable

Go development environment installed.

I created a small verification program and had it load the HTML after JavaScript execution that I saved earlier.

This is the code I actually used.

package main

import (
	"fmt"
	"os"

	distiller "github.com/markusmobius/go-domdistiller"
)

func main() {
	result, err := distiller.ApplyForFile("note-rendered.html", nil)
	if err != nil {
		panic(err)
	}

	err = os.WriteFile("distilled.html", []byte(result.HTML), 0644)
	if err != nil {
		panic(err)
	}

	fmt.Printf("distilled.html を作成しました（単語数: %d）\n", result.WordCount)
}

At first, it was just a matter of 'the link card isn't showing up in the RSS reader,' you know.

For some reason, I'm running a Go program.
My entire Sunday afternoon was wasted.

When I checked the HTML after extraction,

the link card was gone.

I searched further, but the URL to the original article that should have replaced the card was also missing. It had completely disappeared.

Of course, Go-DomDistiller is not the same as the DOM Distiller in Chromium itself. Therefore, I cannot definitively say that the same result will always occur in Chromium itself.

Even so, the same trend occurred with DOM Distiller-based implementations.

I don't want the link card's appearance to remain

Let me clarify one thing here.

I am

not saying that I want note link cards to be displayed with the same design even in reader mode.

I don't mean to say that.

Reader mode is a feature to remove decorations and make the main text easier to read. I understand that the card's image and description disappear.

What bothers me is that

it becomes impossible to even know that there was a link there

is the thing.

For example,

Suppose you place a link card immediately after that sentence.

On a regular note, a card for the related article is displayed below it.

However, in reader mode, it ends with

it ends there.

"Which article?"

is what happens.

If you are using only link cards to create a path to related articles, not only do the links disappear, but the flow of the text also becomes a bit strange.

I sent a request for improvement to note

So, I sent a request for improvement via the note inquiry form.

What I asked for was not that they reproduce the link cards in reader mode.

Even if the link card is excluded, I requested that they consider an HTML structure where at least the existence of a link is apparent, such as

or

as a minimum requirement.

Looking at the current HTML, the link URL itself exists on the parent page side. It does not seem that the link destination is unknown.

If a meaningful regular link can be placed outside the iframe, the navigation path might remain even after the main text is extracted.

Of course, I do not know the internal implementation details of note.

It might not be as simple as I think, and I don't know if it will be addressed.

For now, I have summarized what I confirmed and sent it as a request for improvement.

I will also place text-based links

I don't know how note will respond in the future. So, what can I do myself right now?

The conclusion is simple.

Do not rely solely on link cards for important links.

For example,

I will set a link on the article title text as well, in that format. Below that, I will place the usual link card.

On a regular note, the link card serves as a visually clear navigation path.

Even if the link card disappears in reader mode, the regular text link will remain. It makes for a somewhat redundant notation, but this is not just about RSS readers.

Even with text browsers like w3m that I have used for a long time, regular links can be followed. Come to think of it, it was a very simple countermeasure.

Summary

It started when I was reading my own article in Read You and

"Huh? The link card is missing."
noticed that.

I thought it was just a problem with Read You, but it also disappears in Firefox. It also disappears in Vivaldi. It also disappears in Chromium, which uses a different mechanism. It also disappears in Instapaper. In the end, I was even running Go-DomDistiller.

As far as I have investigated, the link card itself exists in the DOM after JavaScript execution.

However, the card itself is an iframe, and the regular link on the parent page side is empty and hidden. I believe this structure is one of the causes that is incompatible with the main text extraction process.

I have sent a request for improvement to note.

I don't know if the specifications for link cards will change. For now, I'll just take the measures I can myself.

Don't rely solely on link cards for important links.
Place a regular text link alongside the link card.

Whether it's an RSS reader, reader mode, or a text browser, I want to make sure that even if the link card disappears, the link itself remains.

By the way, for the links to external sites included in this article, I have set links on the text as well, not just on the link cards.

I have immediately put into practice what I investigated this time.

Well then...

I'm going to check the link cards I placed in past articles and add text links where necessary.

...I wonder how many articles there are.

Ah, what a pain.