Re: [twdev] Re: Tailwind - a CSS framework as if made for TW !

[@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

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b40d1892-bd1c-4865-9e0d-a73ccea9a6f4%40googlegroups.com.

Re: [twdev] Re: Tailwind - a CSS framework as if made for TW !

[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

On Wed, Aug 28, 2019 at 7:17 AM TonyM  wrote:

> 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
>
> --
> 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 tiddlywikidev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywikidev/8498ff57-f699-4b73-9f42-c88bdbf4dffe%40googlegroups.com
> .
>

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/CAJ1vdSR-FXNe_EpLGkYQK93wGuTkUOdM9zLNrXf3CupRCEFV9g%40mail.gmail.com.

Re: [twdev] Re: Tailwind - a CSS framework as if made for TW !

[@TiddlyTweeter]

Would this approach HELP SEE TW CSS?

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

TT

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/bd23bc29-228d-45da-b0c7-d455195b6c91%40googlegroups.com.

Re: [twdev] Re: Tailwind - a CSS framework as if made for TW !

[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

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/8498ff57-f699-4b73-9f42-c88bdbf4dffe%40googlegroups.com.

Re: [twdev] Re: Tailwind - a CSS framework as if made for TW !

[Arlen Beiler]

I'm Shocked! It Worked!

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


On Tue, Aug 27, 2019 at 10:29 PM Arlen Beiler  wrote:

> 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.
>
> On Tue, Aug 27, 2019 at 6:30 PM Thomas Elmiger 
> wrote:
>
>> 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
>>
>> --
>> 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 tiddlywikidev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/tiddlywikidev/507dced0-8a53-42a7-970c-fa7beb88177e%40googlegroups.com
>> 
>> .
>>
>

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/CAJ1vdSRVa2Uj6ZnPvjobeVObK6Czy86UO0AY4QDS5MR5iqOPcA%40mail.gmail.com.

Re: [twdev] Re: Tailwind - a CSS framework as if made for TW !

[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.

On Tue, Aug 27, 2019 at 6:30 PM Thomas Elmiger 
wrote:

> 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
>
> --
> 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 tiddlywikidev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywikidev/507dced0-8a53-42a7-970c-fa7beb88177e%40googlegroups.com
> 
> .
>

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/CAJ1vdSRXPpKDy7a3kqrm340y3%2BtC3wsZH4LLcsUNvZ%2B%3DzK9wYA%40mail.gmail.com.

[twdev] Re: Tailwind - a CSS framework as if made for TW !

[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

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/507dced0-8a53-42a7-970c-fa7beb88177e%40googlegroups.com.

Re: [twdev] Re: Tailwind - a CSS framework as if made for TW !

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

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/33B8B304-BA90-4250-8BB6-E4D3FF609FDE%40gmail.com.

[twdev] Re: Tailwind - a CSS framework as if made for TW !

[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 .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.


<:-)

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

[twdev] Re: Tailwind - a CSS framework as if made for TW !

[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 
.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

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/81422698-3e7d-4ea4-8f24-691a1dc3fb2d%40googlegroups.com.