Meaning of 5 , 1 , 19 ?

[Mat]

What does it take to jump "a tenth" in the version number, i.e to get TW version 5.2? Seems like we over modestly increment with 1/1000 even when pretty big improvements are made.

More generally put, what do the value positions in 5.1.19 actually signify in TW - there is no exact standard for versioning? And actually, is "5" a version number or a part of the product name?

<:-)

[PMario]

Hi Mat,

TW uses "semantic versioning" ... kind of ... see: https://tiddlywiki.com/#TiddlyWiki5%20Versioning ... BUT TW is special.

Since backwards compatibility is a main goal, the 5 will probably never change. 

5.0.x ... have been beta versions.

5.1.0 ... has been the first "production" version.

TWclassic is 2.9.2 ... where 2 will probably stay for ever.

-m

[Mat]

PMario - thanks, I was not aware of that tiddler about versioning!

So, in "major.minor.patch" I take it the 5 is the major. But  - and I guess I'm talking to @Jermolene now -  it seems to me that we're only increasing the "patch" number in spite of the absolute majority of the updates being "minor".  Not that it's a huge deal, but it just seems overly cautious and, at least for me, there is some kind of psychological effect to it that makes things feel slower than they are... plus it probably signals to newcomers that big improvements are rarely made, which is just not true.

<:-)

[MidnightLightning]

There's a conversation over at https://github.com/Jermolene/TiddlyWiki5/issues/3834 on the GitHub repo that asks a pretty similar question too.

[Arlen Beiler]

I've always read it to be brand:major:minor, as the "5" signifies the upgrade from "2", using many lessons learned, and is a play on the number 25, which was in the original slogan (TWenty 5 - A remake for the next 25 years). The middle number is major changes to the internal javascript code, such as a major rewrite of boot.js, which might break certain things like Bob and TiddlyServer (tools which depend on the internal workings of TiddlyWiki), and the last number is the number that tells us which bugs we might be dealing with and which macros and features are available. We don't really do patch, but we also don't really do breaking minor changes. All 5.1.x wikitext will always work on 5.1.x, and might work on 5.2.x as well, since breaking changes are rarely introduced into the parser. 

That's how it's seemed to work from my observation.

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 post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/023ddcbf-6f5c-4f95-aa19-8b7f442d4feb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Ruston]

Hi Arlen

That’s great! I hadn’t seen the “25” connection, but otherwise that reflects my thinking.

As it happens, I have been wondering recently if enabling duplicates within filters might not be exactly the sort of change that warrants moving to 5.2.x:

https://github.com/Jermolene/TiddlyWiki5/pull/3790

And, of course, if we decide to make 5.2.x then there’s a natural opportunity to consider some other improvements that are not 100% backwards compatible. For example:

* Changing the HTML storage format to embedded JSON to remove restrictions on field names (and make the HTML valid)

* Adopting a new .tid file format that allows for fields containing new lines

* Fixing timezone handling

* Switching off CamelCase by default

* Replacing Vanilla and Snow White themes with something based on a higher quality, off-the-shelf CSS library

* Updating to a later dialect of JavaScript (arrow functions! Promises! — although I think that being conservative in our JS requirements has been very good for TW5)

* Refactoring boot.js to be less monolithic

Best wishes

Jeremy

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/CAJ1vdSRnsqgP8fkZaAUW%3DZD-uOCOk3u4KGgg9wo%2BzCwOpBwu9g%40mail.gmail.com.

[@TiddlyTweeter]

Footnote from Italy 😀

I think that better Css would really help (get greater uptake) ... I mean it's "look" that initially grabs most users--savant or not, I think?

Best wishes
Josiah.

[Mat]

Jeremy Ruston wrote:

As it happens, I have been wondering recently if enabling duplicates within filters might not be exactly the sort of change that warrants moving to 5.2.x:

@Jermolene - a suggestion:

If I understand things right, the dupes issue is holding back the new math operators which consequentially holds back the release of 5.1.20. Might an idea be to postpone the math ops to get a release of 5.1.20? I'm screaming "nooo" inside but I understand the dilemma and 5.1.20 is already late as it is plus the prerelease still has some really useful new stuff.

