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