I would like to propose adding a style property to the design panel of every component, such that we can modify any css attribute in-line, not only a select few present in the designer.
While we can modify any css attribute via Roles, I often find myself wanting to tweak just one specific button, image, etc., and it gets a tad annoying having to create a whole new Role that you would only use for one instance of a component. Moreover, the role dropdown list gets quite cluttered with this approach.
Would it be an idea to have a generic style property for each component where you could just write the raw in-line style string and specify the values for an arbitrary selection of attributes? E.g. like in the example below:
If there are any conflicts between the values of attributes specified in this style property and those specified in the standalone properties (e.g, if background-color is specified both in the style property and the standalone background_color property), then whateverâs in the style property could take priority as it would likely be used by more advanced users.
It would allow developers much greater flexibility in applying style changes to individual instances of components, rather than having to create a new Role that may only be used once.
I like the idea, as long as somebody includes pointers to syntax and semantics of the entries.
Many folks come to Anvil because they donât know HTML, CSS, Javascript (and its myriad frameworks), etc.; donât want to know; and have no idea what search terms to use when looking for those things.
Take the existing border entry, for example. You can type almost anything in there, with no guidance whatsoever. Get anything even slightly wrong, and it will be ignored. Silently. Nothing to tell you what went wrong. Nothing to learn from. Anvilâs documentation assumes that you already know what belongs in these fields, what works, what doesnât, whatâs safe, what isnât.
To be effective, this style field will have to be different. It doesnât have to repeat existing documentation, but it will have to point to current, accurate documentation of its allowable contents, preferably aimed not at CSS experts, but at Anvilâs most common developers.
Hey Phil, Iâm not sure I completely understood your argument.
I feel like even now if someone wants to do more specific styling modifications they have to delve at least somewhat into CSS. For example I wouldnât know what to write in the border property unless I google it. Anvilâs docs just say âThe border of this component. Can take any valid CSS border value.â If you use Roles you also need to dive into CSS.
Yes, this property would be somewhat different in the sense that it doesnât take a single value, but the whole declaration block. But I think that this could be properly explained, and fairly straightforward to understand with some examples.
It could also be hidden behind an âadvancedâ dropdown / button click so as to not intimidate new users. There are solutions.
In the end, nobody would have to to use it any more so than they have to use Roles or Anvilâs other more âadvancedâ features. But it would give a lot more optionality when it comes to styling to those who need it.
I agree. Moreover, Anvil doesnât have to provide them, as long as it points to the proper documentation that has such examples.
Itâs the current lack of such pointers, in the current documentation, that rubs me the wrong way.
Absolutely. And I would love to have the chance to use a generalized style field, even in place of the current, piecemeal fields.
I simply note that if most current Anvil developers are to use stylesuccessfully, then such documentation pointers will be more necessary than they already are for border, due to styleâs much broader scope.
This would actually be an opportunity, for a clever CSS expert: design and build an Anvil App that can
translate a widgetâs CSS into terms a typical Anvil user can reasonably interpret, and
translate the other way, back into CSS, for filling into your style field.
That would actually be a great IDE feature, come to think of it. After all, the IDE has all the CSS context, the values that âcascadeâ on down to the widget, from its environment, and are not stated explicitly in the widgetâs (styleâs) CSS itself.
With practical help like that, I think that your style idea could really take off.