Then head for a super exciting 5.2.x by starting with a discussion and collecting suggestions. It is a rare opportunity and it would be really unfortunate if great ideas miss out and have to wait for yet another backwards-incompatible moment, possibly many years away. BTW, there are already a few things listed in an old roadmap that I'm not sure are in the backwards breaking list mentioned in this thread but that still would be very useful.

In reply to @TiddlyTweeters footnote; I also think CSS is one of the areas that need more love. IMO we see very little variations in TW appearences. IMO, CSS is a kind of poor mans coding to affect how things appear so I suspect the big JS-boys here don't fully appreciate this need for us non-JS mortals.

<:-)

[Jeremy Ruston]

Hi Mat

If I understand things right, the dupes issue is holding back the new math operators which consequentially holds back the release of 5.1.20. Might an idea be to postpone the math ops to get a release of 5.1.20? I'm screaming "nooo" inside but I understand the dilemma and 5.1.20 is already late as it is plus the prerelease still has some really useful new stuff.

I’ve also been thinking that we should postpone the maths operators until we implement change the filter duplicates behaviour. Otherwise, documenting how to safely use the maths operators will be extremely hard.

Then head for a super exciting 5.2.x by starting with a discussion and collecting suggestions. It is a rare opportunity and it would be really unfortunate if great ideas miss out and have to wait for yet another backwards-incompatible moment, possibly many years away. BTW, there are already a few things listed in an old roadmap that I'm not sure are in the backwards breaking list mentioned in this thread but that still would be very useful.

Yes, with the proviso that there’s some tension between the speedy release of 5.2.x and the number of features we attempt to add.

In reply to @TiddlyTweeters footnote; I also think CSS is one of the areas that need more love. IMO we see very little variations in TW appearences. IMO, CSS is a kind of poor mans coding to affect how things appear so I suspect the big JS-boys here don't fully appreciate this need for us non-JS mortals.

I took Josiah to be expressing agreement with my suggestion of replacing Vanilla and Snow White with an off-the-shelf CSS framework.

What exactly is the need that isn’t being recognised?

Best wishes

Jeremy.

<:-)

--
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 post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/c50d2de9-17be-498f-8809-4c229c6d9a49%40googlegroups.com.

[Arlen Beiler]

Ouch, I'm sorry! I didn't mean to be so condescending!!!!!!!! 😀😀😀

Just kidding, of course!!! 

From my perspective, I always find myself very lost when I need to decide how a webpage should look. On the other hand, if you gave me a sufficient number of example pictures covering every aspect of the HTML and Community standard, I know that I could definitely write the HTML/CSS needed to make it look exactly like that. I could even write the TiddlyWiki templates needed with sufficient help from the WikiText gurus on this forum. I can make it look however you want it to look, but I definitely don't know what it should look like. 

But that's just me. I know not everyone is that lost when it comes to design. Jeremy seems to have a pretty good eye for it. As do a few others around here. 

That being said I recently tried to make a new theme based on Material Design. It looks half decent but it's not completely done. I just uploaded it to my github page so it should show up in the next 24 hours (you know how that goes) https://arlen22.github.io/material.htm. I had to make some changes to the core code which I'm currently trying to get merged.

Arlen

[Mat]

Jeremy Ruston wrote:

In reply to @TiddlyTweeters footnote; I also think CSS is one of the areas that need more love. IMO we see very little variations in TW appearences. IMO, CSS is a kind of poor mans coding to affect how things appear so I suspect the big JS-boys here don't fully appreciate this need for us non-JS mortals.

I took Josiah to be expressing agreement with my suggestion of replacing Vanilla and Snow White with an off-the-shelf CSS framework. 

Aha! That would be great! 

What exactly is the need that isn’t being recognised?

Thanks for asking. I'm referring to that CSS is relatively simple to learn at a rudimentary level but still pretty powerful - but that TW is not really set up for manipulating css easily. Here are a few things that would make working with CSS simpler and many are kind of connected:

• The main obstacle for manipulating the styling is by far the current stylesheets monolithic nature. These should be split up even though I can't say exactly how. In complement to splitting them, they could afterwards be grouped into cascade order, perhaps by means of tags or... (next bullet)
• Slugification of tiddler titles would enable more direct manipulation of CSS in wikitext, using e.g tiddler titles as class names and even appended as selectors.
• Cascade order deserves an explicit D'nD listing somewhere under Ctrlpanel > Appearance 
• To create a SS tiddler, it ought to be enough to add a $:/tags/Stylesheet tag, i.e auto-detect type.
• Local styleblocks are easily "lost". If there was a way to automatically "collect" (transclude?) them, it would be relatively easy to create custom complex stylesheets or themes gradually.

Hope this clarifies a bit.

<:-)

[TonyM]

Mat et al,

Dropping Awesome fonts, bootstrap and or w3.css css files into a tiddler and tagging as style sheets is easy, trivial even and provides a lot of additional styling opportunities. I like this open solution better than bespoke ones.

To me the main barrier is documentation that helps people understand how to identify, and how to manipulate the elements within tiddlywiki, and the classes, and related variables already in use so that you may override them if desired.

I recently discovered you can even leverage whole html/css platforms if you are prepared to include their dependencies in the same folder of your wiki.

However the new class field should be explored more https://tiddlywiki.com/#Custom%20styles%20by%20user-class

Regards

Tony

[Jeremy Ruston]

Hi Tony

Dropping Awesome fonts,

Just as an aside, icon fonts like Font Awesome are now widely considered to be a bad idea because they are not accessible:

https://cloudfour.com/thinks/seriously-dont-use-icon-fonts/

It’s a controversial topic, but even the most ardent supporters of icon fonts acknowledge that they should only be used either if one doesn’t care about accessibility or if one is skilful enough to fix the accessibility issues. The TW core aims to be universal which implies doing what we can to support accessibility, and avoiding features that are known to compromise it.

bootstrap and or w3.css css files into a tiddler and tagging as style sheets is easy, trivial even and provides a lot of additional styling opportunities. I like this open solution better than bespoke ones.

It is indeed possible right now for apps built with TW to use off-the-shelf CSS frameworks. Using one in the core means selecting one specific one, though.

To me the main barrier is documentation that helps people understand how to identify, and how to manipulate the elements within tiddlywiki, and the classes, and related variables already in use so that you may override them if desired.

I suspect that stuff is pretty self explanatory to a somebody like Arlen who understands both TW5 and CSS. I think that’s the real problem: CSS is complex and takes a significant investment before one fully understands the intricacies that make it so hard at the beginning. I’m not sure that TW5 can take much responsibility for addressing that.

Perhaps more in the spirit of TW5 is to grow a community where people with CSS skills can find and work together with people with design vision.

Best wishes

Jeremy.

I recently discovered you can even leverage whole html/css platforms if you are prepared to include their dependencies in the same folder of your wiki.

However the new class field should be explored more https://tiddlywiki.com/#Custom%20styles%20by%20user-class

Regards

Tony

On Monday, April 29, 2019 at 4:37:36 AM UTC+10, Mat wrote:

Jeremy Ruston wrote:

In reply to @TiddlyTweeters footnote; I also think CSS is one of the areas that need more love. IMO we see very little variations in TW appearences. IMO, CSS is a kind of poor mans coding to affect how things appear so I suspect the big JS-boys here don't fully appreciate this need for us non-JS mortals.

I took Josiah to be expressing agreement with my suggestion of replacing Vanilla and Snow White with an off-the-shelf CSS framework. 

Aha! That would be great! 

What exactly is the need that isn’t being recognised?

Thanks for asking. I'm referring to that CSS is relatively simple to learn at a rudimentary level but still pretty powerful - but that TW is not really set up for manipulating css easily. Here are a few things that would make working with CSS simpler and many are kind of connected:

• The main obstacle for manipulating the styling is by far the current stylesheets monolithic nature. These should be split up even though I can't say exactly how. In complement to splitting them, they could afterwards be grouped into cascade order, perhaps by means of tags or... (next bullet)
• Slugification of tiddler titles would enable more direct manipulation of CSS in wikitext, using e.g tiddler titles as class names and even appended as selectors.
• Cascade order deserves an explicit D'nD listing somewhere under Ctrlpanel > Appearance 
• To create a SS tiddler, it ought to be enough to add a $:/tags/Stylesheet tag, i.e auto-detect type.
• Local styleblocks are easily "lost". If there was a way to automatically "collect" (transclude?) them, it would be relatively easy to create custom complex stylesheets or themes gradually.

