Hi Mat,
TLDR;
*The concept of utility classes is worth considering for TW.* For the rest:
There is nothing new. TW allows us to use this workflow, with 2 exceptions:
- We don't need additional build steps.
- We don't need 80+ MByte 3rd,4th...10th... party dependencies. TW is
self-contained!
TW can and does already build its CSS dynamically. The only thing we would
need, is 400k of additional CSS definitions (watch the videos).
I doubt, we want that.
--------------------
I did have a closer look and also watched most of the documentation videos.
... I think you like it, because the TW concept is very similar, with 1 BIG
difference:
- Tailwind is for *developers* ... TiddlyWiki is for *users*
The concept doesn't go far enough for us. ... The only thing it does, it
provides some naming conventions.
The backside of the coin is:
- The default CSS is ~400 kByte as shown in 1 of the videos
- They try to solve this problem with an other post-processing step
named:
CSS-purge, which removes unused CSS definitions and introduces other
dependencies.
- Purging the CSS is not possible with TW, because it's not the
developer, that uses the CSS: ___It's the end-user___
TW always has to have ALL the definitions.
- As soon as duplication of utility classes starts, they try to combine
them, using a mechanism that is standard:
- They define a new class. ....
The problem is: They use alien syntax, which needs a build step.
The first doc videos all work with very small HTML files, similar to 1
tiddler ... As soon as they start to do "real work" they need to introduce
a template engine. ... VUE.JS ... To do something we use for years. ...
TiddlyWiki and the list widget using a templates
We have tiddlywiki.js we don't want vue.js or react.js or angular.js or
<you name it>.js
The utility class names can be freely assigned. ... And that's absolutely
necessary, because "text-indigo-500" is only useful to convince others,
because it's easy to understand, but not practical for production use. In
other words: It's absolute nonsense.
eg: What if I want to define the color green and not indigo. I would need
to search and replace all the class names. OR I just *change the color
value to "shades of green" and let the class-name alone*. ... Which is the
intention of a framework!!!
On the other hand, this is the absolute horror, since naming green as
indigo ... you know what I want to say!
.... I could go on here stripping apart every 10 seconds of the videos. ...
BUT I don't want to.
*In short: It's worth considering the mechanism, because we already can.*
-----------------------
For TW use we would need to name colors as: primary, secondary, tertiary
... and so on. ... see TiddlyWiki classic ColorPalette
<https://classic.tiddlywiki.com/#ColorPalette>. ... Guess what: Users did
find it difficult, because it's a little bit abstract.
TW5 introduced more possibilities
<https://tiddlywiki.com/#%24%3A%2FPaletteManager:%24%3A%2FPaletteManager%20%24%3A%2Fpalettes%2FVanilla>.
... Guess what: Users find it difficult ... because it is ;) -> OK we
should and could improve the $:/PaletteManager with the possibility to show
examples.
Are we able to tweak the overall layout
<https://tiddlywiki.com/#%24%3A%2Fthemes%2Ftiddlywiki%2Fvanilla%2Fthemetweaks>?
... yes ... does it dynamically change CSS settings. ... hell yes.
Is it user friendly. ... probably not, since they don't find it on their
own.
Do we miss possibilities to user-define buttons, tabs, lists and other
existing design elements. ... *yes*
Should we consider to implement utility-classes for them ... *yes*
Do we need naming convetions for that: ... *yes*
Do we need an external framework to achieve that: ... *no*
have fun!
mario
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/81422698-3e7d-4ea4-8f24-691a1dc3fb2d%40googlegroups.com.
