The case against <input type="date"/> in TW?

[Hubert]

Hello,

What is the case against using the html input tag with the "date" type in TiddlyWiki other than compatibility across browsers?

We've seen some great efforts to create datepickers for TiddlyWiki, either standalone or as part of other solutions (such as the brilliant Projectify).

Except for browser compatibility, is there any particular reason why the use of the "pure" html implementation of a datepicker is generally discouraged?

Thanks

-Hubert

[PMario]

Hi Hubert,

I think it's mainly because of UI consistency. We need browser and OS consistency. So it's much easier to create your own UI and be consistent, instead of documenting a 100 different OS and browser combinations.

• Date and Time pickers imo are always used in a very specific context. ... You mentioned Projectify, which is a task-management context
• On a holiday-booking size you may need a "from - to" context and you probably need 2 pickers in 1 "popup".
• In a calendar context you will probably need additional fields for "week" and "time" ...
  
• ... .and so on ...

All of this makes it "easier" to make it on your own!

On the other hand date-calculations are extremely complex, since they have to deal with country and / or region specific differences. ... That's the reason, why many 3rd party libraries are huge in terms of byte-size.

So TW only provides the most basic possibilities. ... Even if they would profit hugely from some "love", since the browsers have made a lot of progress since TW5 and the date-functions have been created.

Just my thoughts!

mario

[Joshua Fontany]

From a technical standpoint, that HTML entity may be removed from the DOM at any time (during the TW refresh cycle, if it is inside a block that gets refreshed to no longer include it, i.e. a user closes the Tiddler in the river, or "hides" it by a "slider"/$reveal. Any code references to that specific HTML entity in the DOM are now broken.

TW uses Widgets (which survive the refresh process, handles all code references i.e. persisting variables or data, and then build HTML to insert into the DOM if the widget is actively displayed).

I would read the Dev Wiki on tiddlywiki.com to get a sense of how the update/refresh procces works, and then the $edit-textwidget docs, and then the CODE inside the "simple engine" that the $edit-text widget spawns for simple 1 line textboxes:

https://tiddlywiki.com/dev/#WikiText:WikiText%20Widgets%20Introduction%20HelloThere

https://tiddlywiki.com/#EditTextWidget

https://tiddlywiki.com/#%24%3A%2Fcore%2Fmodules%2Feditor%2Fengines%2Fsimple.js


There is also this similar plugin: http://kixam.github.io/TW5-datePicker/

Best,
Joshua Fontany

[Hubert]

Hi Mario, Joshua

@Mario, thanks for your detailed response.

I'm in any way trying to challenge the fact that TiddlyWiki has no built-in datepicker functionality. I understand why it doesn't and it makes perfect sense. It would be a complex undertaking that is unlikely to meet all needs. In fact, I think that TW is actually better off without a built-in datepicker widget (less likelihood of bloat, increased bite-size as you mentioned due to various locale settings etc. and also no maintainability requirements). But the building blocks are there, so individual solutions can be built on top of the pure HTML functionality that is inherent to TW.

I was more trying to understand whether relying on the pure HTML implementation can cause problems in itself, other than consistency/compatibility. These problems could be, for instance, that in one browser/OS combination the output of <input type="date"/> would be YYYY-MM-DD and in another browser/OS combination it could be YYYY/MM/DD etc., which would create problems in that the output would need to be parsed (by filters for instance) differently depending on those combinations so that the output is made consistent with the TW format of YYYY0MM0DD0hh0mm0ssXXX before being usable. So, it might need to be more "hacky" than it should. 

BTW, the browser/OS combination is something I haven't tested yet but assume that the output of <input type="date"/> could indeed have inconsistent formatting depending on browser/OS combination. This would then create problems even for personal wikis if used on different devices.

@Joshua, thanks for responding from a technical perspective.

I wasn't aware that the <input/> HTML entity can be removed from the DOM on refresh but widgets can actually withstand refreshes. I guess that we could work around that to some extent but again I'm not sure if it's worthwile. Anyway, thank you for linking to the additional resources, I'll have a read.

Regards,

-Hubert

[Saq Imtiaz]

Note that the <$edit-text> widget can be used in this form: 

<$edit-text tag="input" type="date" tiddler="test">

The user interface however is widely inconsistent across browsers. Also, if you want to save dates in the same format that TW uses for the modified and created field, you will run into shortcomings for converting the TW format date string into something the browser can understand as a date. Using a button to display the date in an <$edit-text> widget after applying a filter is a potential workaround. Saving it back in the correct format is easily resolved with the inputActions parameter to <$edit-text>. 

I am all for minimal solutions but I cannot recommend this approach due the poor cross browser user experience.

[Hubert]

Hi Saq,

Thanks for sharing your take on this, I appreciate it.

The inputActions parameter sounds interesting. Sounds like it will save me a button click in certain scenarios :) Thanks for bringing this up.

Regards,

-Hubert