Maybe prepend? Replacing can be a bad surprise 
2 Likes
Edit: When I tried a Youtube link on the same site it worked fine:
https://forum.manjaro.org/t/the-vulkan-graphics-api-what-it-means-for-linux/16329?u=orajnam
When I try pasting this URL into the title bar, it doesn’t get automatically pushed down:
http://writing.jan.io/2015/11/20/sustainable-open-source.html
And it’s not recognised as a link:
Same for https://opensource.guide, https://karissa.github.io/post/okf-de and What makes a good community? – Sage Sharp.
This one has no HTML <head> neither OpenGraph nor oEmbed support.
Facebook does the heavy lift for you, by using the first <h1> as a title, and a random content inside the firsts <p> as the description. It would also use the first <img> as the image, but this page has none.
I would love for Onebox to do the same, but I’m not sure if the risks (more resource use, more attack vectors) are worth it 
.
This works for me.
This returns a 404 error with content, that’s crazy.
This one also doesn’t support OpenGraph, so it’s the same case as the first, we would need to do extra work.
3 Likes
Regardless of whether we’re able to onebox the link (or otherwise get some metadata) or not though, we should definitely
- push it over to the editor field
- still display it as an outgoing link in the topic index.
4 Likes
I disagree: if we can’t onebox the link, we can’t get the title (for topic titles or excerpt (it will be a plain vanilla link in the body) so there’s no real benefit.
The target site has to support opengraph or oembed for this to work.
The benefit is that you get to share a link, which I thought was the whole purpose of this feature. Virtually no other link-sharing site (Reddit, HN, GrowthHackers) follows this obscure “only if oneboxed” convention. Users are sure to be confused about why their link doesn’t create a “link post”.
We want this to be an easy way to seed a new community with content, right? It seems silly to exclude a huge swath of seedable content just because it can’t be oneboxed.
3 Likes
What’s the benefit? Zero time is saved. No title is generated. No summary. It is literally identical to manually starting a topic and pasting a link in. I guess all it would do is transfer the URL from the title to the body which seems quite pointless to me.
What you are really arguing for is some kind of fallback mode that manually scrapes the page and synthesizes a title, excerpt, etc which is a wholly new feature.
I suggest re-reading what @falco wrote closely.
Nope. My main gripe is this:
And it’s not recognised as a link:
Regardless of whether the link can be oneboxed or not, when you’re sharing a single external link, it should be rendered on Latest just like the rest:
I don’t really care about whether or not the URL is moved from Title to Editor, although I still think it’s bad UX to tell users to paste a link there when it will sometimes just awkwardly remain, effectively not working as intended
4 Likes
Our rule is, the target link currently has to support opengraph or oembed for that. See @falco’s response, it would be the same as mine.
Almost all “big” sites do, so this is really about the small fish. 98% of the time if you came to share a link to a popular website anyone actually wanted to read, it would support oembed or opengraph and thus work exactly as expected.
Edit: I am not opposed to more engineering work to have non opengraph and non oembed fallbacks but this is a sizable amount of potentially dangerous (parsing raw websites and HTML) engineering work, and it seems easier to just wait for other sites to get their 
in order and support proper embedding standards for everyone’s benefit…
3 Likes
Yes - this is a problem from my POV too. If a user thinks a website feature isn’t working properly they may give up using it, and feel like they’re doing something wrong. A user should never be made to feel stupid.
The problem with inconsistent website support for embedding will always be a problem on the web as long as it’s decentralised (and long live decentralisation!). The “semantic web” is a notorious non-entity. It didn’t happen, and probably never will.
All we need here is to improve feedback to the user when a link couldn’t be oneboxed.
5 Likes
… and it wouldn’t hurt to have some explicit feedback about whether the link will be featured or not too, since it’s not at all obvious, as @erlend_sh points out.
As a user, how do I know whether that little shortcut is going to appear in the topic list or not?
Even if the link is one-boxed there is no immediate feedback to tell me that that will appear (it will if I paste the link in the title box, but not if I paste it in the body – but there’s no way to really know that).
I’ve made similar points a few times above.
…
2 Likes
It.would introduce inconsistency and I don’t know if there would be room for it in all use scenarios, (I.e. phone) but some type of “title preview” similar to the text area seems like it could work.
2 Likes
In the case where oneboxing happens, it’s obvious that the topic will feature a link because the body and preview get updated automatically.
For the case when oneboxing doesn’t happen, we need to provide feedback in the composer somehow. Mockups?
So that you know that you’re creating a topic that looks like this:
3 Likes
I’m not worried about the visual feedback – if you paste an URL in the title field that should suffice. I am worried about keeping the code overhead to a minimum to cover this case.
This statement is incorrect. There are a ton of big sites, on a national scale, that return nothing or nothing useful to oneboxes. Global scale players mostly do, of course, but a community does not typically target the globe. The context is often regional, cultural or other niche.
For now, we can accept these links as featured links and copy them to the body.
6 Likes
I made this change. Links without oneboxes can be featured links.
14 Likes