From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp1.migadu.com ([2001:41d0:403:58f0::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms13.migadu.com with LMTPS
	id uFL8FmwIoWf5KwEA62LTzQ:P1
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Mon, 03 Feb 2025 18:18:20 +0000
Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp1.migadu.com with LMTPS
	id uFL8FmwIoWf5KwEA62LTzQ
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Mon, 03 Feb 2025 19:18:20 +0100
X-Envelope-To: larch@yhetil.org
Authentication-Results: aspmx1.migadu.com;
	dkim=pass header.d=lukasepple.de header.s=uberspace header.b=wr4esubH;
	dmarc=none;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org;
	s=key1; t=1738606700;
	h=from:from:sender:sender:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:mime-version:mime-version:
	 content-type:content-type:list-id:list-help:list-unsubscribe:
	 list-subscribe:list-post:dkim-signature;
	bh=i4MEEzpA7/ww0A5YHONdeekHVG9mWvs8+DWWqPXWlZA=;
	b=RO3uLZGcwXuNlXl8UmQOJEsO1BXaCs6uNMU3Smf4Bc/OQP7XV4gRem8LdxL4qih+A2Wpbi
	zhCGeKKkbJZmDXAQNxpZzRYM2kfu2jduLccgAjMdOTk2CLKXG/7/6xW405FvHOkGIdxv0y
	5XCJKRlCD1sA0m1T0KaRlVV37qDLzgo7bxHpCWABqTPZD88fBCOzzU295n6QdymWcav4EY
	zEiW/3XIvOdpOVwuEAhH4g5PwBpvTSwxF0KTVxiDabXha7oRAWXEGgyVgs9mHxvHMgHL2g
	k23JIKsaL/8/SdArqu/cqIRYNKY/eNMNGfcQj751cTGiL/2pHao302n3rEtVuA==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=pass header.d=lukasepple.de header.s=uberspace header.b=wr4esubH;
	dmarc=none;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"
ARC-Seal: i=1; s=key1; d=yhetil.org; t=1738606700; a=rsa-sha256; cv=none;
	b=jNZKkDknXMWLMg/lvjgRgLzM95BccDweYAMOwFj3Jj8PfdhjXYHFd5+FXB5EdiC3K+v5/a
	DWQp2/JSp0EiuOT+PnHxJmIjEOElMgebI6NITbFsAcgonGhUjS81yyMhLmgvSv+k3NZdNu
	EWa5TY5vlp2NA1sAc49sFCvlIOYcMJ44AgxlwetGwEjmeiLZgOebKfOA8oZADAd9Vy/W4B
	PA6bhpCOrB6VSEgRok+jv1k8+N+OISb8+lG6jlPbAUqxCc09Y9XMLFztwAsIZWBrBUfXee
	Rz+0AMn9c2Fng6Pm0fUPOT28EwpBrnmSyMu4ccVTCg2whkAUpUmcytGuj0QmSg==
Received: from lists.gnu.org (lists.gnu.org [209.51.188.17])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by aspmx1.migadu.com (Postfix) with ESMTPS id 2EA9E8EEE0
	for <larch@yhetil.org>; Mon, 03 Feb 2025 19:18:20 +0100 (CET)
Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-orgmode-bounces@gnu.org>)
	id 1tf10q-00069D-NL; Mon, 03 Feb 2025 13:17:36 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <emacs@lukasepple.de>)
 id 1tf10n-00068m-25
 for emacs-orgmode@gnu.org; Mon, 03 Feb 2025 13:17:33 -0500
