when exactly that will happen, and if we can redo the current CSS to work under a new structure? and, if this will be the last change, so in the future, I don’t need to worry about going back to all apps and fixing them?
2 Likes
So just to be clear, if I have this custom CSS pointed at a ButtonBar:
would I only have to change the " > div > :nth-of-type(n)" to point to the new position of the ButtonBar?
If so, that would be better than what I was thinking – that this will no longer be possible at all.
Since I am new and have followed the advice of Glide Experts I feel their pain.
In this June 2021 post Glide asked the experts how they used CSS and I would expect with an expectation that when CSS went away many of the features called out from this post might have been integrated.
This awesome community has now created another list (my small requests are for tables and sticky components) of features they need to support APPS already built.
I hope Glide is rapidly responding to the Glide Experts on what can and can not be done with CSS in the new DOM model.
1 Like
Hi Matt and other people that have been using our Notion,
From David and Mark’s comments, I see that the DOM structure will change, but they will not disable custom CSS.
Me and other people will definitely spend time to update our Notion docs so that the old code will work with the new DOM, that’s the best we can do.
Let’s say previously, just for the sake of an example, a [data-test="app-vertical-list"] would now become something like [data-test="app-list"] > div[class="vertical"]. We will try to work together as a community to find those changes, and update accordingly.
As @Darren_Murphy and @Robert_Petitto have said, us experts have a good relationship with Glide. Whatever happens that leads to a better functioning app, I’m all for it.
For custom solutions that are not offiically supported like this, me and other people who use CSS will try our best to help others to get what they want when we have some free time, but still warning people that it is not supported, and can break any time.
14 Likes
This gives me hope that html tables will still work since the styling is self contained within the HTML table itself and not used against any native glide components. So from that standpoint, the styling would be stable as I assume it’s not affected by the DOM.
7 Likes
Well, this would certainly bring a sigh of relief to most of us. If it’s a matter of reimplementing the CSS in a different manner, then no problem!
8 Likes
strongly agree!
2 Likes
phew!
This gives me hope that my Roster Calendar may continue to work. I barely slept last night trying to figure out what I was going to do about that 
4 Likes
1 Like
I think it’s useful to understand Glide’s mission. If one truly adheres to Glide’s mission, then in my opinion one cannot support css (and markup for that matter) being a necessity in Glide. Optional, why not. Necessary, no.
Layout structure, not esthetics
Bob mostly uses css to compensate for placement/structural limitations in the builder, and I think this makes good sense. So Glide could probably add a few placement/structural features in the builder. But I wouldn’t push it with colors. Most 1 billion creators couldn’t design a good looking app if their life depended on it: giving Glide builders too many design options would just about guarantee that the output would look terrible.
Losing business / We depend on css+html for customer success
“Because of some sort of design limitation.”
Well, don’t oversell Glide’s capabilities: css isn’t and never has been part of the package. It’s pretty simple.
“Because Glide projects look the same.”
Be unique with the specific business pain point you solve internally within a business. If that problem repeats across businesses, then sell the same solution. But being unique in how the app looks is not that important in B2B (with Glide you won’t be building the next TikTok). This is especially true for apps for work (business), apps for good (non-profit) and apps for fun (personal).
CSS in Glide Pages
As it’s already been announced publicly, CSS might be optional in Pages at some point, just like in any website builder. But let’s be honest, 99.99% of Glide builders would probably be better off staying away from it.
If I had to guess, a design-related and possibly component-related announcement is just around the corner. The Glide team usually makes minor enhancements here and there, is pretty quiet for a few weeks and then suddenly releases something huge on the product side: 30+ computed columns, Glide Tables, Glides Pages, external data sources come to mind. Well, I feel Glide has been a little quiet these days, and now suddenly there’s a lot of talk about layout (css and design). This could only be related to the new computational model for Apps, but I think something else is brewing. Of course I have no idea and could be totally wrong.
8 Likes
your remarks are totally wrong… Glide is big mostly because of the best way of handling google sheets and the flexibility of applying CSS if there are limitations… if Glide decides to go its own way at this point… it will be a total failure… but lots of work for me to get all these big accounts into Google Apps… but, I always will feel bad for the little ones who lost months of work.
and I already announced to all my customers that I will be charging for fixing CSS… is not my fault… all of them agree… many of them wanna switch to another solution (they expect stability)… so… is gonna be a busy few months… like when Glide changed plans… 
5 Likes
On the other hand, this is the risk and the consequence of using startup tools. You join them when they are still searching and changing all the time. The business models, the target audiences, the functionalities, the technique. Part of startup life, I’m afraid, has been my experience in using maybe a hundred of them in the last decade.
4 Likes
Well the Glide Team have always said that CSS manipulation techniques may break one day. For this reason we have generally tried to avoid them wherever possible.
It’s therefore difficult to complain, on the assumption that a reasonable timeframe is given for us to address issues with existing solutions that do use them.
I would like to understand:
- What is the actual timeframe for switchover
- Will existing apps be unaffected or do all apps need to move to NCM
- Is any more UI flexibility available once the transition is complete
The last point is important since even the target audience of “internal apps and their customers” generally want more UI customisation than Glide currently allows.
4 Likes
Same here! I think there is a lot that can still be simpler.
@Darren_Murphy ow is the day going? CSS/html-style usage has A New Hope ™ 
Question for you and @ThinhDinh - I use this bit of code in a number of places to provide an alternative to the standard “See All”. Do you think it will still be usable based on your insights?
Funny - I literally know nothing about CSS/HTML (did I mention I spent 30 years in sales!) but have successfully integrated it in a number of places to add key functionality within Glide because this team of experts have been so articulate in its usage and deployment.
ALSO - as I have new questions about CSS should they go into a new thread versus pilling-on to this one?
→ View As Agenda
.see-all-custom {
font-weight: 600;
font-size: 0.875rem;
line-height: 1.0625rem;
color: #4574E8;
position: relative;
float: right;
}
I think you can expect this piece of code to break, yes.
We could keep this thread to comments about David’s initial post: “Unsupported HTML/CSS in the Rich Text component will completely break in the coming weeks”. You can always create new topics about CSS and give them a descriptive title, it helps keep the forum as organized as possible 
Please let us know exactly when things will break so we can be ready to fix the affected apps. Thanks! 
OMG