Mini (Inline) Onebox Support RFC

Replacing my <a href="url-goes-here">description about url</a> description about a url will break my in-line use of html links. The og:title (or whatever) is unlikely to fit in the sentence the same way. Am I misunderstanding this? Is it a proposal for adding a footer with that information? I look at that Wikipedia thing and think that it is just about the decoration around the links. That I’d have no issue with.

If the url has a description it will not be replaced. This will only happen on links that don’t have descriptions, for example

<a href=""></a>



I think it would be good to have a way to ‘opt out’ of the mini-oneboxing, in the same way as we can opt out of normal oneboxing by putting a space before the link. That said, I can’t think of a tidy way that could be done inline, whitespace clearly won’t work…

1 Like

Some suggestions:

  • Always prefer opengraph/etc to title cause stuff like this is bad:

<title>Hummus Kitchen - Reservations - 340 Photos &amp; 598 Reviews - Middle Eastern - Theater District - New York, NY - Phone Number - Menu - Yelp</title>
  • If title is too long always truncate and add elipsis at some sane length. (site setting maybe)

  • To opt out easily use this syntax: <> , very easily detectable in our engine.

  • We got to protect the Mini Onebox from hammering servers… should only request first N bytes of the page.

I like the external link icon, keep in mind some people may want to style it themselves for self owned domains and so on, so a class with the domain name would be nice. I would definitely avoid re-hosting and downloading custom favicons per site in the initial implementation, a default font-awesome icon for off-site is fine for the default. (also consider adding it optionally for any external links, at a minimum add a class on every A for internal vs external)


Why? This would be incredibly noisy from a visual standpoint… we already show click counts so now we’re showing a favicon on every link on top of that?

Also we kinda buried the lede here… we are only proposing this behavior when self-linking to your own Discourse instance, for v1 of this anyway.

So you’d only get this behavior when posting internal links to your own Discourse at least for v1.9. We could unlock “all links” behind a site setting perhaps for testing.

Well, the whitelisted domain part didn’t seem so buried lede to me. Maybe overthinking a V1 implementation. Or maybe the buried lede is self-links come whitelisted, and everything else is additional configuration.

But taking Wikipedia for example, there are many sister sites that are part of the same project but have different domains. Wikiquote, Wiktionary, Wikisource, etc. I like the idea of CSS styling that could be different for each. Sam’s class per domain would do that nicely.

To avoid clutter mini-onebox links like this could use a leading icon, or suppress showing a visit count (not suppress keeping one).

I’ve just deployed the first version of this that supports linking to topics. For example: inlineRegexp with the new Markdown-it

Tomorrow I’m going to look at the whitelisted title version.


Okay, I’ve added whitelist based support for inline oneboxing via <title> or opengraph tags:

(I also fixed the emoji issue).


One issue I noticed was that “rebake” is not fixing up the titles if you rename the original.

Also, looks like it is not working in list items: eg: CommonMark testing started here! :vulcan_salute:


  1. CommonMark testing started here! :sadpanda:

The problem here is I cache lookups for 1 day.

I think there might be an option when rebaking to invalidate the cache so I will look at that (as well as the list case).


I wonder title is a better default than og:title?

Cause for example:



But could be:

discourse/ at master · discourse/discourse

Even NYTimes ships with pretty crappy og:title when consumed as a pure title: eg: Technology - The New York Times has the og:title technology, which really sucks unless coupled with an NY times logo.

My call would be to prefer title for now, cause it seems more correct on more sites.

Additionally, I think we should add a site setting for “enable mini onebox on all sites” that way we can properly test this here.

Longer term maybe we should look at adding a favicon, or maybe allowing the onebox gem to handle custom titles and so on.



Added the setting enable inline onebox on all domains, which is enabled here.

Also, after trial and error I think title is a far better default, so I changed it. I also fixed some issues with resolution of inline oneboxes in lists.

Some example mini oneboxes

Personally I LOVE :heart: Mini Onebox for everything ™ … I think it is spectacular! And think that we should make it default in a few weeks.

In contrast I think this is spectacularly ugly :japanese_goblin:





Long term I would like to spruce up inline oneboxes so it possibly includes a favicon or some other additional decorations and maybe even move it to the onebox gem.


This is fine, but I am strongly opposed to adding a favicon to every link. At best an optional option.

Sure this is all going to be optional, the advantage of moving this to the onebox library long term is that it can “normalize the text”

Some sites like - GitHub other’s | Ars Technica, normalizing all of this has tons of appeals to me. But its definitely a v2 thing.

Almost 2 weeks later I still feel that enable inline onebox on all domains is a far better default. People are using it here and enjoying it lots. The edge case of is fixed. There is minor level of muttering about people that need to discover the < > trick but I don’t think this warrants not making it default.

Should I go ahead and make it default?

1 Like

I dunno there is a lot going on, would rather take some
time on this. We spent 2 months cleaning up after always on regular onebox.

OK, will chase this up in 2 months.

1 Like

In I’ve got a mini onebox and an ordinary onebox, both pointing to different parts of the same topic. After posting I changed the title of the topic, so I rebuilt did a “Rebuild HTML” to fix the titles in the oneboxes.

The regular onebox got fixed, but the mini onebox remains the same.


Just came across a very minor issue: In a composer preview, the mini-onebox doesn’t kick in without a protocol specified:

But when I click save, it turns into a mini-onebox:


been complete for quite a while!