Hope this clarifies a bit.

<:-)

-- 
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 post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/09d309a0-d7fe-42c8-a645-2fcfc665d454%40googlegroups.com.

[Jeremy Ruston]

Hi Mat

• 
  The main obstacle for manipulating the styling is by far the current stylesheets monolithic nature. These should be split up even though I can't say exactly how. In complement to splitting them, they could afterwards be grouped into cascade order, perhaps by means of tags or... (next bullet)

Yes, the theme stylesheets are ridiculously big and should be chunked up.

• Slugification of tiddler titles would enable more direct manipulation of CSS in wikitext, using e.g tiddler titles as class names and even appended as selectors.

We can already target specific tiddler titles with CSS, I guess you’re referring to the need to encode the titles when using them in selectors? That can be done with a macro. Slugification isn’t a silver bullet, because titles with nonstandard characters will slugify in unpredictable ways, and slugification needs duplicate avoidance.

• Cascade order deserves an explicit D'nD listing somewhere under Ctrlpanel > Appearance 

OK, but right now you can D&D the order anywhere you see the tag $:/tags/Stylesheet

• To create a SS tiddler, it ought to be enough to add a $:/tags/Stylesheet tag, i.e auto-detect type.

That would be en enormous change, and it’s really hard to see how it could be done consistently, rather than just some bit of random magic whereby some special tags have side effects

• Local styleblocks are easily "lost". If there was a way to automatically "collect" (transclude?) them, it would be relatively easy to create custom complex stylesheets or themes gradually.

Local style blocks are actually almost always a terrible idea, except for trivial test cases.

The problem is that the content of the style tag is wikified. Most of the time, with care, that doesn’t matter, but it’s incredibly easy to forget about the problem until, say, you add a background image URL that contains //, and thus triggers italics.

Accordingly, the core doesn’t use the technique at all.

Best wishes

Jeremy

Hope this clarifies a bit.

<:-)

--
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 post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/7de5e641-c2fa-42d1-9942-7f2a472dc54e%40googlegroups.com.

[@TiddlyTweeter]

Ciao Jeremy & Mat

Jeremy Ruston wrote:

• Mat: The main obstacle for manipulating the styling is by far the current stylesheets monolithic nature. These should be split up even though I can't say exactly how. In complement to splitting them, they could afterwards be grouped into cascade order, perhaps by means of tags or... (next bullet)

Jeremy: Yes, the theme stylesheets are ridiculously big and should be chunked up.

FYI, the work that Thomas has done on this is useful to look at his "Bricks" plugin. https://tid.li/tw5/test/bricks.html

It (1) chunks the monolith; (2) pretty much conforms the rules to a standard existing library (http://tachyons.io/); (3) provides a mechanism for generation.

There IS the issue of specific CSS rules that are dynamically modified in TW that you have to take into account. But overall his approach is a very useful and I think illustrates what may be needed ...

• A - chunking

• B - some kind of interface/toolkit for easier working with the chunked CSS.

Thomas' work goes a good way towards that I think.

Finally, one thing I want to strongly emphasise, and very much in TW's favour, is that its core CSS is very consistent. Thanks to JR. In that sense it CAN be chunked in a reliable way. Compared to many sites its really good logically.

Best wishes

Josiah

[Mat]

@Jeremy 

Thanks for comments. To be clear, my bullets were mere examples of what might be done to make TW support CSS hacking better.

Regarding:

Yes, the theme stylesheets are ridiculously big and should be chunked up. 

[...]

Local style blocks are actually almost always a terrible idea

This made me post this issue requesting compound tiddlers as a possible route.

 

<:-)

[Mat]

Additional examples for improving css hackability in TW:

• Page template based on css grid (Great intro vid for anyone curious).
• ...and tiddlers too (...when subgrids come... or maybe the way TW coded it's not necessary with subgrids i.e already possible?)

<:-)

[TonyM]

Jeremy,

To me it is tiddlywikis' power that html and css largely work out of the box. Throughout the core and ui there are styles and classes used and elements to which they are applied. Most tinkering with css needs to know these classes and the elements they are applied to so the designer can alter or manipulate them. This to me is missing information that makes ui modifications take time.

Regards
Toby