URL--Text to Display Feature

I had a look at the RTF field type. This is a weak option at best. If you had a table with several thousand URL records, you would need to convert them manually (unless I’m missing something here). Also you are not be able to dynamically alter the link based on other criteria. This new field type doesn’t negate the requirement for a real HYPERLINK function.

Agreed, but the beta addresses some of the use cases mentioned in this thread, which is why I brought it up. I’d still like a url function for formula fields.

You’re not missing anything; using the rich-text field is simply one of many workarounds that one might use to transform what is otherwise a user-unfriendly display into something more friendly.

We must remember though, that Airtable is more like a database and less like a spreadsheet. We can hope and expect the tool to perform to our definition of spreadsheet, but there are specific design choices that the Airtable team made to address other data management requirements.

At the root of this topic is a design choice that is not entirely obvious and surrounds the lack of in-place transformations.

Most data systems that claim spreadsheet-like functionality support in-place transformations - i.e., a cell or column may contain both the data and a different rendering that is a function of the data. This is not possible in Airtable and why we tend to see a number of additional - seemingly redundant - rendering fields - i.e., data in one column and a transformed representation of that data in an adjacent column.

This is what I detest most about Airtable. It lacks the ability to perform in-place transformations and computations.

We don’t need a hyperlink function - rather, I believe we need the pervasive ability to perform in-place transformations for all fields. This will eliminate many issues that are well-documented in this community and things such as transforming a URL into a clickable name value will become inherently possible.

The rich text field type is a good workaround for displaying text for static links. I’m not clear whether this works for formulae, though. Eg. if you’re programmatically building a link in a formula field, I think you’re stuck with an ugly long link (no ability to set the display text) - as far as I can see!

Here is a script we wrote to solve this issue:

Yep - this is great that rich-text updates are now supported in Script Blocks. I’ve also been using this approach with the API -

They said in January 2016… Still not done!!!

It’s simple Bill. In the age of the internet, we want an URL in a text field. This is about the simplest thing you could ever ask of a web based product. Albeit an extremely limited product…

Indeed, I totally agree. However, I am only offering the community insight about a relatively useful approach to overcome this essential [web link] requirement that has been asked for and addressed by many apps since what - late 1997?

It’s not as if the separation of URLs and link names is a new thing, right? In fact, to put this into perspective, it’s very likely that this basic [web] concept was possible before the Airtable developers were born.

It is, and this specific request was initially created in 2016, so it’s coming up on half-a-decade. No reasonable and common feature expectation should be allowed to languish for a half-decade which is roughly the equivalent of 35 Internet years.

What’s the Problem?

My hypothesis is that this feature is challenging for the Airtable team because of some early architectural choices. Have you often wondered why so many Airtable apps suffer from formula field bloat? (i.e., multiple formula fields that serve to create intermediate or final values from other field values)

Unlike the vast majority of spreadsheet apps where multiple property layers make it possible for a single cell to have both a formula and a value, Airtable doesn’t support this design. And I believe that the inability to store a URL with a link name and render it with grace and beauty is because of this design limitation.

But even if my assessment is accurate, we can’t broadly indict Airtable for making this design choice any more than we can assume they aren’t doing something about it as we chat. This, and many other seemingly obvious requirements, happen in all products and tend to wane as the product and the customer base matures.

In the meantime, there are now a few remedies where there were none at all just 6 months ago. They’re not ideal remedies and they often require scripting in a “code-free” solution, a deep irony that does not escape my sense of humour.

It’s scandalous, that they are 3 years old and can’t support a URL

Apparently you didn’t read my response or I wasn’t entirely clear in my prose. Airtable is actually more than five years old and they do support linked URLs as evidenced by my screen shots. I don’t build or support any Airtable solution that openly displays URLs unless specifically asked to do so by my clients.

I get it; you’re upset that Airtable doesn’t work like other products in the “sheets” genre; that’s a fair criticism that I fully agree with and stated as much. However, dredging up complaints from 2018 that are no longer completely accurate reflections about the current state of Airtable is not helpful to users or to encourage Airtable to do better.

Scandalous?

In the grand scheme of things that should be addressed in Airtable, this feature doesn’t even make the top 25. :winking_face: If lack of integrated and native support for embedded field is scandalous, half the stuff I delivered to clients last week should be on the front page of the Enquirer.

The real problem was that it wasn’t documented that URLs can be added by enabling a long text to with rich text formatting… This the enables full URL functionality. However, I couldn’t find a single reference in any support material explaining this…

It is documented as inline text formatting on the support page about Formatting rich text in the long text field.

It wasn’t directly mentioned in the post announcing rich text, but the webpage above is available two clicks from that post.

With all the new features in rich text, I think that it is understandable that they couldn’t fit every last detail in the announcement.

Yep - this approach is not ideally documented to show these dependencies. But, rich-text implies embedded links which [then] implies the use of a [long] text field as if it were simply a smart [short] text field with embedded URL abilities. It’s the classic definition of a workaround, so it’s not surprising this is not fully documented.

What’s more surprising is Airtable 's markdown documentation doesn’t appear to reflect the actual behaviour of rich-text links.

Could you elaborate please?

Are you referring to Markdown syntax when

• typing in text with a physical keyboard


• copying/pasting text


• setting text via one of the APIs

I find that I am able to enter some Markdown formatting when typing text, such as bold, italic, lists, checkboxes, but not others.

I find that if I copy/paste text, Airtable does some behind-the-scenes processing to adjust Markdown code. For example, if I copy bold text from a rich text field and paste it in a different app, it won’t be bold in the other app. If I copy Markdown source text into a rich text field, the markdown syntax is escaped and shows up as plain text.

