A problem existed where in a superscript if there is a line immediately
above it the superscript text would cover part of the line and in
subscript the same problem occurred with the line below it.
This change can possibly be improved but it now does not cover text
(though admittedly I did not test the subscript before the change, only
after, but it seems highly unlikely it was not a problem).
This solves a problem with smaller screens where the code would wrap to
the next line which ruins the formatting of the code on smaller devices.
A downside to this is that it makes it not fit on the screen but since
it technically did not fit on the screen before and this way line breaks
are not added this seems a much better way. It also will mean we
shouldn't need to try and fix all the other long lines in code blocks
(which not only can be problematic but in some cases it can be wrong -
plus it is taking too much time away from moving from entry to the next
entry to the next entry).
As a trial, we change the `<pre>..</pre>` and `<code>..</code>`
blocks form "_Indigo_" to "_DarkGreen_".
We needed a colour that was **NOT** on the "_blue_ thru _purple_" colour
range, nor "_red_" that is currently used by links.
We choose "_DarkGreen_" as this is the same colour as the box around
quotes. Given that `<pre>..</pre>` and `<code>..</code>` text
is unlikely to be confused with a box around a quote, we felt this
was a safe colour to try.
While the use of `**font-weight: bold;` helps links standout in
most cases, there a few "_link heavy_" pages were the **MANY BOLD
LINK IN CLOSE PROXIMITY** looks excessive to the point of being
distracting. In areas where **nearly everything is BOLD, nothing
seems to stand out**.
Fortunately there seems to be only a very few places where this is a problem:
* `faq.html` - the table of contents
* `authors.html` - nearly the entire page
* `location.html` - nearly the entire page
* `years.html` - nearly the entire page
As an **bold** 😎 experiment we added to the CSS:
```css
/*
* To make a link non-bold, use: <a class="normal" href="url">link text</a>
*/
a.normal {
font-weight: normal;
}
```
And then modified select tools and a markdown file to "_unbold_"
those "_link heavy_" areas of the 4 pages above.
We don't claim that this is the best solution and there may be an
even better way to solve this, nevertheless we **do** think the it
improves the look and feel of the "_link heavy_" areas of the 4
pages above. For example, in `faq.html` beyond the table of
contents, the bold links look reasonable (although again there are
some quasi-"_link heavy_" areas down in the page look a bit too
bold, but perhaps not enough to warrant changing so we only altered
the table of contents).
In a few cases, while we were editing code that generated links,
we remove a few "**.**"'s where we didn't think they helped the
look and feel.
Change `bin/gen-authors.sh` VERSION from "1.10.3 2024-05-24"
to "1.10.4 2024-07-13".
Change `bin/gen-location.sh` VERSION from "1.4.2 2024-05-19"
to "1.4.3 2024-07-13".
Change `bin/gen-years.sh` VERSION from "1.3.3 2024-07-07"
to "1.3.4 2024-07-13".
Performed `make www` to accomplish the above and to test under macOS.
This does mean that in some cases there is now redundant markdown '**'s
to make the links bold but those can be removed as they are discovered -
or not.
Rather than have a literal vertical bar (|) for lines that indicate a
change from the last contest, it is now a CSS class which has a solid
black left border of 4 pixels. This not only makes it easier to see but
it fixes some formatting issues too (see below for tests).
This means that if a change mark is needed one can do:
<p class="leftbar">
...
</p>
A tip for vim users: in the .vimrc file add the following line
(temporarily or otherwise):
abbr leftbar <p class="leftbar">
Then you only need to type:
leftbar
and it will automatically add the proper block.
As for testing how this looks I have checked it with Safari with:
- an iPhone 14 Pro Max
- an iPhone 8 Plus
- a MacBook Pro 16 inch (both at full width and smallest width)
- an iPad Pro 11 inch 4th generation in both portrait and landscape
orientations
An important point that one needs to remember when using this CSS class
in lists is that one cannot do:
<p class="leftbar">
* foo
</p>
<p class="leftbar">
* bar
</p>
but rather do:
* <p class="leftbar">foo</p>
* <p class="leftbar">bar</p>
A problem was discovered in blockquotes for really long text, in
particular in the guidelines: 2305567963945518424753102147331756070. The
problem was that the number flowed outside the border. That should no
longer happen. Below is what should happen instead, though it's hard to
be sure how it will look in every case.
In Safari on a 16" MacBook Pro with Safari all across the screen it is
not a problem but shorter text will be in a smaller box (this means
the green box will vary in size depending on what is in it but this does
not seem to be a big problem).
With Safari in an old iPhone 8 Plus the box can go a bit further beyond
the screen width but text does not go beyond the boundary and one can
scroll left/right at need.
With Safari in an iPhone 14 Pro Max there is currently a cache issue but
earlier (when playing with different options) it seemed to fit and in
Simulator (in macOS) it looks good. However in Simulator earlier it was
fine even when the iPhone 14 Pro Max was not.
In responsive mode in Safari with a small width (400px) it is the same
result as the iPhone 8 Plus.
Finally with Safari in macOS with the window decreased in width it is
fine but it already was fine because it doesn't go to the size of a
phone (though it has helped fix problems with phones).
I have changed the font-style to normal (was italic) in blockquotes also
as this way italics can show up specially if requested.
The guidelines had some line breaks in the blockquotes that were
problematic; these have been removed as they are not necessary and it
did not look good either with smaller width screens.
More testing will likely be useful but it should be a lot better now.
It is very hard to find a shade of green that works well in all cases
against the white background and as already established blue and purple
cannot work (and some of those would be hard to work with especially
purple unless very dark maybe). Many possibilities were proposed but
they all seem to be a problem so instead of changing the text to green
there is a border on all sides now (forming a box or if you wish a
'block') and the text colour is black. The box / border is dark green.
The text style is still italic but it is unclear if this is wise. On the
one hand quotes are often in italics but with italics in quotes it means
that any quote with italics will not have those italics stand out.
Tested this change in two different forms: a blockquote where there are
blank lines in between the other lines (it's a dialogue) and a back and
forth dialogue broken up between text that is not a blockquote and it
looks good both in macOS Safari and Safari with an iPhone. This test
involves an entry from 1984 (anonymous) that should have been using
quotes instead of code (and now does but will be committed next) and it
does mean that a quick look over the earlier years for code versus
quotes has to be made but that should not take much effort or time.
There are many fixes made but a few questions remain so when I reach
those years I will address those then. Unfortunately, due to
infrastructure work right now, this is all I can say even though there
are a number of things I'd like to say.
There is no need to have 'blockquote' in one place and then later on in
the file '.content blockquote p'. This brings the two rules together so
one does not need to go back and forth in the file.
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.
*/
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.
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.
We add the following default IOCCC setting to `ioccc.css`:
```css
img {
height: auto;
max-width: 95%;
position: relative;
}
```
We also modified `ioccc.css` to use consitent 4 space indentation.
No other `ioccc.css` changes were made.
The icons used to show the menu open (`png/hamburger-icon-open.png`)
and closed (`png/hamburger-icon-closed.png`) have been added.
Changed `inc/topbar.default.html` to use the png icons instead
of a svg file.
A new page `nojs-menu.html` has been added for when
JavaScript is disabled.
Changed `bin/gen-top-html.sh` VERSION from to "1.4.4 2024-04-21"
to "1.4.5 2024-04-23".
Sorted top sections in `inc/md2html.cfg` and added
a section for `nojs-menu.md`.
Fixed `ioccc.css` so that the topbar and related pulldown
menus had the correct background colour.
Ran `make www` to perform the above.
TODO: Detect when JavaScript is disabled and display:
Please
Enable
JavaScript
As a link to the new `nojs-menu.html` page.
TODO: Fix a problem on wide screens where some of
the righthand edge pulldown menus are cutoff.
TODO: Fix the 5 HTML 5 errors introduced by the topbar code.
The topbar, by way of JavaScript, now works
on mobile devices such as cell phones and
tablets.
Internal links for entries from 1984 thru 2015
have been adjusted.
Ran `make www` to perform the above.
TODO: Fix some color issues on topbar.
TODO: More testing!
Thank you, @chris-sab, for your excellent work and for helping us
commit this alpha version of the topbar.
As part of this work, the following HTML sections were removed:
* begin-row
* begin-leftcolumn
* sidenav
* end-leftcolumn
* begin-rightcolumn
* before-content
* end-rightcolumn
* end-row.default
Also added a new HTML section, just above the "header" section:
* topbar
The web site now as a more modern looking topbar, thanks to the
work of the contractor (GitHub user @chris-sab) who is working on
issue #2273.
Performed `make www` to implement the above and test under macOS.
TODO: Fix the Responsive Web Design to deal with
the new topbar system.
TODO: Improve the topbar. What is there now is
just an alpha version.
TODO: Decide what to do with `png/ioccc.png`.
Remove it make selective use of the image on certain top level
pages lower down?
TODO: The changes to `ioccc.css` causes some
formatting problems with pages such as `location.html` (missing
blank lines). Fix formatting problems as needed.
TODO: Fix the "Nu HTML check this web page"
links on things like the year level _YYYY/index.html_ pages.
TODO: Correct all HTML errors, warnings and perhaps
informative messages from the Nu HTML check.
TODO: Consider adding color (colour) to the
web pages in such a way that people with color perception
challenges can still use the web site.
TODO: For those web browsers that have and allow
JavaScript, make use of technology such as [Code
Mirror](https://codemirror.net/) to directly render source
code (C, shell, Makefile, etc.) with syntax coloring (colouring)
directly in the browser. For non-JavaScript browsers, fallback
to the current use of GitHub source code viewing.
This one of the parts of the change to the [look and feel
change](https://github.com/ioccc-src/temp-test-ioccc/issues/2273#issuecomment-2059754857)
wrote about.
Stay tuned ...
.. per a comment on GitHub suggesting none is not wanted. Again maybe it
needs to be in a different section or even different html element but
this seems to solve the problem anyway and can be experimented with.
In other words we won't see text like:
... See also the IOCCC FAQ for ad-
ditional information on the IOCCC.
As I am not sure of the formatting of comments and the organisation of
the different html elements it might be that the CSS for 'p' might need
new comments or it might need to be moved to another section in the file
(which I believe but do not know).
The inc/footer.default.html now has a common Copyright and CC BY-SA
4.0 License section for all generated HTML files.
All markdown files have a similar Copyright and CC
at the bottom in the form of an HTML comment.
By improving how padding is applied to the right column
and footer, the rendered HTML looks better.
There are still issues, but at least it does not
_suck_ as bad. :-)
The initial release of `bin/readme2index.sh` tool that converts
`READMD.md` and various JSON files such as `.winner.json`
as well as "author/author_handle.json" files.
Applied the `readme2index.sh` tool to generate `2020/ferguson1/index.html`.
We generated the `2020/ferguson1/index.html` by executing:
```sh
./bin/readme2index.sh -v 3 2020/ferguson1
```
NOTE: This above tool requires **pandoc to be installed**.
See the [pandoc web site](https://pandoc.org) for how
to install. We used _HomeBrew_ to install it,
but there is also a _macports_ process as well.
NOTE: While the above web page does have formatting issues, it is
a first attempt data driven programmatic web page generation.
Some adjustments can be made by mostly improving `ioccc.css`,
and some perhaps by modifying how `bin/pandoc_wrapper.sh`
invokes pandoc. But probably most of the improvements can
be made by fixing and improving `ioccc.css`.
TODO: Fix and improve the `2020/ferguson1/index.html`
web page by fixing and improving `ioccc.css`.
Moved scripts and tools needed to generate HTML pages
into a new `/bin` subdirectory.
TODO: Consider getting rid of the [build-ioccc
repo](https://github.com/ioccc-src/build-ioccc) and just use the
`/bin` subdirectory.
NOTE: Some links in the `2020/ferguson1/index.html`
web page do not (yet) exist.
TODO: Once the basic format of the `2020/ferguson1/index.html` web
page is somewhat reasonable, generate `index.html` pages for other
winners. Generate the year level `index.html' files.
Generate the top level HTML files, including the missing
`location.html` file.
Greatly simplified the `.winner.json` file format,
removing a number of fields that were not strictly needed
for generating an inventory on a `index.html` page.
Updated various versions:
* `bin/gen-author.sh` VERSION="1.3 2024-01-14"
* `bin/gen-inventory.sh` VERSION="1.0 2024-01-14"
* `bin/manifest.winner.json.awk` VERSION="1.0 2024-01-14"
* `bin/pandoc_wrapper.sh` VERSION="1.3 2024-01-14"
* `bin/readme2index.sh` VERSION="1.0 2024-01-14"
* `bin/subst.default.sh` VERSION="1.1 2024-01-14"
* `bin/subst.winner-index.sh` VERSION="1.1 2024-01-14"
* `tmp/gen_path_list.found.sh` VERSION="1.1 2024-01-14"
* `tmp/gen_winner_json.sh` VERSION="1.1 2024-01-14"
The `.winner.json` file format from winner_JSON_format_version
"0.5 2023-11-04" to "1.0 2024-01-14".
All `.winner.json` files have been updated to use the
new `.winner.json` file format.
The manifest (`tmp/manifest.numbers` and `tmp/manifest.csv`) has
updated to use the new `.winner.json` file format.
The following procedure was used to generate the
`tmp/manifest.csv` manifest file:
0. open [manifest.numbers](manifest.numbers) in numbers: modify if/as needed
NOTE: Please try to keep the [manifest.numbers](manifest.numbers) spreadsheet
in order order. Use Organize -> Sort -> ((Sort Now)) to sort.
NOTE: Empty fields in the [manifest.numbers](manifest.numbers) spreadsheet
are not allowed. By default, a cell that is empty is colored
as a warning.
1. File -> Export To -> CSV...
* 1a. `[ ]` Include table names (unset)
* 1b. Text Encoding: Unicode (UTF-8)
* 1c. Click ((Save..))
2. Save As: manifest.csv
* 2a. Select the `tmp` directory
3. Click ((Export))
* 3a. If needed click ((Replace))
4. Execute ./tmp/[fix_csv.sh](fix_csv.sh)
NOTE: You must run the [fix_csv.sh](fix_csv.sh) in the above
step in order to make the CSV file usable by other tools.
NOTE: If no changes are needed in the above step, the
original file content will be restored.
5. Execute ./tmp/[gen_path_list.found.sh](gen_path_list.found.sh)
NOTE: The above step silently performs a `make clobber` at the
top level, and so it takes a bit of time.
NOTE: If no changes are needed in the above step, the
original file content will be restored.
6. Execute ./tmp/[check_path_list.sh](check_path_list.sh)
NOTE: The above step prints nothing and for an exit 0, then
all is well. If there is a problem, such as files
found that are not part of the manifest, or files
in the manifest that are not found, then an error
message will be printed and the tool will exit non-zero.
If errors are reported, go back to step 0 and
correct the errors.
7. Execute ./tmp/[run_all.sh](run_all.sh) ./gen_winner_json.sh
NOTE: The above step will take a few seconds to run. It will rebuild
all `.winner.json` files for all winners.
NOTE: If no changes are needed in the above step, the
original file content will be restored.
8. Execute `git status` and inspect changes
NOTE: Check in changes if and as needed.
NOTE: In a number of shell scripts under `bin/*.sh`,
and in the `bin/manifest.winner.json.awk` script
you will find comments of the form:
```
```
This is a note that when tools such as `jnamval` (and `jval` and `jfmt`) are
ready, these gross hacks should be replaced with calls to those tools.
Until they are ready, some must be careful with the layout of JSON files.
A number of bugs and typos have been fixed.
NOTE: Fixing typos in the files touched by this comment is welcome.
This includes scripts, data files, text files, etc.
The _inventory_order_, _display_as_, _display_via_github_. and
_winners_text_ fields of the [manifest.numbers](manifest.numbers)
spreadsheet were just set to have some initial values.
As they impact the inventory displayed on `index.html` pages,
their content needs to be improved.
NOTE: Improving the above mentioned fields of the
[manifest.numbers](manifest.numbers) spreadsheet is welcome.
Added Left - class for placing things on the left side
Added Right - class for placing things on the left side
Added Disabled - class for making something as if the feature has been disabled
Improved Responsive Web Design, adjusted font sizes and scaling.
Now Default: screen is > 968 pixels wide (> 984 w/padding)
Adapts when screen is > 761 pixels (> 777 w/padding) AND <= 968 pixels wide (<= 984 w/padding)
Adapts when screen is > 500 pixels (> 515 w/padding) AND <= 761 pixels wide (<= 777 w/padding)
Adapts when screen is <= 500 pixels wide: (<= 515 w/padding)
Changed tmp/test,html to help test this new part of the CSS.
Now code, pre, mono font set starts with "Menlo, Monaco, Consolas"
before going to the other font defaults.
Established IOCCC defaults for body, pre, code, blockquote,
a (link, visited, focus, hover, active).
Added pandoc --standalone defaults for some property settings
that we NOT part of the "Establish IOCCC defaults" set above.
The assumption is that the tools that convert markdown to
HTML via pandoc will NOT use --standalone because we want
finer control over CSS. Even so, there may be good reasons
to go with most of what pandoc recommends: unless we have
good reason to NOT do so.
Reduce font size to 90% (0.9em) for screen that is >= 401 pixels
AND <= 800 pixels wide.
Reduce font size to 80% (0.8em) for screen is <- 400 pixels wide.
Added print media property based on pandoc --standalone.
This is still rather experimental.
The ioccc.css Cascading Style Sheet has updated.
This CSS will serve as a model for generated HTML pages,
especially HTML generated form markdown.
The top level HTML pages will also use this CSS.
This CSS is intended to be functional, black/gray/white, and
good enough for testing purposes.
Added HTML page templates that will be used
by tools in forming HTML pages:
* tmp/template-top.html
* tmp/template-header.html
* tmp/template-footer.html
See the modified
[tmp/README.md](https://ioccc-src.github.io/temp-test-ioccc/tmp/README.md#templates)
for info on the HTML page templates.
Added a test page containing dummy HTML:
* [tmp/test.html](https://ioccc-src.github.io/temp-test-ioccc/tmp/test.html)
This test page was generated from the above mentioned HTML page templates.
It is designed for 3 screen sizes:
* wide screens: 801 pixels wide and larger
* medium-sized screens: 401 pixels to 800 pixels wide
* small-sized screens: 400 pixels wide and smaller
NOTE: Some of top and side bar navigation links do not (yet) work.
If all goes well, the main web site can launch with web pages that
are based on the final ioccc.css. After the main web site is update,
a web designer can improve the look and feel of the web site by
adjusting the ioccc.css, the HTML templates, and the tools used to
generate HTML content.
The 2020 winners are hinted it, but the source code is not there,
nor are the hints. Someone could look into the HTML and
see what was commented out, but that is not a problem because
WHO won is known and the name of their AWARD is known already.
Moreover a number of the winners have talked about what their
entirs do, so the commented out spoiler text is not a bit problem.
One will find HTML commented out with:
<!-- XXX remove when 2020 is ready
2020 links here
XXX remove when 2020 is ready -->
The "XXX remove when 2020 is ready" string is found at the
start and end comment blocks. Again, soneone could read
what was commented out, but that is OK since most of that
information is known or can be known. The following files
have such HTML comment blocks in them.
./winners.html
./years-spoiler.html
./years.html
In addition, ./all/summary.txt was modified to not
include the 2020 entries for the momemt.
The 2020 winner code AND write-ups are NOT part of this set.
p.s. The all/all.tar.bz2 does not contain the 2020 source code (yet?).
Landon Curt Noll