Tailwind - a CSS framework as if made for TW !

[Mat]

@Jermolene, @TElmiger and everyone else

Tailwind is a CSS "utility framework". It has no components because it is designed to be hackable and simple. I've only briefly looked at it... but it seems perfect for TW. I believe it would to a large extent free the user from having to go into the stylesheets!

Here's a presentation on Tachyons which is very a similar framework (and the one that Thomas used for Bricks.) If I understand, Tailwind is more powerful and generic (and has also become more popular).

The presentation early on states that you will HATE Tachyons/Tailwind. It seems to go against some basic rules and it looks ugly.

...but please look more and think about it from a TW perspective. I believe it would...:

• remove the black box problem where it is not clear what a style does without digging into the stylesheets (...often in multiple places).
• make creating selectors super simple!
• make styling be a part of TW hacking instead of a separate world. (Be open minded!)
• help to avoid inline styling and bad CSS practice.
• minimize CSS conflicts/surprises
• basically free the user from having to know/learn CSS! 

This short article (again on Tachyons, but it's very similar) illustrates the dramatic consequences. I believe Tailwind is a bit more generic.

Here is one of Tailwinds key developers describing different approaches to CSS.

Github.

It is very tiddlyesque too... it splits up styling into the smallest meaningful units and the user weaves them together into larger narratives... In fact, I believe the Tailwind approach would even itself be enhanced in a TW environment where the user decides if he wants to make abstractions by means of local macros.

Please take a serious look. Several thousands of people are apparently already convinced.

<:-)

[PMario]

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. ... Guess what: Users did find it difficult, because it's a little bit abstract.

TW5 introduced more possibilities. ... 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? ... 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

[Mat]

PMario, thanks for great input!

TLDR;

The concept of utility classes is worth considering for TW.

Good you agree; Introducing utility classes was the main point!

I won't delve into the details of your reply because we actually agree. I also don't think we'd need an extensive framework for this BUT I do think it could save us a lot of work if we find a suitable one - but more than anything we might not do it ourselves if we're supposed to do it from scratch.

Just one note; you're a bit unfair when you complain that we don't want to use "vue.js or react.js or angular.js or <you name it>.js" because that is the video presenters exact point: Use your own environment, in our case tw. And they make this point when they talk about avoiding repeated text which is a macrolishiously simple matter in TW.

Your reply makes me realize we should first discuss what it is we want with CSS in TW. I'll start a thread.

<:-)

[Jeremy Ruston]

Hi Mat,

Just to say that I share your enthusiasm for moving towards our default themes being based on re-using existing CSS frameworks. Tailwind looks great, and tries to address many concerns that are familiar to us. However, frameworks like Tailwind go so far beyond what is possible with CSS that they are all based on tools that extend and enflex CSS: SCSS, Less, etc. In the case of Tailwind the dependencies are unfamiliar to me but seem to include an interesting looking mechanism for manipulating CSS within JS. Meanwhile, TW5 itself already incorporates the important functionality of those CSS frameworks (e.g. making it possible to use maths operators to compute dimensions).

The essence of TW5's internal design is to reuse the same wikification mechanism for everything, and so I don't want to bring into the core an alternative mechanism that duplicates what we can do with wikification. So, I think the approach we'd have to take is to take a static snapshot of the output of the framework and then use automated tooling to transform it into something that TW can process. The idea would be to move from specifying parameters at the time the Tailwind framework is built to doing it dynamically via wikitext constructions.

It's the kind of thing I'd like to address for v5.2.x

Best wishes

Jeremy

--

Jeremy Ruston

jer...@jermolene.com

https://jermolene.com

On 26 Aug 2019, at 18:59, Mat <matia...@gmail.com> wrote:



--
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 tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/8335ab0d-b26d-43fb-a0a1-6d73d3d884e5%40googlegroups.com.

[Thomas Elmiger]

Hi Mat, Jeremy and Mario,

Thanks for thinking of me, Mat, and my usage of tachyons elements in my Bricks studio. 

The reasons why I (only) adapted selected parts of tachyons (typography, spacing/measures, some colours, ...) are:

• I like the simple and useful design concept (as a starting point).
  
• I basically agree with what Mario says.
• TiddlyWiki can already do magic stuff (variables, calculations – JavaScript in CSS –, theme-tweaks, palettes, ...).
  

Some things that are difficult in standard TW and that I tried to improve in Bricks:

• Find the right spot in the existing CSS to change.
  
• So I transformed it into a collection of specialised small CSS documents.
  
• Colour calculations, e.g. to blend or invert colours or to check contrast (accessibility).
• My ambition was: Enable users to choose some base colours, and then calculate everything else automagically. That turned out to be incredibly hard.
• Still I think my ColorAction plugin is great and the Colour Manager points in the right direction (it allows to define/calculate colours based on other colour variables – and still see them, a big improvement compared to the standard palette manager).
  
