After all these changes and improvements in the past, I decided to quickly build something to see what’s still missing for me in terms of CSS properties and possible restrictions of values.
Here are my points:
Clip-path property missing inside the Relative Styling options (for Div block). Wasn’t able to add the styling for the active menu state. Clip-path values are restricted to % which limits to specific designs. I have some use cases in mind which are not feasible currently.
Transitions are still very limited. Values only accept numbers, no option to define custom transition timing functions. Especially for the more animation-like cubic-bezier values, this is important in my builds (like for the menu items when triggering the overlay menu).
Flex order is not available. In my example, I want to change the order on mobile devices, so the menu is displayed above the contact details.
Align-self is also something which isn’t available yet. The contact headings required some custom CSS.
I am aware that for the last 2 aspects, other (already available) options would’ve done the job as well in this case, but that’s not the point here.
The demo was quickly thrown together, it’s all about how far I could get, focusing on available CSS block inspector possibilities.
With the last 2 updates (1.2.5.2 and 1.2.6) quite a few things in that regard got added which was another important step to a full no-code experience.
Yes, I agree with this stuff. While it’s easy enough to create custom CSS for those who know how, it would be nice if everything was accessible within the visual controls. On the flip side, there are A LOT of CSS properties that exist, so who knows how practical that is. I guess we’ll see.
What I would like to see is better use of variables throughout the builder. Here are some points regarding this:
For the Cwicly global colors, it would be nice to be able to set a color value the way we currently can, but also be able to set them with a variable. The use case would be if someone was using a CSS framework, they would be able to tap into the framework color system easier.
The Cwicly grid system now supports variables for gap, but when I use a variable, it collapses the visual grid builder thing (where it shows the purple grid boxes, lol, I don’t know what it’s called). So for now, the workaround is to add the gap via a custom class instead of a variable, or make sure the grid layout is set before adding the gap variables.
Lastly, this is more of an ongoing issue that’s not necessarily related to variables, but the gradient color picker should include access to the global colors, I would think. Right now you have to manually add color values, but ideally you would be able to choose a global color you have already defined.
I also think it would be good to revisit each of the existing blocks and add any missing pieces to them. Adding gap to the menu block is an example of something that is a big time saver. All in all, Cwicly is getting so good that it’s becoming harder and harder to find things to change!
I want to add that there is another important part which might be underestimated or not on the radar for everyone. It’s a way of managing and organizing the CSS. With full block inspector control, everything sits on its right spot. No more digging in code blocks, stylesheets or blocks’ specific CSS.
Of course, not everything should be added. Exotic stuff should be avoided, edge cases could be discussed - decisions made by user feedback.
I assume this will be the case as soon as the gradient colors received some love, which was already confirmed. Make sure to add your requirements.
Sure, why not. I think the best way is to give direct feedback if something is missing. Things might appear complete until someone finds out on specific use cases, they are not.
Always room for improvements but while I was building this menu example, I was pretty amazed of how things have changed.
For me, super detailed css option are not very important. (as first I don’t use them very often and second are easy to add them in a stylesheet). Just the basics (mostly layout related) are more then enough to speed up development.
The most benefits I see from a no-code solution is on the logic side of things, dynamic data, queries, filters, modals etc. as those really cut the development time as opposed to do them manually.
We already have them in cwicly, but would like to see them even more extended.
The basic idea here was to create something which is a bit more advanced than the standard layouts and see where I get stuck, when it comes to CSS properties and values.
Of course, this isn’t representative. That’s why I took it under the general instead of the feedback category. It’s a specific use case, so kind of random.
There is the interaction part, which I left aside purposely.
Things like keyboard support to close the menu or manipulating attributes other than classes will be necessary at some point.
But, I won’t disagree with your points. This is the part which becomes more and more prominent and important nowadays and Cwicly already does a super job in that regard.
