From c260df79943d6dd57720d369dfb9214644ef94e0 Mon Sep 17 00:00:00 2001 From: valentin gagarin Date: Wed, 13 Nov 2024 15:24:41 +0100 Subject: [PATCH] add todo concerning palpable content --- presentation/dom.nix | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/presentation/dom.nix b/presentation/dom.nix index ecd096e0..d15198dc 100644 --- a/presentation/dom.nix +++ b/presentation/dom.nix @@ -557,7 +557,14 @@ let })); }; }; - config.categories = [ "flow" ] ++ [ "palpable" ]; + # XXX: here we can't express the spec requirement that `dl` is palpable if the list of term-description-pairs is nonempty. + # the reason is that we have to specify a child's *type* in the parent, but being palpable is a property of the value in this case. + # and while the module system does have some dependent typing capabilities, we can't say "the type is X but only if its value has property Y". + # but since the "palpable" category isn't used in any structural requirement in the spec, this is not a loss of fidelity on our side. + # TODO: the whole notion of content categories may be a red herring for this implementation after all, reconsider it. + # it does help to concisely express type constraints on an element's children, but it seems that most of the categories in the spec can be ignored entirely in this implementation. + # the cleanup task would be to identify which categories are really helpful, and document the rationale for using that mechanism as well as the specific choice of categories to keep. + config.categories = [ "flow" ]; config.__toString = self: with lib; let