This site collects together pure HTML+CSS implementations of buttons, checkboxes, loaders and other basic UI elements. They are straightforward to reuse in TiddlyWiki but no doubt there is scope to make a plugin that encapsulates the implementations neatly for reuse.
Some of the designs are utilitarian, but some are much more elaborate. For example, this toggle button is entirely constructed from CSS gradients, with no images:
I Agree that would be good but one advantage of this resource is access elements as needed. All we need todo it provide some instructions;
From this example Input by adamgiebl
.input-wrapper input {
background-color: #eee;
border: none;
padding: 1rem;
font-size: 1rem;
width: 13em;
border-radius: 1rem;
color: lightcoral;
-webkit-box-shadow: 0 0.4rem #dfd9d9;
box-shadow: 0 0.4rem #dfd9d9;
cursor: pointer;
}.input-wrapper input:focus {
outline-color: lightcoral;
}
Then in the tiddler where you want it the html given is;
<div class="input-wrapper">
<input class="input" name="text" placeholder="Type here..." type="text">
</div>
But instead you need to use the TiddlyWiki way
<div class="input-wrapper">
<$edit-text tiddler="AppSettings" field="myconfig" placeholder="input here..."/><p/>
Value of ''myconfig'' : {{AppSettings!!myconfig}}
</div>
Great stuff @jeremyruston
Thank you!
I found the css variables quite powerful to be used in TiddlyWiki. There is a small issue with -- in TiddlyWiki when you use them in tiddler of type text/vnd.tiddlywiki, but seems the pragma \rules except dash helps to resolve this issue.
What do you think about open-props I see it is very small and powerful
I found the css variables quite powerful to be used in TiddlyWiki. There is a small issue with
--in TiddlyWiki when you use them in tiddler of typetext/vnd.tiddlywiki, but seems the pragma\rules except dashhelps to resolve this issue.
It is more robust to use \rules only to specify precisely which parser rules are required; otherwise any future parse rules that are introduced will automatically be enabled, possibly leading to unexpected results. The core uses the following rule to allow macros and transclusions:
\rules only filteredtranscludeinline transcludeinline macrodef macrocallinline macrocallblock
Very interesting. New ways of encapsulating functionality are always welcome. Something I don’t like so much is that using it efficiently relies on a bundler process of some kind (developers wouldn’t usually want the overhead of setting up all the available CSS variables).
In some areas, it is opinionated without being customisable. For example, there is a fixed set of gradient designs built-in (numbered from 0 to30, with no meaningful names). The colours, angles etc are all fixed for each design. If you take that particular example, it seems to make more sense to me to use an interactive gradient designer rather than relying on such a small canned set.
Another area that I don’t quite understand is the need to name font sizes as indexes from 00 through 0 to 8. The actual sizes corresponding to those indexes are fixed which seems strange; the usual reason for referring to things by name is so that access can be indirected.
Thank you for clarification Jeremy!
Absolutely agree! Very useful to see. Very easy to use and make one’s own.
Thankyou, TT