I think it would be nice to have the option to hyperlink with different text showing, like any basic HTML hyperlinking. Like I can even do in this forum if I needed to.
Visually, having the url just there isn’t appealing.
The URL Text to Display feature hasn’t been officially added yet, it is still in beta. You can sign up for the beta using the link below, which will give you access to the feature (with some other ancillary features as well). I have no idea of the timeline for when they make the feature official.
A note: this is not for the URL field type. You’ll have a new field type available called Rich Text Fields, which will allow you to type in some text (i.e. “Click Here”), and when you highlight the text there’s an option to add a URL to it.
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.
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.
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.
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!
Yeah, that makes a lot of sense. We’re looking to update our text editing experience soon, to provide better formatting which would include link title editing.
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.
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…
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.
I am new to Airtable as of today and was already quite sold on how it could improve on many Google Sheets tables I currently have that are basically very specific databases with relatively few records. But then I stumbled upon this issue – having to split every field that has a linked text into one text field and one URL field is quite a bummer and really surprising. So, +1 from me too for this feature. And I will have to see how much of a dealbreaker missing it is.
It’s scandalous, that they are 3 years old and can’t support a URL
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.
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…
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…
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…
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.
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 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?
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.
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.
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.
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?
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.
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.
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.
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}}
]);
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.
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.