• Use different colour schemes for content and sidebar (e.g. dark sidebar, light background for content)
• I hacked a way around this but it was a long and hard process.
  
• Save computing power: With TWs flexibility, the more variables you have the more complex calculations are needed to render the design.
  
• So I implemented a simple "compiler" that renders one big stylesheet without any variables. I can use this "frozen" version to publish faster wikis.
• Adjust spacing to follow a system (margins, paddings, whitespace around headings, ...)
• This is where my tachyons-based variables were extremely helpful.

So features like these would be more important for me, than what/if any framework is used. As long as there is a solid concept that goes through all of TW and is easily adaptable (using far less parameters than the ControlPanel offers today) I would actually not care, where it is derived from.

All the best,

Thomas

[Arlen Beiler]

This is why I want the autoparagraph feature GONE! Ok, whatever, maybe that won't happen right away, but we'll get somewhere close eventually. I love the idea of adding parameters to the mime type. I didn't even know that was a thing before today. 

But this is a good read (the article from the original post): https://adamwathan.me/css-utility-classes-and-separation-of-concerns/

I think we should consider that idea, or perhaps an alternate idea that I got from react native where styles are kept near the elements they style. So for instance every template tiddler would have a stylesheet tiddler and use a variation of the qualify macro to return the class names to use for those styles, and also add those classes to the global stylesheet whenever the tiddler is rendered, probably using the same macro somehow, but still it would be unique based on the position in the widget tree. The styles could be defined using a macro as well, I believe. That would probably be easier. But I don't quite know how to get the styles into the global stylesheet. Maybe we need to have a style widget that just sticks in a style tag with its unique class names right there. 

--

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 tiddlywikide...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/507dced0-8a53-42a7-970c-fa7beb88177e%40googlegroups.com.

[Arlen Beiler]

I'm Shocked! It Worked!

\define class(suffix) $(classprefix)$$suffix$
\define css()
.$(classprefix)$align {
  text-align:right;
}
\end
<$set name="classprefix" value=<<qualify "Test1">>>
<style><$text text=<<css>>/></style>
<p class=<<class "align">>>Hello world</p>
</$set>

[TonyM]

Arlen

This looks promising because scoping css to a specific tiddler or set of tiddlers rather than the page is critical. So often in tiddlywiki we are thinking with a tiddler focus not a whole of html file css, except with themes which are by definition whole of wiki. It makes me ask if we could have one or more tiddler themes.

We know html and css are partners in crime so I would like to see more thought about structures within tiddlers that we provide the classes to enhance with. An example may be tiddler layouts with supporting css that allows the tiddlers to be targeted.

Perhaps we can choose a single other framework for flex boxs etc... And build the css to support that.

Regards
Tony

[@TiddlyTweeter]

Would this approach HELP SEE TW CSS?

I think the single biggest issue is seeing what is happening.

TT

[Arlen Beiler]

I think for the UI we should have scoped classes. In other words, instead of setting the classprefix using the quaify macro, we would just set it directly to "tc-sidebar-", "tc-topbar-", "tc-page-header-" for instance and then within that each component would have its own class and the CSS would be in the themes, but it would be written so that each known section would have its own section in the theme and be very easy to find and modify. The class names are already basically setup that way, but the CSS definitely is not! We could add a section to the tiddler edit mode which would add a text field for the stylesheet that relates to that template tiddler, perhaps based on a tag such as $:/tags/themed-template and a field specifying the classprefix. I believe this is already a feature of the edit template, so it could be easily done without modifying anything besides the theme and adding the tags and fields to the right tiddlers. The theme stylesheet would then pull all the themed templates' stylesheets into one generated stylesheet. The stylesheets would be shadow tiddlers from the theme and would be named according to the classprefix. With that in place it would make ton of things a whole lot easier, I think. 

This is just me brainstorming a random idea that I see in my head. I haven't even thought about it before. So I may be missing some other pieces of the puzzle, but these are my ideas. 

I do agree that the whole thing would be a lot easier to do with flex, and I think that may be a step in the right direction, but block and inline-block still work excellent with a little extra fiddling. 

Arlen

--
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 tiddlywikide...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/8498ff57-f699-4b73-9f42-c88bdbf4dffe%40googlegroups.com.

[@TiddlyTweeter]

Ciao Arlen

I am not good on what some of the technical terms you use mean, but this got my attention ...

so that each known section would have its own section in the theme and be very easy to find and modify.

RIGHT. From my point of view understanding right now TW CSS looks far more complicated than it could be. 

My impression of TW CSS is it is far more logical than most web sites already. That has to do with its fundamental architecture. Please don't loose that fact.

Any solution IMO should leverage off that.

From point of view of an end-user like me I just want a better way to understand WHAT to change WHEN and what the "nested scope" is.

TT