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:
(start quote)
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