Received: from mailgate02.uberspace.is ([2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <emacs@lukasepple.de>)
 id 1tf10k-0001hz-Ls
 for emacs-orgmode@gnu.org; Mon, 03 Feb 2025 13:17:32 -0500
Received: from belinda.uberspace.de (belinda.uberspace.de [185.26.156.156])
 by mailgate02.uberspace.is (Postfix) with ESMTPS id 4760E18049F
 for <emacs-orgmode@gnu.org>; Mon,  3 Feb 2025 19:16:38 +0100 (CET)
Received: (qmail 12285 invoked by uid 989); 3 Feb 2025 18:16:38 -0000
Received: from unknown (HELO unkown) (::1)
 by belinda.uberspace.de (Haraka/3.0.1) with ESMTPSA;
 Mon, 03 Feb 2025 19:16:37 +0100
Content-Type: multipart/mixed; boundary="------------VfoPgKKn3XjFs33gIwb8LlgR"
Message-ID: <20a8f91f-9edf-448d-aff7-e40e845033cc@lukasepple.de>
Date: Mon, 3 Feb 2025 19:16:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Lukas Epple <emacs@lukasepple.de>
Subject: [FR] [ox-html] export timestamps and durations via HTML5 <time>
 element
To: emacs-orgmode@gnu.org
Content-Language: en-US
X-Rspamd-Bar: -
X-Rspamd-Report: BAYES_HAM(-3) XM_UA_NO_VERSION(0.01)
 MIME_BASE64_TEXT_BOGUS(1) MIME_GOOD(-0.1) MIME_BASE64_TEXT(0.1)
 MIME_HTML_ONLY(0.2)
X-Rspamd-Score: -1.79
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=lukasepple.de; s=uberspace; h=from:to:subject:date;
 bh=GvtGSaW7/mdrfrW4M2wthl8D3b54oCCYHSHOJa+e0AM=;
 b=wr4esubHLqbOSq9iA6tvP/gFYVLUMImVWdhCbV48xgEivvaN+4mdgGehBHttoF1mDgVYnV4qVU
 xkMQtmsG/u40Qrqrs3z8EEvCHgMQhip0/9PSiF4kHIs2ozAI5RADPbN8L/irX+oY5vh44pJE2efh
 Uy7xdYJaeeETQr52eUgjJtw+Ir0ngWfp6d60eqo4MFTGnlgTd4p3YfNCd3KALgxHagR3jesakQTH
 N5ilc2piSysdLxBeXQeL0cbI+FfSO/YuvUvmkzu+XqLALvXHk8DXSqvfhe9P+K8ykdQYAqvAKquR
 iEder1R3DlxSidLfvRpLvm+HvJs9IMBpX6pspOQkDBh5FuPmBKvBgX7OftHsn+7pyVRQTeEoOcZ2
 IZpu0tPnegGAJkqYFd5NXtrmeZTRZYPtSPJhCIWOY+BnufYUmSD7BBA0jcXJtzIGNcK6X5ufADJP
 4h/xSWyINs8rRpKddN7mQdH5+W+WCuReHs4bXTZq4XyW6zhowMLAsmDCS4Jsjee65ClQW6KBgsco
 VJqndEaeK8ST7FrjPTJUucehG2+y3oNn5pQd1iUyRbDtn1GCA9s98n2uGygXRwNln5d6GSSWUCMQ
 4865YGLUlOJTpw7KGdusDjReBz+mvhfaZNXzASclX+gxq7oMNOpb27aQ7VtyD4ydhgqK4xbdjH7j
 s=
Received-SPF: pass client-ip=2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4;
 envelope-from=emacs@lukasepple.de; helo=mailgate02.uberspace.is
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-BeenThere: emacs-orgmode@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
X-Migadu-Flow: FLOW_IN
X-Migadu-Country: US
X-Migadu-Spam-Score: -2.14
X-Spam-Score: -2.14
X-Migadu-Queue-Id: 2EA9E8EEE0
X-Migadu-Scanner: mx11.migadu.com
X-TUID: pVK0wKxLKVRE

This is a multi-part message in MIME format.
--------------VfoPgKKn3XjFs33gIwb8LlgR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi everyone,

* Feature Request

currently HTML export will always render timestamps, both plain and from 
a clock/planning element to something like the following HTML:

     <span class="timestamp-wrapper"><span class="timestamp">
     [2025-01-31 Fri]
     </span></span>

If we are using HTML5 (<!doctype html>) to export, we are entitled to 
use the <time> element [1] [2] which allows attaching a machine readable 
date, time, datetime or duration to text. Consequently, I propose that 
we change the rendering to something like the following if the user sets 
org-html-doctype to use HTML5:

     <span class="timestamp-wrapper">
     <time class="timestamp" datetime="2025-01-31">[2025-01-31 Fri]
     </time></span>

Browsers don't seem to treat <time> much differently from <span>, so I
don't think we'd need to adjust CSS. For non-HTML5 rendering, we can
continue using <span>.

* Motivation

MDN states

> It may include the datetime attribute to translate dates into 
> machine-readable format, allowing for better search engine results 
> or custom features such as reminders.

Also, screen readers can in principle rely on this extra information in
order to properly present the content of the element (I do not know if
they do in practice, though). For Org Mode, using <time> would mean that
the export doesn't loose information even if the user defines some org-
display-custom-times format that does (see also Open Questions section
below).

* Proposed Implementation

I would be happy to write the patch myself, but I figured I'd ask for
feedback on the idea and some pointers first, especially since I've not
yet assigned my copyright to the FSF. I've attached an (undocumented)
proof of concept which implements this change for org-html-timestamp
only (by overriding the function using advice-add).

As far as I can see, a concrete implementation could be achieved in the 
following steps:

1) Add a new pair of timestamp formats to ox-html which are HTML
compatible (i.e. ISO8601), e.g. '("%F" . "%FT%T%z").

