I'm keeping a running list of features/functionality that are currently available in API v1. Would love to get them incorporated in Spark.
Please feel free to add to the list.
- Custom CSS in design system and/or skuid pages
- Form option to display field labels next to field (vs. above)
- Form collapsible section headers
- Required field red border? Cant find any styling for the required fields
- Table row edit? Is table limited to inline only?
Nice to have in Spark Design System
- Min/Max widths on components (button for example)
- Style for form section headers
Thanks for starting a list! We'd love to hear from others as well if they've noticed anything missing. We’ve tried really hard to make sure we have feature parity between our V1 and V2 (Spark) components, but inevitably we knew we’d miss a couple since Skuid is such a large and feature rich product.
Some of the things you mentioned were actually conscious design choices, and I’m going to do my best to explain why we made these choices or established these constraints. I’ve acknowledge a few thing that I’ll write down, but this does not guarantee any specific timeline.
Custom CSS in design system and/or skuid pages
This was probably the biggest and furthest reaching choice we made, but this is intentional. We spent a lot of time talking through and debating this, but ultimately the pros of not supporting custom CSS greatly outweigh the cons.
We always have and always will want Skuid to be an extensible product. However, even above that, we want Skuid to be a stable product. In order to have a stable and extensible product we had to make some hard calls about the points at which our product is extensible. In our V1 components we have always supported custom CSS targeting any element on the page. However, leaving CSS open ended has meant that we cannot change the DOM structure of our components without introducing huge risks in breaking currently implemented custom CSS during upgrades. It’s hard to overstate how much custom CSS has created friction for upgrades and inhibited our development of new features or fixes for bugs.
That being said, we’re really excited about how applying some contraints the scope of extension points in V2 sets us up for the future to focus and flesh those points that we’ve decided upon. We’re working hard to make custom component creation much more developer friendly as well as looking into a successor for custom field renderers (which will occupy the same role but probably be called something different).
Form option to display field labels next to field (vs. above)
We did this because because of accessibility and usability concerns. To quote from this sitepoint article the disadvantages of labels beside fields:
On small screens, when focus is in-field, label may not be visible (because of zoom).
User is unlikely to be able to see the label and the field within one glance.
When form is translated into other languages, labels may no longer fit into allocated space.
Form is wider compared to having labels above fields.
Labels may be far away from their corresponding fields, so it can be hard to see which goes with which (zebra striping can help to minimise this issue).
Lastly, one that they didn’t mention is that users utilizing a screen magnifier due to visual impairment or other reasons will suffer the same fate as small screen users; the label and the field may not be visible simultaneously.
If you’d like to provide feedback on use cases where labels beside fields is better though, we’re all ears.
Form collapsible section headers
Good catch. I’ll write it down.
Required field red border? Cant find any styling for the required fields
I’ll write it down. It’s worth noting though that having solely a color indication for required fields can provide trouble to users who cannot distinguish colors, so if we do add support for styling the borders of required fields, we most likely will still enforce a symbolic/written indication of the fields level of requirement.
Table row edit? Is table limited to inline only?
Yes. However, you can navigate the table fully using the arrow keys, space, enter, and escape now, so hopefully the need for table row edit has been reduced.
Min/Max widths on components (button for example)
Do you have specific use cases with this? I think I see where you’re going with it but I’m curious.
Style for form section headers
It’s there. Open the DSS -> Component -> Form. Then in the form properties on the right Nested Components -> Section header
I am not using Spark yet, but was one of the early Lightning movers - so we are using a custom Lightning based theme (copied from the Skuid lightning theme.) I took a look at the custom CSS on my theme, and it was all to fill gaps in the original Lightning theme:
- The navigation component lacked any CSS or styling, with no way to adjust in the theme builder
- Boolean checkboxes show large in some browsers, causing fields to mis-align
- Tables with required fields in edit mode lacked the red border so the user had no way of knowing the field was required
- The Date picker was cut off (width) and the user couldn't see the whole month
- Field editor picklists drop down elements didn't match (text, background)
I believe most if not all have since been fixed in patch releases, and if I was more proactive I would have gone back and confirmed and removed the custom css. But my point is I was able to resolve the issue with a few lines of CSS that applied instantly to 100s of skuid pages and not have to live with it until a patch fix was released.
PS - I'd also like a button width controller. Many times I have stuck a button in a grid just to control its width.
Form collapsible section headers
Could just include the form inside an accordion, disable section header from the form, and add it to the accordion header. I've been using this structure way more than the version 1 Field Editor's ability to collapse sections (since you can collapse entire component sets).
Just as a heads up, the Accordion & Form section header are by default set as different font sizes. Not sure if your variants can affect this though
Also- I third the css issues above in regards to having to bridge the gap to lightning layouts. And being able to limit button widths.