custom css in design system?

  • 2
  • Question
  • Updated 2 months ago
Is it on the roadmap to allow custom css to be added to pages, or to a design system as a whole in api v2?
Photo of Jack Sanford

Jack Sanford, Champion

  • 10,090 Points 10k badge 2x thumb

Posted 10 months ago

  • 2
Photo of Samuel Cohen

Samuel Cohen

  • 392 Points 250 badge 2x thumb
Any answers here? This is a big + important question!
Photo of Josef Lagorio

Josef Lagorio

  • 3,394 Points 3k badge 2x thumb
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. 
Photo of Samuel Cohen

Samuel Cohen

  • 392 Points 250 badge 2x thumb
Ah! Fascinating, I'll try that. Thanks!
Photo of Matt Brown

Matt Brown, Product Manager

  • 1,986 Points 1k badge 2x thumb
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!
Photo of Andrew Duensing

Andrew Duensing, Software Engineer (Technical Lead)

  • 410 Points 250 badge 2x thumb
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.
Photo of John Dahlberg

John Dahlberg, Champion

  • 4,610 Points 4k badge 2x thumb
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/skuid/topics/styling-in-spark
Photo of John Dahlberg

John Dahlberg, Champion

  • 4,610 Points 4k badge 2x thumb
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.