2) Add a new function that handles rendering everything inside the
timestamp-wrapper span (in my code, it is called le-org-html-format-
timestamp). This function would be used by org-html-timestamp, org-html-
planning and org-html-clock.

It would switch between <span> and <time> based on org-html-html5-p. If
HTML5, the datetime attribute is added based on the format from 1) via 
org-format-timestamp. For the text inside the element, 
org-timestamp-translate would be used in all cases, like before.

3) For the duration part of org-html-clock we need to render a supported
duration string (see [2]) inside the datetime (!) attribute. As far as I 
know, there are no existing facilities to render a compatible output. It 
shouldn't be difficult to write a function similar to 
le-org-html-format-timestamp for durations. The formatted string would 
probably need to be generated based on org-duration-to-minutes.

** Open Questions

1) In the example above, I've used an RFC3339 format string which
includes the local time zone. Since I've written that code, I've become
somewhat convinced that we should not include the timezone (at least not
by default). While it is nice that this would actually make the
timestamp fully determinate, timestamps in org files don't have the
ability to prescribe the timezone, so the system time zone is used. As a
result, exporting the same org file on machines with different time zone
settings would reduce in HTML export that references different points in
time.

2) It also occurred to me that including the timezone would leak the
user's timezone settings without them necessarily noticing. Browsers
usually don't display the datetime attribute to users anywhere.

This got me wondering about a hypothetical scenario where a user
deliberately uses org-display-custom-times to reduce the precision of
timestamps in the output. With my proposed change, the full precision
timestamp would still be recoverable via the datetime attribute. If the
user were to do this for increased privacy, it would be problematic.

These scenarios are probably (?) outlandish, but I'm interested to hear
opinions on this or maybe related design decisions Org Mode has made in
the past. It is not like we'd be breaking an intended privacy feature in
Org Mode, so the change is permissible, I think. It is worth 
considering, though, since the changed HTML output wouldn't be apparent 
to the user unless they'd look at the underlying HTML.

Kind regards,

Lukas

