How best to target css selectors for inject css?
The new update of SaaS Studio Web 5.29 broke a bunch of our custom styling. I had assumed that the cryptic named classes and ids would persist but it seems like they maybe have they changed with the update? This is highly annoying as we have to quickly scramble to restyle everything that we spent time working through before.
I have noticed that padding/margins have changed, all of the headers (H1,H2,…) seem to have changed making our content look clumsy and overly large. Is there a way to more gracefully update these changes?
– Marc
-
There have been a number of UI updates in the past year, ironically reducing many font sizes and paddings (I imagine that you had compacted things, as had I though I don't use SaaS).
I never trusted those .gxw-ltr-123789 classes, so I didn't bind to them but I've still got dinged because I had a bunch of long selectors (to increase my specificity & compete with some builtin styles) which broke because VertiGIS (or maybe React upstream, IDK) removed a bunch of extra levels of HTML nesting, which is probably a good thing. I also got dinged on some styling I had for form Item Pickers which changed to lis from nested divs (definitely a good thing).
Where I'm at right now with what I've learned licking those wounds, I'm sure you've had some similar thoughts yourself:
- Layout component IDs are very stable, everything else is subject to change. So, I use a lot of
[data-layout-id="map-config-1"]{}in my CSS now. The container divs have been marked with a “data-layout-id” attribute for some time which binds to the ID of the layout component and can always be bound to using CSS. This has been my go-to selector for about a year now, but again it only gets you to the container element and you may need to bind beneath it. - I avoid binding to children of container elements when possible, but that's often not possible. As mentioned, the HTML structure of VS Web Components and WF Form Elements have changed and presumably remain subject to change.
- K.I.S.S. This is already something I am working on with my CSS, trying to keep what I write legible and rendering quickly etc. Make your selectors as short and specific as possible. To that end, I have been doing what is probably bad practice lately to cheat my way to specificity using :not() when some VS Web components get an HTML update, e.g.
:not(#fake-id) [data-layout-id="map-config-1"] {…. This gives me a lot of specificity when I need to compete with a long builtin style and I don't need to maintain an element id to do it. - Also, organization. I used to put CSS snippets wherever they were convenient, but no longer. Everything goes in one WF now. It runs on app startup and includes everything that might get used in the app. Every rule is commented with a description of what it selects, so if every class and ID in the app changed I'd be able to go through my CSS line-by-line and rebind my rules without thinking too hard (ideally).
I'd love to hear input from other folks who've written a bunch of CSS on how y'all do it. If anyone in the VS team can shed light on what's safe or recommended to use as a CSS selector, I'd love a little more clarity there too. I don't imagine we'll see locking down the HTML structure of VSW components, but maybe we can rely on certain classes or attributes that are more stable?
This only answers half your question Marc but as you can tell I have burned an hour or two on the issue myself & I would take some guidance wherever I can find it.
0 - Layout component IDs are very stable, everything else is subject to change. So, I use a lot of
-
Great question. I have also burned time on this. I am by no means a CSS expert, though I certainly prescribe to the KISS principle.
I discovered (and this is not an endorsement) there are several Chrome plugins like this one: CSS Selector Helper that can help in this regard.
For example, this is what you might see when inspecting a form element:
Note how I can see in a hierarchy the elements that might affect this specific element. This helps me built a CSS selector.
1 -
Another trick to get to the selector in Chrome is with a right-click in the Developer Tools (Ctrl + Shift + I) --- no plugin required. Use the element selector
to help find the element in question. On the Elements tab of the Developer Tools, as you hover your mouse over the text a popup will open over the element in the page with some details of the element. If you right-click on the text and go to Copy > Copy selector, the selector will get copied to your clipboard. Not sure this answers your question, but it's a trick that might be helpful.
Here is what was copied to my clipboard in the picture below:
#gcx-search-button-search-config-1 > span.MuiButton-startIcon.MuiButton-iconSizeSmall.gxw-ltr-16rzsu1 > svg
1 -
Thanks for the responses, all.
While I know how to find the css selector tags currently in a viewer, the problem is that they seem to change with updates to the viewer at times causing my custom css to break. I understand that this is a challenge from the VertiGIS side as it may be hard to implement changes without breaking some classes and ids. The main rub point is that we have to respond to breaking display in production tools fast and often on an unknown schedule. If there was a way to peg a viewer to a version in the SaaS viewers and allow for us to upgrade deliberately after having tested and updated anything that needs to be updated that would be helpful.
– Marc
3 -
Hi, I agree completely with Marc's request to be able to stay on an existing version of Web in SaaS before upgrading deliberately after thorough testing and updating of any customized elements. The current situation has proved problematical for us in the past, with broken components but very limited developer time available at short notice. This has caused some significant user frustration which has impacted positive uptake of the product.
1 -
Couldn't agree more with Marc's request here. If the components can be bedded down with each release, that would make things a whole lot easier. I guess we're lucky enough to not be using the SaaS version, but in any case, it's still an issue, as we too, preload a bunch of CSS on startup. Checking for changes post upgrade is not ideal at all.
0
Please sign in to leave a comment.
Comments
6 comments