I see a lot of posts where people are using HTML in Rich Text components when they have been warned not to, because Glide says they may not support it in a future Glide release.
One of the complaints is the limitations of displaying table data and how you can’t get the spacing to span the full width of the screen. IF you know in advance the exact column sizes you want, and the destination devices screen width, you can use the following work around to get pretty close to what you can get by using HTML.
The trick is to use transparent png’s to accomplish the spacing. In the below example I created 2 pngs, one 165x1 and the other 100x1. I am using these in the title area of the markdown table. Here is the result:
 |
 |
|
| Left Column |
Center Col |
Right Col |
| More Text Here |
And More |
Finally |
Here is the code:
|[]()|[]()|[]()|
|:---|:---|:---|
|Left Column|Center Col|Right Col|
|More Text Here|And More|Finally|
Copy and paste it into Glide to see the results in an app. BTW I used Gimp to create the png’s. Time to create the png and upload to imgur was under 1 min each.
2 Likes
I read somewhere here that the reason HTML and CSS are frowned upon are specifically because they are hard for Glide to standardize across devices. So the fact that this work around requires you to know a specific output screen seems to contradict that design philosophy.
I’m one of those folks using HTML here. I’m certainly worried that I’ll wake up one day and large portions of my app will be a mess, but honestly, there are not enough styling options currently for designers. Being forced into set fonts, font sizes and font colors is extremely limiting for certain types of apps. Using transparent images as markdown hacks seems like a similar way to get more style out of Glide than it appears the devs want us to have right now.
If I had to guess, a lot of folks are using HTML and CSS at this point. So I would at least hope if the devs do decide to remove HTML and CSS from Glide that they give us ample warning to prepare for the inpending apocalypse. That said, I’ve always interpreted “we don’t support HTML and CSS” to mean, “we aren’t developing those features any more right now because they make it hard for us to standardize across iOS and Android, so we can’t address any concerns or wants in regards to that capability.” Not necessarily that they are planning to remove the capability.
1 Like
I also feel somewhat comfortable with very limited and basic html use because in the end markdown is still rendered as html. Take a look at the tables in dillinger and you will see that it’s an html table with table, tr, and td tags. I’ll never promote the use of html and will always advise against it, but there are occasional cases where markdown by itself is limiting in what it can do. However, some markdown versions do promote the use of a limited subset of html tags in combination with markdown.
It’s my impression that markdown has it’s standards, but any use beyond that is not supported because I assume Glide could switch up which markdown engine they use at any time.
May I see your app that you build on html?
@Muhammad_iqbal the app is still in development, but when I’m finished, I plan to create a public version for folks to browse. I’ll let you know.
@Jeff_Hager that makes sense about possibly switching up markdown engine. But in that case, why not an HTML component separate from markdown? I understand that the no-code movement is about democratizing app creation, but spreadsheets themselves support a wide spectrum of “magic” code, and with google sheets you have access to scripts as well. So it seems perfectly reasonable to include HTML/CSS for those who have the skills to use it just as sheets provide advanced functions for those who have the skills to write them. So from that standpoint, it looks (to me at least) like HTML/CSS is not promoted out of fear it would enable users to make stylistic choices that the Glide designers would not deem “good design practices”. Yes, HTML/CSS require understanding the differences in browsers, unsupported styles, differences in how elements and styles are rendered. But the internet is full of designers who do effectively juggle those decisions—many of whom could do tremendous work with Glide.
I agree, it’s probably to maintain consistency across all apps, but I have to wonder if it may be a security concern as well. Having an entry field that that is later rendered as a rich text component could allow any user to potentially use html or javascript injection for various hacks against other users. Since Glide is playing middle man, I’m sure they want to maintain integrity and minimize any database breaches. I’ve seen unclosed tags the the app for a loop, so I imagine its possible to some point. Just like SQL injection can be a risk on websites that don’t protect against it, you have to be careful when allowing entry fields that can be converted to front end or back end code.