[TW2036] Planning for v5.4.0

#105

I think you will be astonished how view lines of code that actually is. It is 309 loc (lines of code) → 10.5kByte including comments.

  • 2/3 of it can not be removed, because it is initialising, loading and rendering of the canvas in edit mode
    • Edit mode is necessary to be able to define type and fields
  • IMO rotating an image without modifying it is mandatory and can not be removed
  • Resizing an image is needed and can not be removed
  • At line 225 the “touch” and “mouse” handling starts
  • At line 325 is the save mechanism which needs to stay

So the only code that can be removed or “moved into a plugin” is about 90 locs. If we say the average line length is 50 characters, we can safe 4500 character.

  • The edit-toolbar has 9 icons. 4 of them could be moved into a plugin.
  • 4 toolbar buttons have dropdowns
    • colour picker (used for 2 buttons) … 46 loc → 3kB
    • Opacity dropdown … 32 loc → 1kB
    • Line width dropdown … 25 loc → 1kB
  • Icon SVGs
    • Line width → 0.5kB
    • Opacity icon → 1.2kB
    • Paint icon → 0.9kB
    • Eraser icon → 0.5kB

So we can safe: 12.6kByte in the core if we remove the icons from the core. Which means they are not available for users without installing a plugin.

A plugin for 4 icons and 3 wikitext templates and 90 lines of code → IMO that’s not worth it, since core plugins need extra maintenance work.

Especially, since we remove simple very light weight sketching functionality from the app.

You are right. Images done wrong can have a huge impact on wiki size. So telling users, how they should use and optimise images, is worth wile. There is a pending PR at GitHub that will make the wiki at tiddlywiki.com smaller by 2000kB.

IMO that’s worth it. Removing basic drawing functionality and winning 13kByte isn’t.

No offence intended.

#106

First off; absolutely no offence taken, on the contrary you are clearly enlightening me with information (and some opinions). Thank you, if anything.

Regarding the unmovable parts in the drawing tool and how 2/3 creates the canvas - but the point is that someone who wants a drawing tool would import one which presumably features the canvas aspects. Those who don’t want a drawing tool also don’t need the “loading and rendering of the canvas”.

BUT, I believe this request was already answered elsewhere where Jeremy explained that supportability is a prime objective in TW and, implied, that it would not be possible to support what I request here. So for 5.4.0 my interpretation is that the answer is “no”.

#107

It would be fantastic if the CSS in TiddlyWiki v5.4.0 could utilize modern CSS3, as these features are well-established and supported by all major browsers.

I think both Vanilla and Snow White themes should be retired, and a new minimal, maintainable, and hackable base theme should be introduced, using standard CSS3 rules, functions and classes.

It looks like Jeremy (@jeremyruston) has already begun working on a new color handling code for TiddlyWiki, which will hopefully be included in TW v5.4.0.

3 Likes
#108

Anything to MODULARIZE the CSS in TW would make a lot of difference.

At the moment it is far too difficult to trace which CSS is doing what.
The main stylesheet is too monolithic to use easily.

Two cents, TT

4 Likes
#109

You need to be more specific here. Which features do you refer to?

There is no CSS3 there will never be a CSS4 – Now CSS Modules have a level.

#110

I think, @pmario, you are right.

As far as my use goes the existing TW CSS is very good.

My issue is simple. Vanilla is huge. It is extremely difficult to get good at understanding it.

IMO either modularization OR more logical sectioning by comments would help users a lot,

2 Likes
#111

It should be CSS Snapshot 2017, and perhaps also some new CSS properties and functions, because using @support to check CSS properties for fallback is supported in browsers released after 2015.

https://www.w3.org/TR/css-2017/

1 Like