Any answers here? This is a big + important question!

If you are working in lighting, a workaround is to include a blank v1 page with custom CSS on your lightning page and style the components in your v2 page. 

Ah! Fascinating, I’ll try that. Thanks!

Jack, Samuel, Josef - I don’t know about roadmap, but can you give some of your top reasons for needing CSS? That’ll help us give some context to the product team. Thanks!

Due to the architecture of v2 (specifically the fact that it uses generated class names), any custom CSS targeting an element generated by Skuid will break in subsequent releases, major or minor.

We are, however, continually working to provide a better code-friendly developer experience in general, one with more clearly defined API endpoints, more streamlined custom component development, and a v2 rendition of custom field renderers. Essentially, exposing more of the things that make Skuid powerful to customer developers in a meaningful way. This work is part of the roadmap, but I don’t have any specific timelines.

The use case is that designers are constantly coming up with new ways of handling visual elements.  At the same time, Skuid will always be a work in progress introducing innovations and trying to keep up with the rapid pace of change in application experience expectations.  Developers are looking for ways to minimize the inevitable gap between these two threads.  

The generated class names is a brilliant architecture, but the design system can’t possibly handle all of the styling requirements that different designers come up with.  Their job, after all, is to create new experiences.  

With this said, style extensions belong in the DSS and incorporated into the generated classes, rather than embedded in CSS targeting elements in the browser.  With this approach, Skuid should have the flexibility of adjusting the DOM structure without worrying about blowing up customer solutions.  This leads to accelerated innovation and happier customer experiences in the long term.

Here’s a link to an idea post from a while ago on this topic:

https://community.skuid.com/t/styling-in-spark

Just to clarify, when I say “the design system can’t possibly handle all of the styling requirements”, what I mean is that trying to anticipate every style tag is a pretty impossible task.  Providing extension capability is more scalable.