I am simply suggesting that if you create a link in a rich-text field [manually] and then examine how Airtable actually stores it in the field (using the API or a script block), you will be surprised at the “markdown” it actually uses.

This is because (I think) the rich-text field is actually Airtable’s own version of markdown and rich-formatting design - it’s markdowny-like, but not actually Markdown. And this would explain why copy/paste actions will not behave as you might expect.

Correct, but all editors do this right? Including the one we’re using right now. How should this (or any rich-text editor) respond when handed something like this text when pasted or typed?

# This is a test...

It should probably escape it from any assumption of implied formatting, right?

Airtable has documented that it is a variation on Markdown, not actual Markdown. Documentation also says how the rich text fields are handled in the API and calculated fields. I have not found documentation that says how copy/pasting to/from a rich text field is handled.

Well, when I copy bold text between Excel and Word, it stays bold. That’s not the case when going between Airtable and Word. In Word and Excel, I also have the option to paste text as plain text or as formatted text. But Word is a word processor. I don’t expect Airtable to have as robust text editing features as Word.

The same team build the rich-text systems used across all Microsoft products, so this is not surprising. And neither of those apps support Markdown without a third-party plugin.

Word and Excel was just an example. Copy/pasting bold text among MS Word, MS Excel, Google Docs, and Google Sheets all works the same. Bold text is retained. If I copy bold text from a web page and paste it into any of the above apps, the bold text is retained.

On the other hand when I copy/paste rich text to/from MS Access sometimes the text is bold and sometimes it isn’t. MS Access of rich text is also very limited, and is not true rtf, just as Airtable rich text is not true Markdown.

I get it that rich text can be tricky to implement, and that copying/pasting from other apps with different encoding methods can have limitations. That is also why I appreciate clear documentation.

I haven’t thoroughly tested Airtable’s rich text, but I haven’t found any places where rich text does not behave as documented, including when using the API. I have found some aspects where the behavior is not documented and and the behavior might not be as expected or desired, but that’s a different matter than saying that the documentation is wrong.

Okay - this has not been my experience or @Jerry_Hall’s as evidenced in this thread. Furthermore, @dave_brand makes a fairly good case that the documentation doesn’t actually reflect behaviour as evidenced here.

Have you actually tried to update a rich-text field with script using a vanilla Markdown link?

Yes, I’ve both created and updated a rich text field with both forms of links using the scripting API. In all four cases, it worked as documented. I have not done tests with the Standard API, blocks, or 3rd party integrations.

It looks like the two cases that you mention are slightly different from using the API: CSV import, and Zapier integration. I believe that neither of these use cases are documented, just as what happens with copy/paste is not documented. In fact, the behavior that they are seeing in these two cases is very consistent with the behavior that I see with copy/paste.

In the thread where rich text was announced, I specifically asked if there was a way to automatically convert long text that wasn’t rich text (but was valid markdown) to rich text, but my question went unanswered. For now, it looks like using a script is the way to go for batch conversions.

Just to be clear… you have used the API to update a long text field with Markdown enabled and the text pushed into the field looks like this and actually works?

[I'm an inline-style link](https://www.google.com)

I have tried this through many API pathways and it always fails to create the desired inline link. Alternatively, this format works via the API, Script Blocks, CSV imports, Zapier, and Integromat.

[I'm an inline-style link][1] [1]: https://www.google.com

I believe both of these formats are technically markdown, but Airtable docs actually specify the one that doesn’t seem to work as evidenced by this test.

I’m glad it’s working well for you but there are a number of users (including me) who are experiencing the opposite. I wonder if you have some magic in your script that no one seems to understand.

[I'm an inline-style link](https://www.google.com)

[I'm an inline-style link][1] [1]: https://www.google.com

Sorry it isn’t working for you. I don’t have any magic in my script. I’m just following documentation.

let table = base.getTable("Table 10");



let markdownLink1 = `[Link reference][1] also works.



[1]: https://example.com`;



let markdownLink2 = `This is a [plain](https://example.com) link.`

let markdownLink3 = `[I'm an inline-style link](https://www.google.com)`;



await table.createRecordsAsync([

  {fields: {"RichText": markdownLink1}}, 

  {fields: {"RichText": markdownLink2}},

  {fields: {"RichText": markdownLink3}}

]);

[I'm an inline-style link](https://www.google.com)

[I'm an inline-style link][1] [1]: https://www.google.com

In that test, he isn’t using the API directly. He is using Zapier. Now using Zapier does require having an API key, but that is not the same as using the API directly. We don’t know how Zapier is interfacing with Airtable, beyond the fact that it uses the same API key as other APIs. If I recall correctly, there was a thread implying that Airtable might have a special API just for Zapier’s use. Since how Zapier deals with rich text fields isn’t documented, I don’t think it is fair to say that Airtable is not working as documented based on this specific use case.

let table = base.getTable("Table 10");



let markdownLink1 = `[Link reference][1] also works.



[1]: https://example.com`;



let markdownLink2 = `This is a [plain](https://example.com) link.`

let markdownLink3 = `[I'm an inline-style link](https://www.google.com)`;



await table.createRecordsAsync([

  {fields: {"RichText": markdownLink1}}, 

  {fields: {"RichText": markdownLink2}},

  {fields: {"RichText": markdownLink3}}

]);

Cool. Maybe it was broken earlier this year while in beta and now it’s more consistent.

Can you show me a screenshot of Table 10?