* Fix for Bug #6618
This Commit fixes Bug #6618. It is a little bit more complicated than
using one tiddler to store the new value for a field. Because the
following can happen:
* The user types "not-a-date" into the field value of a simple text field.
* The user now selects a field name that uses a HTML5 date editor. The
Editor will show no date because the value cannot be parsed.
* The user saves the tiddler by clicking the checkmark.
Now the date-field contains the value "not-a-date" but the user was not
aware that this will be added. The edit control showed no date (because
the value was invalid) and the user assumed the field was empty and
won't be added to the tiddler.
To prevent this, every kind of field editor gets its own storage tiddler.
Its name is derived from the SHA256-hash of the name of the tiddler that
is returned by the Field Editor Cascade. That way every editor in the
cascade is only seeing its input. As long as the default setup (with one
default editor) is used, everything works like in 5.2.1.
This commit also fixes the bug that the after adding a field the
field-type input box was not focused again.
* Update Documentation for Field Editor Cascade
The fix for bug #6618 makes the handling of the tiddler backing the edit
operation much more complicated. See previous commit "Fix for Bug #6618"
for more details.
* Fix: eventcatcher widget - variables can be undefined
* Fix: selectedNode can be an svg where offsetLeft ... are undefined
* Make check for offsetLeft short
* remove second collectDOMNodeVariables
* Fix lazy all template with user defined macro cause error
Fixes https://github.com/Jermolene/TiddlyWiki5/issues/6637
* fix: exclude the SJCL library when saving
@Jermolene said:
The construction -[type[application/javascript]library[yes]] is used in the core as a rather clumsy way to exclude the SJCL library when saving. The same construction is in the usual $:/core/save/all filter too.
It's possible that we should review unintended side effects of that behaviour, but here we should leave it alone.
* Documentation for indeterminate checkboxes
* Unit tests for indeterminate checkboxes
* Implement indeterminate checkboxes
* Simplify indeterminate checkbox example
* Slightly simplify refresh logic for indeterminate
That five-line if statement can be turned into a simple assignment.
* Use "yes" and "no" for checkbox indeterminate attr
This makes the "indeterminate" attribute of the checkbox widget work the
same way as other boolean attributes of other widgets.
* Fix bug with invertTag attribute
One place in the checkbox widget code was checking invertTag for
Javascript truthiness rather than the value "yes", which could have
produced incorrect results if anyone wrote invertTag="no". Fixed.
* fix: formatDateString with [UTC]xxx didn't use passed date
* test: for formatDateString UTC
* fix: not possible to test internal date without hijack
Expected '20220410073037515' to be '20220410073037516'.
* fix: hour
* Give plugin authors the chance to extend a palette
* Update CSS.tid
* Update ColourMacro.tid
* Update CSS.tid
* Update ColourMacro.tid
* Add whitespace trim to colour macro
* Show server response as error message in put saver
I'd like to use this on Tiddlyhost so users can get more informative
error messages if the put save fails for whatever reason.
This would make the put saver a viable replacement for the legacy
upload saver, which is what Tiddlyhost uses currently.
I'm not sure what standard WebDAV servers do, but I would guess they
don't provide any response body for put requests, and hence this
patch would have no impact for a standard WebDAV server. (That said,
it would be a good idea to test it to make sure there aren't any
unexpected regressions for WebDAV or other put saver compatible
services.)
* Access http response status directly in put saver
There's no need to extract it from the error string created inside
tw.utils.httpRequest if we can get it directly from the xhr object.
* Add 'Save starting' notification for put saver
There are two related changes here:
1. Add a 'Save starting' notification for the put saver, similar to
the upload saver. Not sure if it was intentionally omitted for
the put saver, but it seems reasonable to have the two be
consistent.
2. Send the 'Save starting' notifications in both upload and put
save right before the actual request is sent. While testing I
noticed that the save might have failed before the "Save
starting" notification appeared which doesn't seem useful.
* Docs for CheckboxWidget list and filter modes
This documents the `listField` and `filter` attributes.
* Tests for checkbox widget list mode
* Implement checkbox list mode
* WIP on implementing filter attr for checkboxes
* Improve CheckboxWidget documentation
* Refactor checkbox tests: move function to top
The big findNodeOfType function belongs at the top of the describe
block, so that the checkbox tests are more compact and easy to read.
* Move checkbox widget tests to end of file
The checkbox widget tests are long and involved, so we'll move them to
the end of the file so they aren't a huge block of code you need to read
past to find the next test.
* Improve formatting of CheckboxWidget docs
The \define() calls that are short enough to fit on one line should be
put on one line, for readability. The ones that are quite long have been
kept on multiple lines, for readability.
* Added more passing tests for checkbox widget
* Add some failing tests for checkbox widget
The filter mode where neither checked nor unchecked is specified (in
which case an empty filter result means false and a non-empty result
means true) is not working yet.
* Make failing tests pass
* Uncomment (and improve) test for field mode
We're now ready to start working on making this test pass. (There was
also one small mistake in the test, which this commit corrects).
* All tests now passing
* No indeterminate checkboxes in simple modes
The simple checkbox modes (field and index) should not produce
indeterminate checkboxes. That should be reserved for the advanced modes
(list and filter).
* Minor improvement to unit tests
* Allow indeterminate checkboxes in list and filter modes
This change may require some tweaks to the unit tests to be able to test
it properly.
* Slightly easier to read tests
* Two more tests for list mode
* Greatly simplify unit test code
Turns out there's no need to jump through Object.getPrototypeOf hoops.
* Minor simplification of unit test
* Add tests for indeterminate in list & filter modes
With this, the set of tests is complete.
* More tests to specify list mode behavior
* Unfocus tests so all tests run
* Update docs to say "new in 5.2.3" insetad of 5.2.2
* Move checkbox widget tests into their own file
The test-widget.js file was getting too long with all the checkbox
tests added, so we'll move the checkbox tests into their own file.
* Add checkbox widget tests for index mode
This commit also adds tests for index list mode (with a listIndex
attribute that will parallel the listField attribute) but leaves them
commented out because they don't pass yet: the code that implements the
listIndex attribute hasn't been written yet).
* Add listIndex attribute to checkbox widget
* Remove code that lets checkboxes be indeterminate
This reverts commit 6afcb151be. We will
add this code back in a later PR.
* Remove indeterminate tests for checkbox widget
We're currently not allowing indeterminate checkboxes, so there's no
need for the tests that check for them.
* Document listIndex attribute of CheckboxWidget
* adds class tc-checkbox-checked when checked
* equivalent to #2182 (RadioWidget)
* also applies `tc-checkbox` to checkboxes by default, always
* Move macro definitions inside example text
Since the wikitext-example-without-html macro creates a new parsing
context, it's safe to have macro definitions inside it. That makes these
examples a lot easier to write, and to read.
* Remove all mention of indeterminate checkboxes
Also improve the documentation a little bit: mention what happens in
list mode if neither checked nor unchecked is specified.
* Move filter mode to bottom of checkbox docs
The `filter` attribute should be under both `listField` and `listIndex`
rather than being between them. The documentation for filter mode should
similarly be after the `listIndex` documentation.
* Improve docs for `class` attr of checkbox widget
This brings the wording of the `class` attribute more in line with how
it's worded in the RadioWidget docs.
* Fix bug with list tiddlers
If neither checked nor unchecked was specified, then the behavior should
be "empty = false, non-empty = true". But if *both* are specified yet
neither is found, then the checkbox should be unchecked (false). It had
been falling through to the "non-empty = true" behavior, which was wrong.
* Improve listIndex example of checkbox widgets
* Remove unused function from test-widget.js
Co-authored-by: Tobias Beer <beertobias@gmail.com>
* adding trim: large macros and languageswitcher
* adding trim: KeyboardShortcuts.tid
* Hidden space to force some macros to be inline
This'll be our little secret. This single byte will actually allow
the uglifier to trim over thirty bytes while condensing.
I know I'm not supposed to optimize TW for some 3rd party plugin,
but I'm the one doing the whitespace trim work, so I'll give myself
this.
* More consistent nested quoting
* First batch of \whitespace trim
Along with some quotation improvements to compensate for the new bytes.
* Undid experimental, new-age, gen-Z formatting
* daring to whitespace trim a placeholder macro
* switching to more consistent nesting of quotes
* Fix field edit bug
This fixes the field edit bug mentioned in
https://talk.tiddlywiki.org/t/possible-field-editing-bug-in-5-2-2/2884 .
* Revert "Fix visual regression in #6511"
This reverts commit c920960942.
* Add new class `tc-edit-fieldeditor`
This class must be added to input and select elements that are used as
field editors. This class reduces the line height of the input element
if it is displayed within the `tc-edit-fields` part of the edit
template.
This allows the same input and select elements to be used for editing
and adding fields.
* Add the new class `tc-edit-field` to the docs
The example in `Customizing EditTemplate Field Rendering` now uses the
new CSS classes.
* tabs activate v5.2.2 tests add whitespace trim
* tabs-macro -- add indentation and code preview
* tabs-macro -- replace substitutions with variables
* split tabs-macro macro into different elements
- tabs-button
- tabs-tab
- tabs-tab-list
- tabs-tab-body
- tabs ... main macro
* tabs: add cascade to button and reaveal widgets
This will allow users to create "default tab" configurations similar to the tiddler info tab handling.
* tabs-macro -- add code_body: yes
* adding trim: Last of the macros I think
* adding trim: EditTemplate and ItemSidebarIcon
* adding trim: control panel basics
* Another hidden space to guide the uglifier
* More consistent nested quoting
* Reconciling tests for \whitespace trim
* adding trim: AdvancedSearch Standard
* adding trim: tiddlers that had SOME trim already
* making all existing trim tiddlers consistent
* Forgot to properly indent this widget
* I don't THINK that space was important...
but I'm putting it back in
* Forgot one whitespace trim