> The issue of any "subset of HTML" we use is that there are things that
> people might want to include that get excluded because they are
> difficult.
This is true. However, we’re discussing a recommended practice, not a
required one. Of course, some things are not expressible in smolweb /
SubWeb / XHML Basic / HTML 3.2. But suggesting a smaller HTML subset
and (begrudgingly) allowing things beyond it in exceptional cases is
still beneficial for machine processing and user agent pluralism!
> Another issue that is not solved with "small" HTML is that the
> selection of elements is small (by definition), so when we mark up
> things that aren't covered by those elements we have to get
> presentational.
Which applies to full / proper / standard HTML itself too—it’s
impossible to cover everything even with such a repertoire as the one
Living HTML boasts (damn, they even added <geolocation> recently!)
The example of DocBook is noted. I have no suggestions for that
really.
However, the case of procedure prototypes would not be covered in
neither smolweb HTML, SubWeb (I’m inclined to drop that one in favor
of saner smolweb,) nor standard HTML. I think we have to see what the
set of the “uncovered” elements is, and whether they actually might be
covered by any of these subsets. I have a suspicion that this set of
“uncovered” elements actually has no overlap with any of the subsets
for the virtue of being quite Scheme-specific. I might be wrong
though!
> You could try text-before and text-after in CSS, but I find
> that to be a hack.
However much I love CSS content hacks… it’s also not reliably
accessible, so it should not be used for vital non-presentational
information
<https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::after#accessibility>
> This is a representation of EBNF and is structured enough to be
> mechanically translated into a YACC grammar. An HTML representation of
> this would have a lot of superfluous ::=, ⟨, ⟩, +, and * floating
> around that you'd have to remove somehow.
>
> The R7RS DocBook toolchain compiles to XHTML1.1 so you can distribute
> a compiled HTML file for web viewing, and use the DocBook version for
> format translation / extracting information.
>
> This more-or-less brings us back to custom elements, which would be
> fine if we didn't have to use JS to transform them. Having a compiler
> (a simple script) that translates HTML+SRFI-custom-elements to HTML5
> (or XHTML1.1 or SmallWeb whatever dialect of HTML) would be useful.
Yeah, basically that. A script is preferable, of course. Writing one,
however, requires a list of these custom elements to transform. R7RS
small didn’t require many, as processed by r7rs-html5
<https://codeberg.org/aartaka/r7rs-html5/src/branch/main/htmlize.ed>.
SRFIs might require many more.
Update two hours after writing the bulk of this message: actually, I
just parsed all SRFIs and found that there are only ~90 tags used in
them:
262980 <a>
1513 <abbr>
4678 <address>
31658 <b>
7240 <blockquote>
4451 <body>
23067 <br>
8 <caption>
1 <center>
629 <cite>
561949 <code>
6 <col>
2 <colgroup>
60093 <dd>
69 <del>
20 <details>
4 <df>
7303 <dfn>
11489 <div>
13742 <dl>
1773 <!DOCTYPE>
67430 <dt>
196820 <em>
2 <figcaption>
2 <figure>
15482 <font>
51 <foo>
20 <form>
16343 <h>
30195 <h1>
24810 <h2>
26190 <h3>
1935 <h4>
3942 <head>
4184 <hr>
3942 <html>
61672 <i>
757 <img>
100 <input>
86 <ins>
10 <label>
161396 <li>
3328 <link>
1 <mail>
14 <math>
6889 <meta>
6 <mfrac>
80 <mi>
33 <mn>
107 <mo>
41 <mrow>
6 <msqrt>
2 <msubsup>
15 <msup>
1 <mtable>
6 <mtd>
6 <mtr>
8016 <ol>
419054 <p>
6 <path>
118547 <pre>
3715 <q>
34 <s>
73548 <samp>
59 <script>
2352 <small>
13342 <span>
308 <strike>
7487 <strong>
1954 <style>
39460 <sub>
20 <summary>
13573 <sup>
6 <svg>
9481 <table>
779 <tbody>
82305 <td>
16010 <th>
136 <thead>
3941 <title>
39527 <tr>
63031 <tt>
2522 <u>
24413 <ul>
187 <va>
309576 <var>
74 <wbr>
Out of these, there are several groups that are beyong smolweb:
• MathML (14 uses:)
<math>
<mfrac>
<mi>
<mn>
<mo>
<mrow>
<msqrt>
<msubsup>
<msup>
<mtable>
<mtd>
<mtr>
• SVGs (literally 6 uses:)
<path>
<svg>
• Deprecated elements (a lot:)
<center>
<font>
<strike>
<tt>
<U>
<s>
• Actual modern elements
<col>
<colgroup>
<del>
<ins>
<WBR>
The takeaway is: SRFIs are already pretty compliant with smolweb HTML,
with minimal SVG and MathML penetration and significant historical
crust. So imposing a new recommendation is unlikely to significantly
change someone’s process overnight, but will result in more accessible
HTML by default.
What do you think?
Oh, right, here’s the makefile I used to parse all this:
# Use as
# make clean all FILES="$(ls srfi-*/srfi-*.html)"
# In the unpacked srfi.tgz directory
# Dependencies: POSIX make, GNU/BSD ed, coreutils
.PRECIOUS:
.SUFFIXES: .html .html1
FINAL = $(FILES:.html=.html1)
# Helper file extension to generate all tags
.html.html1:
@cp $< $@
@printf "H\n v/[<>]/d\n g/<\\([[:alpha:]]\\{1,\\}\\) *[^>]*>/s//\\\\\n<\\\\1>\\\\\n/g\n v/^<[[:alpha:]]\\{1,\\}>\\\\\$$/d\n wq\n" | ed -s $@
@cat $@ >> tags.txt
all: $(FINAL); @cat tags.txt | sort -f | uniq -ci
clean:
-rm srfi-*/srfi-*.html1
Thanks,
--
Artyom Bologov
https://aartaka.me
