Also called Ell Dee

And something else, editing one's entries on the dashboard seems to become increasingly more laggy the more content there is, to an almost unusable degree already.

Depicting how the current theme mod renders the datetimes and amounts of notes.

Sigh. This tangent is long enough already.

The first reblog incidentally exposed a bug in the theme mods. Might just make that bar contain three lines, though that would make it even blockier. And now how to make it so that only affected entries contain the third line?

Found after the earlier review that, apparently, out of the two "GMT" settings, there's one with some sort of seasonal timezone changes (labelled "(GMT) Greenwich Mean Time : Dublin, Edinburgh, London", internally selecting "Europe/Dublin") and another that apparently doesn't have any of those (labelled "(GMT) Casablanca, Monrovia", internally selecting "Africa/Casablanca"). Speculatively then, all the datetimes formatted (in ISO 8601) on this blog, which were previously marked as "local", will now stay as UTC permanently. Hence they will now be marked with the 'Z' (as in ISO 8601) to indicate this.

That self-selected suspension of tumblr usage endured for a much shorter duration than usual.

It's only that datetime stamps in all entries appear to be controlled by that one "Timezone" setting on www.tumblr.com/blog/NAME/settings which unfortunately doesn't clearly indicate whether and in what way seasonal timezone changes (incl. "daylight saving time", "summer time") are handled. The datetime stamps on the most recent entries imply that the selected "GMT" setting actually uses +01:00 currently, not +00:00 (ie UTC). Need further testing to find out whether the current effective timezone trivially determines the offset used with all datetime stamps, or whether seasonal change rules of the selected timezone are applied in a proleptic manner so that datetime stamps of specific entries are constant across the year while the same selected setting is constant (entries would then have local times of different effective timezones depending on when they were published). Don't know which is the worse. However, seasonal timezone changes along with unmarked local datetimes are clearly at the root of this; unsurprisingly, both are bad. There does not appear to clearly be any UTC setting that doesn't use any seasonal timezone changes. The tentative examination of the themes mechanism yielded no way to mark local datetimes with their effective timezone. Presumably, no information is stored on the timezone used by the author of an entry while submitting it. All right, there is not a lot of timezone handling that could be worse, apart from permanent corruption of the metadata. Not particularly happy with it being severely inaccessible, though.

_is_bad is bad

In other news, the plain text reception apparently deleted the URL included with the previous entry somehow. Furthermore, the way this user agent wrapped the plain text email apparently caused the plain text reception to insert br elements after each linebreak as it occurred in the email. And then the Markdown source text reception apparently deletes tags and also some text that is Markdown-formatted in some specific ways. Didn't expect their handling to be /that/ bad. To mention, presumably there is no way to queue the entries published using the email interface. All in all, given this start, again the phenomenon can be observed that any tumblr usage causes the urge to write, host, and use an alternative to rise, permanently and steadily. This is not a good thing. And then the situation around theme development, available themes, and the bad conditions of both the former. And the all too conventional lock-in of content and users. Only the most essential considerations. Seemingly, tumblr is still exactly as hostile on the technicalities and usability as remembered from former experiences and first impressions. -is-bad -copyrights-unquote

Test Test

Test Test

Test

There seem to be some scary heuristics in effect which will determine what type of entry the user presumably intended to submit, based on various aspects of the email's content. Some of this is documented on but it isn't documented that there are a full three categories of text posts, as follows: * (documented/implied) plain text emails * (documented) Markdown-formatted emails * (undocumented) HTML-formatted emails There is a special "code" in order to indicate Markdown formatting, although this is problematic because the code is supposedly detected "in any part of the email's subject or body", therefore (for instance) this entry cannot include that code lest it will be a false positive. Note that the HTML to plain text distinction applies not only depending on the type of the received email; in all tests as yet only emails containing plain text were sent. That is, even for plain text emails, tumblr's receiver uses some heuristic to determine whether to read the text contents (of an email determined to be intended as a text entry) as HTML source text or as plain text, with all that implies on its own. Furthermore, as for the documented Markdown indicator code, it might be that any text in the entry that reads like HTML mark-up might be misinterpreted as the user's intention to have the text interpreted as HTML source text when this wasn't the case. Aside all of that, it is unclear what precedences apply particularly to the determination of the email as HTML instead of Markdown source text. This knowledge might be necessary to implement a workable alternative. (The latter must allow the user to know how the email is interpreted without having to check after reception by tumblr, and ideally would allow entering any text to appear literally in the published entry. The second requirement already rules out plain text for this.) If detection as HTML source text has precedence over detection of the Markdown indicator then sending easily-detectable HTML source text should be a sufficient workaround. The right way to do this would be to have explicit ways to indicate to tumblr's receiver how to interpret the email's content instead of the unwell-documented heuristics. (The lack of supplied documentation and lack of details in the supplied documentation worsens the usability, but the design approach of heuristics is arguably fundamentally wrong for advanced use cases.) It is clear why the heuristics design was chosen for such a feature, but there should rather be alternatives with the heuristics in place as default only rather than a requirement. As a requirement, it turns the feature into somewhat of a mis-feature, by making it a hassle to use it for some use cases. Furthermore, the entire feature of publishing via emails should be configurable to be enabled either only from select email addresses or from any email addresses at least. Optionally requiring further authentication would be even better.