Hi Artyom, I'll reply inline

> On 6 Sep 2026, at 09:27, Artyom Bologov <xxxxxx@aartaka.me> wrote:
>
> Hi y’all, hi Duncan,
>
> I realize that my comments are tangential to the actual SRFI text, but
> so are style changes which I consider to be both unnecessary and
> undeserving of a new draft. Comments inline:
>
>> I have also styled <pre> blocks with shading so that the
>> examples are much more clearly distinguished, and I've adjusted the
>> spacing below them.
>
> Shading <pre>-s is a good change, and I personally think this should be
> the default. Arthur, would you be open to such a change in srfi-common?
>
>> I have also adjusted the spacing of the procedure
>> definitions so that it is more consistent, and so that their descriptions below are more clearly linked to the definition immediately above.
>
> I find such layout complications unnecessary, because they break the
> flow of reading and make older / simpler / weaker browsers to do
> unnecessary work. In my SRFIs, I stick to this structure:
>
> <h3>(srfi XXX) procedure (procedure prototype ...)</h3>
>
> While it is slightly more verbose, it’s dead simple to parse and read,
> regardless of a user agent.

This is a change made in a previous draft - this adjusts the spacing
underneath these sections so that it's more consistent when there are
only one procedure in a block. (You're probably aware of this but the
CSS is based on SRFI 276.)

Originally, I took an approach like headings but it didn't work very
well. Specifically, the SRFI exports several libraries, and the document
is not linearly structured in terms of those libraries (as there is
effective duplication for URIs and IRIs).

The libraries were their own headings at level h4, and although the
exported procedures weren't a heading, they were in body-like bold text,
so that's another level of nesting.

I agree that it is more readable in certain proposals, but they don't
export many libraries and are generally terser. In writing this out it
was a constant fight to write more tersely in a way which is clearly
structured and implementable.

>> I have also overridden the default font presentation with a combination of URW Classic Sans (clone of Univers included with Ghostscript) for
>> headings, table structure and test cases, Charter (sans-serif font used in the Racket documentation) for body text, and Roboto Mono for
>> monospace. The R7RS.org website uses URW Classic Sans and it works quite well.
>>
>> Roboto Mono is a good match for the section headings as the original Roboto is close to Univers for many characters (e.g. 'G'), and it has
>> good character coverage which helps in the IRIs.
>
> I personally think that fonts should be left out of SRFI documents,
> unless these fonts come for global srfi.schemers.org stylesheet. SRFIs
> should be simple to parse and read, which means basic HTML and abiding
> to user agent fonts.
>
> In particular, someone with OpenDyslexic or Atkinson Hyperlegible fonts
> might actually _need_ them to read things comfortably. Unconditionally
> overriding fonts hurts accessibility (huge turn-off) and performance
> (which is mostly okay, but is a cherry on top of inaccessibility.)
> Forcing fonts on readers is not cool, especially for such vital
> documents as SRFIs.

I hear you, but I don't understand how this differs from the default
template, which forces Noto Sans (loaded from Google fonts). If we're
going to make the site more accessible then I presume there'd be more
involved than refraining from setting a font.

>> I think it's worth overriding the web browser's own monospace font as it means we can
>> match the monospace font to the body text in terms of size.
>
> This is easily fixable with
>
> pre, code {
>   font-size: 1em;
> }
>
> Including a font solely to “fix” code sizing is an unnecessary burden on
> everyone.

There are a lot of monospace fonts out there and typically the actual
character size is not well-matched to the body text font even when
they're set to a uniform size. I experimented with a bunch of system
fonts and the default, and it was very difficult to get a good match
without reducing the size of the monospace font. It felt that it
mattered for readability in a dense document like this where there is
a lot of monospace inline with body text.

> Yes, the default browser stylesheets setting code / pre font size to 95%
> make a despicable choice, but this is left for discussion elsewhere and
> is unlikely to be fixed due to its backwards-compatibility motivation.
>
>> The procedure index is formatted so that there are no line breaks on hyphens and the procedures do not overflow the notional text width.
>> This also the case in the paragraphs describing procedures (when they link to other procedures).
>
> Note that this might hurt readers on narrow viewports, like smaller
> phones. If you force-disable word breaks, the people get unnecessary
> horizontal scrollbar in the document. This complicates reading and
> scrolling tremendously. See https://aartaka.me/easy-fixes.html#wbr for
> context and a fix:
>
> p {
>    word-break: break-word;
>    overflow-wrap: anywhere;
> }

I didn't realise! Thanks. That was a mistake.

> I urge you to roll back fonts and questionable CSS. For those cases
> where the changes are actually useful (like with shading of code / pre,)
> consider contributing them to srfi-common instead, so that _all_ SRFIs
> benefit from more readability.

I am happy to roll back the fonts but a number of the CSS changes
aren't really about the font at all. SRFI 275 gives gives a number of
test cases and I partly selected the fonts in order to make that portion
of the document more readable without excessive bold text.

There are a number of SRFIs which do not follow the current template,
for various reasons, and at least one which overrides the default
font, so it wasn't clear what the consensus is. I would appreciate
some clarification on this.

I also want to emphasise that the font selection was not arbitrary
and was made with the structure of the proposal in mind. I selected
fonts which are widespread in the Scheme community already (namely
the same body text as the Racket documentation site).

Thanks again,
Duncan