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>
On Tue, Aug 27, 2019 at 10:29 PM Arlen Beiler <arlen...@gmail.com> 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 <thomas.elmi...@gmail.com>
> 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 <https://tid.li/tw5/test/bricks.html#Colour%20Manager>
>> 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
>> <https://groups.google.com/d/msgid/tiddlywikidev/507dced0-8a53-42a7-970c-fa7beb88177e%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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.