[1]: https://html.spec.whatwg.org/multipage/text-level-
semantics.html#the-time-element
[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/time
--------------VfoPgKKn3XjFs33gIwb8LlgR
Content-Type: text/x-emacs-lisp; charset=UTF-8;
 name="le-org-html5-timestamps.el"
Content-Disposition: attachment; filename="le-org-html5-timestamps.el"
Content-Transfer-Encoding: base64

OzsgU1BEWC1GaWxlQ29weXJpZ2h0VGV4dDogQ29weXJpZ2h0IChDKSAyMDExLTIwMjQgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCjs7IFNQRFgtRmlsZUNvcHlyaWdodFRleHQ6
IENvcHlyaWdodCAoQykgMjAyNSBMdWthcyBFcHBsZQo7OyBTUERYLUxpY2Vuc2UtSWRlbnRp
ZmllcjogR1BMLTMuMC1vci1sYXRlcgoocmVxdWlyZSAnb3JnKQoocmVxdWlyZSAnb3gtaHRt
bCkKCihkZWZjb25zdCBsZS1vcmctaHRtbC10aW1lc3RhbXAtZm9ybWF0cyAnKCIlRiIgLiAi
JUZUJVQleiIpKQoKKGRlZnVuIGxlLW9yZy1odG1sLWZvcm1hdC10aW1lc3RhbXAgKHRpbWVz
dGFtcCBpbmZvKQogIChsZXQqICgodGFnIChpZiAob3JnLWh0bWwtaHRtbDUtcCBpbmZvKSAi
dGltZSIgInNwYW4iKSkKICAgICAgICAgKGh0bWw1LWZvcm1hdCAoZnVuY2FsbCAoaWYgKG9y
Zy10aW1lc3RhbXAtaGFzLXRpbWUtcCB0aW1lc3RhbXApICMnY2FyICMnY2RyKQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGxlLW9yZy1odG1sLXRpbWVzdGFtcC1mb3JtYXRz
KSkKICAgICAgICAgKGF0dHJzIChhcHBlbmQgJygiY2xhc3M9XCJ0aW1lc3RhbXBcIiIpCiAg
ICAgICAgICAgICAgICAgICAgICAgICh3aGVuIChvcmctaHRtbC1odG1sNS1wIGluZm8pCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgKGxpc3QgKGZvcm1hdCAiZGF0ZXRpbWU9XCIlc1wi
IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG9yZy1mb3JtYXQt
dGltZXN0YW1wIHRpbWVzdGFtcCBodG1sNS1mb3JtYXQpKSkpKSkKICAgICAgICAgKGRpc3Bs
YXktdmFsdWUgKG9yZy1odG1sLXBsYWluLXRleHQgKG9yZy10aW1lc3RhbXAtdHJhbnNsYXRl
IHRpbWVzdGFtcCkgaW5mbykpKQogICAgKGZvcm1hdCAiPCVzICVzPiVzPC8lcz4iCiAgICAg
ICAgICAgIHRhZwogICAgICAgICAgICAobWFwY29uY2F0ICMnaWRlbnRpdHkgYXR0cnMgIiAi
KQogICAgICAgICAgICAocmVwbGFjZS1yZWdleHAtaW4tc3RyaW5nICItLSIgIiYjeDIwMjEz
OyIgZGlzcGxheS12YWx1ZSkKICAgICAgICAgICAgdGFnKSkpCgooZGVmdW4gbGUtb3JnLWh0
bWwtdGltZXN0YW1wICh0aW1lc3RhbXAgX2NvbnRlbnRzIGluZm8pCiAgKGZvcm1hdCAiPHNw
YW4gY2xhc3M9XCJ0aW1lc3RhbXAtd3JhcHBlclwiPiVzPC9zcGFuPiIKICAgICAgICAgIChs
ZS1vcmctaHRtbC1mb3JtYXQtdGltZXN0YW1wIHRpbWVzdGFtcCBpbmZvKSkpCgooYWR2aWNl
LWFkZCAnb3JnLWh0bWwtdGltZXN0YW1wIDpvdmVycmlkZSAjJ2xlLW9yZy1odG1sLXRpbWVz
dGFtcCkKCihwcm92aWRlICdsZS1vcmctaHRtbDUtdGltZXN0YW1wcykK

--------------VfoPgKKn3XjFs33gIwb8LlgR--