Although blockquote already is set to italic now blockquote p explicitly
sets it. The colour is dark green and the rationale is explained in the
comments as thus:
/* This rule makes sure that text in <blockquote><p>..</p></blockquote> is
* coloured right. Note that this MUST BE HERE and not earlier where the
* 'blockquote' rule is as otherwise the above '.content p' rule would
* override it.
*
* The following rationale with the blockquote rule above (in particular
* with italics) and the dark green selection, so that this is understood
* better:
*
* 0. Purple should NOT be used as this is being used for visited links.
* 1. Blue should NOT be used as this is being used for non-visited links.
*
* Now with context this might be okay but links can also be in blockquotes
* so this alone is reason not to: even if there are underlines in most
* links. Additionally:
*
* 2. Bold seems to be too strong, especially when used for with a bright
* colour.
*
* Bold is used in headings (h1, h2, ..). A bold heading is not too much
* text (as headings tend to be short single lines): one does not become
* too tired looking at TOO MANY SHOUTING BOLD LETTERS. It seems preferable
* to reserve bold for those headings.
*
* Conclusions: dark blue seems to be slightly better but unfortunately the
* headings (h1, h2, ...) is too similar so we use dark green with italics
* as the choice.
*/
Improve the formatting in `1992/westley/README.md`
and thus the resulting `1992/westley/index.html`.
Corrected a mistake on the use of `./whereami.alt`.
Perform `make www` to perform the above and test under macOS.
The `bin/pandoc-wrapper.sh` tool will use `expand(1)` to expand
leading ASCII TAB characters into multiples of 8 ASCII space
characters on all markdown data before piping it into `pandoc(1)`.
Thus, any leading ASCII TAB character in markdown files will be
automatically converted into spaces using 8 character tabs.
Changed `bin/pandoc-wrapper.sh` VERSION from "1.6.3 2024-06-22"
to "1.7 2024-06-22" to preform the above.
Perform `make www` to perform the above and test under macOS.
It turns out that only one other HTML file was impacted: `bugs.html`.
All other leading ASCII tab characters have been rendered
[Mostly Harmless](https://en.wikipedia.org/wiki/Mostly_Harmless). :)
When `bin/pandoc-wrapper.sh` encounters a fatal error, it will
leave behind `debug.input.md` and `debug.output.html`.
Added `debug.input.md` and `debug.output.html` to `.gitignore`.
The `.gitignore` file comment noew refers to `sgi.sh` not sgi.
Changed `bin/pandoc-wrapper.sh` VERSION from "1.6.2 2024-04-18"
to 1.6.3 2024-06-22" to preform the above.
Perform `make www` to perform the above and test under macOS.
While not strictly necessary, replacing the two ASCII tab characters
in the markdown copyright comment makes it easier to detect problematic
TAB indentation within markdown files.
After this commit, only 90 markdown files have leading ASCII TAB
characters. And again, while not strictly necessary, we can consider
running expand on those 90 markdown files to see what effect that
might have on the HTML files they produce.
Replace leading ASCII TAB characters with multiples of 8 ASCII SPACE
characters (the default action of the `expand(1)` tool) might have
an negative effect on some HTML formatting where **hack-a-round**
formatting was attempted to fix broken indentation caused by
problematic ASCII TAB characters.
Think of this as a baseline for evaluating leading
TAB characters within markdown files.
TODO: Consider either using `expand(1)` to replace leading ASCII
TAB characters with multiples of 8 ASCII SPACE characters AND/OR
modifying the appropriate `bin` tool to convert leading ASCII TAB
characters into multiples of 8 ASCII SPACE characters.
One must **NOT** use ASCII TAB characters to intent text. Down the TAB-ed
road is nothing but trouble! There are _quasi-solutions_, however those
have side effects that lead to a different set of problems.
The `markdown.md` was updated to ask that text not be intended with ASCII tabs.
See [Please do NOT use ASCII tabs to indent
text](https://ioccc-src.github.io/temp-test-ioccc/markdown.html#markdown.html#please-do-not-specify-a-language-for-a-code-block).
We discovered this awhile ago and fixed it in markdown files. Sorry
(tm Canada 🇨🇦), we forgot to mention this this in `markdown.md`.
BTW: It took some **deep magic** to be able to show an HTML comment
after a starting fenced markdown code block! See the **NO_COMMENT=**
line in `bin/md2html.cfg`. :-)
TODO: Stamp out indenting TABs in markdown files, especially in code blocks.
TODO: Consider a rule to detect problematic ASCII TAB intendation
within makrkdown files.
I believe now that it is in good order except for a strange indentation
issue in the index.html file in some code blocks that presumably has to
be fixed with CSS.
The bugs file was also slightly updated.
The whereami.c file should not have been left in as the scripts added
take care of the problem.
The Makefile now links whereami to westley and whereami.alt to
westley.alt. Running make clobber will remove the links.
The index.html had some mistakes from the time where the C file was
useful. There might still be some mistakes but that will have to be
checked another time.
The manifest has been updated locally but the .entry.json file and the
index.html file have not yet been corrected. This will happen soon after
the rest of the changes of 1992 are committed.
The problem was that later in the stylesheet there is '.content p' and
since the <blockquote><p>..</p></blockquote> is in the content class the
colour was being overridden. Thus there is now:
.content blockquote p {
color: blue;
}
which fixes the problem.
The play.sh script entry_text refers to snake-colours.sh so
snake-colours.sh comes first. Also since it's a key part of the entry
they come before the html files.
To help the fact it's a quote stand out better the vertical bar is a bit
thicker (4px instead of 2px) and the colour is a bit darker (darkgrey
instead of #e6e6e6). Also the font style is italic (as quotes often are
shown) and the font weight is bold to help it stand out even more (that
might be worth changing). Finally the colour of the text is blue (which
looks nice with bold so it might also be changed if the weight is not
bold).
A point worth noting is that in CSS (tested on my apache server and also
W3Schools) having:
blockquote {
color: blue;
}
does not work (for <blockquote><p>...</p></blockquote>) as in the colour
stays what was left for <p>...</p. which earlier in the stylesheet is
set to black. On W3Schools what does work is:
blockquote p {
color: blue;
}
but on the server for some reason it does not quite work. The rest of
the change to blockquote do work but not the colour of the text. I am
not sure if this is a cache or similar problem or not but clearing the
cache and also history (of the past hour) does not seem to solve the
problem at least at this time. Thus it is entirely possible that this
has to be fixed too.
To put this another way this change might need some tweaking still but
the blockquotes now stand out much better.
Detect were the stat tool is located. If no stat tool is found,
set `$STAT_TOOL` to `false`. Cleanup comments related to
determining the modification time of a file.
Changed `bin/gen-sitemap.sh` VERSION from "1.3.8 2024-04-28"
to "1.3.9 2024-06-21".
Changed `bin/gen-status.sh` VERSION from "1.5.2 2024-04-30"
to "1.5.3 2024-06-21".
Perform `make www` to perform the above and test under macOS.
My original fix no longer worked, at least with clang in some systems,
because of more strictness in the compiler wrt implicit ints. As the
code does not use the Makefile but rather 'cc' (and in an unusual way)
'main()' now has an explicit int.
Also, what was previously documented as a bug to be fixed has been
changed to INABIAF as it was documented already. Thus it should not be
fixed. In fact the judges originally noted that if one specifies the
triggering input they should expect an infinite loop and compilation
failure.
Cody Boone Ferguson