Enhancement: improve the look and feel of the constructed HTML files #2006
Comments
:-) About that entry .. didn't you say I needed to fix something there in the README.md and maybe other markdown files? What did you have in mind (well besides the markdown file references on GitHub should be removed which I'll get to)? Thanks.
Good call on linking there.
As above. Of course I think I've done much of this work but it'll be helpful to see how the index.html files come out to know what has to change further.
I can see how that would be less desirable yes.
This is an example of disabling warnings i.e. the less desirable way, right?
Perhaps it'll be helpful to have all the html files generated so we can see what they look like here so I can know what to fix? And do feel free to assign this to me!
I guess in general complex ways should be weighed against the easier ways and what is gained/lost. Of course in some cases more complex is the right way to go but not always. I can see how a widespread problem would be better fixed at the source of course.
Speaking of such. What will the other html files (from other markdown files I mean) be using?
Agreed it would be good if this can be avoided!
True. That seems even worse than modifying the CSS file. I guess you agree there. Anyway feel free to assign this (and every other one .. I'll mention that in 5) to me. I'll be asking for a priority list too. |
Probably it is: that is untested and likely not needed. It was just a fake example. |
Just making sure. Thanks for assigning it to me. I presume you'll get back to me on the other things later on. |
We just needed a fake example to use. |
They ARE generated OK, as mentioned the higher level HTML files and the winner HTML files that are not It was a milestone that we had been working on for months. It was why we asked to hold off on edits being made to the manifest numbers spreadsheet until now. It was the reason for the creation of all those new issues, etc. start side noteWe are actively working on generating the rest of the HTML files (see the TODO list of issue #4): racing to try and finish issue #4 before the other ((top primary)) issues are completed. For a number of people, work on issue #2 and issue #3 might seem nice, but as they might not take the time to try all of the IOCCC winners of the past, they might not understand the full benefit .. that it until they are looking at past winners for ideas and discover that they actually have a reasonable change to download the core, compile it and run it today. Sadly it will be the look and feel that will catch the attention of most people. The winner If we were make a new accouchement now about the work done so far, and people see a bunch of broken links, missing HTML files, etc. it will be hard for some people to perceive the tremendous progress that was made by issue #2 and issue #3. Thus we have be working very hard to race to try and get the look and feel ready so that your important efforts may present themselves in a good light for others to see. end side noteAnd as the top comment suggests, much of the work will likely involve editing the |
For this issue, only the winner When other HTML files are generated, there will be other issues to review them: likely 2 more issues that will be created, one for the winner non-index.html files and one more for all of the top level HTML files, one those HTML files are generated in the first place. |
Sure .. but I was thinking of in general. But I'll worry about that later on. Thanks. Still what problem existed in I think you said 2020/ferguson1/README.md ? That way I can correct it. |
Right but I thought you said some days back that that file needed some fixes? |
No .. you did indeed mention it. I was thinking of something specific but I'm afraid I don't know what it is now. Maybe it's already fine as it is. That's possible - it might just be I have to look at the rendered files to find errors.
Of course.
I remember you saying that yes. And I wish I had thought of the fact that I know of some errors in one of my entries. Wrong file name. Well I won't do that today. The manifest task is taking too much for me today. I really don't know why I am so exhausted today but I am.
Hmm yes I can imagine that. I don't think nearly as many people understand how many entries no longer worked and how almost all of them now do. And the ones that don't I think work in some platforms. In one case I'm pretty sure it has to do with the version of perl in macOS, as to why it crashes. I think this based on the author's remarks. Even those that do they might not care as much as the look and feel as you say. Presentation etc. seems to get to people in ways that sometimes goes to quite some extremes. The flashy websites being something that so many people like (even if the content is not quality) is a classic example.
Thank you very much! I needed to hear that! When I'm done with that other issue, 3, I will look at the rendered files and then go from there. It is probably better that order anyway since that way I can be sure the html files are up to date. As noted in another issue some are not now (though they're being updated). Then if a file name changes or a file is added or removed or that also means the index.html is out of date. So better to finish that first. Though I have to say today the manifest one is getting to me. But that's because I'm extremely tired - more than usual - and also probably because it's my first time with the very long process.
That's true and it's also true that there will be broken links. Let me say that differently: there ARE broken links. That includes from typos on my part (normal typos that I haven't gone back to 'zoom in on' yet and also it's possible I had the wrong link to type .. and then there are other things too).
Yes. I'm still doing that of course. I think manifest issue is about done, what I'm working on, so I'll post this and hopefully be making a pull request shortly. |
|
Added an "UPDATE 0" to the top level comment. |
I did like the 2020 version of the entries' index.html files and the year's index.html too but I also liked the way you had the index.html files here. Speaking of such I thought you had linked to an example index.html that was rendered as html. I can't find it now though. Can you post it again please? Thanks. That'll help I think. |
Then are rendering on the GitHub pages for the web site such as: https://ioccc-src.github.io/temp-test-ioccc/2020/ferguson1/index.html Better still one can view them locally on macOS using the built in Apache server as needed. |
The GitHub version is better for me actually. Thanks. Would you mind adding a link to it in the todo list so I am sure to not lose it again? Thanks. |
|
Speaking of such I see a problem with the index.html files ... They should list more than just name and location. In particular they should list URLs and also award title. Where should this be fixed? And if it's later in the file I think that's a mistake. A lesser matter is I'm not sure if the 'Author' heading level is right. But I'm not sure if it's wrong either. Seems smaller though and maybe it shouldn't be? But I don't know and the more We could have the author information at the top level 1 (as in |
As mentioned in the top comment: HINT: We recommend using the method outlined in comment 1893176110 on a macOS machine to examine HTML files before pushing changes to the repo. This allows you to first check and test HTML files on your local machine before pushing out a commit for a pull request. |
I meant to see what they look like now. I was too tired to think of more details but that's what I was getting at. |
Addressing any such missing information is probably premature given the ongoing actions are mentioned in comment 1928224505. |
Just wanted to bring it up. No rush on my behalf. I'm afraid I won't do more than the manifest that I did today .. too tired and too much on my mind. I'll do more tomorrow. |
|
FYI @xexyl , the mention of the IOCCC award for a winning entry has been addressed in |
Thanks for the update. |
|
Also FYI: @xexyl , the questions about formatting such as 'Author' heading level has been addressed in |
Thanks! I am going to get myself to bed now. I don't know what I will be able to do tomorrow but hopefully I can do a bit. If nothing else I should be able to start back at doing more in the days after my birthday - though as I said there are a few days after it that will be slower. Enjoy the rest of your day! |
|
We believe we have addressed all of the current questions that still need answering at this time. If we've missed something or something else needs to be clarified, please ask again. |
|
See commit cc73503 As a result, from the top level make quick_wwwand try: make wwwamong other things. :-) |
Nice. Thanks! That'll be helpful. I guess I can update the manifest tool I wrote to do that too but we'll see. Will hopefully do some things tomorrow morning. Just spending a couple more hours and then probably will get sleep: very tired. |
lcn2
changed the title
Added to the top TODO comment. |
Thanks! |
SuggestionAt the last entry of a year if there is another year, have at the menu (at the top where it shows previous entries) a link to the next year (not sure what it should be if there isn't another year). Might be good to have this for previous years too if that's not already there (haven't checked). |
|
Should binary files (like in 2006/toledo2) really use .. considering the manifest says to not display via GitHub I'll change it in the README.md files. Doing manifest updates. Not sure how far I'll get but I figured out how to do it so I'm making good progress! |
Correct: Binary files should not use
👍 |
Already fixed but thanks for confirming!
I'm trying to get it done so I can do other things. I figured out if I sort by entry_text field it works out well. Unfortunately I have a lot to do still and not sure if I'll have the energy to do it all today. Or maybe the patience as I have other things I'd like to do too. Still making good progress and mostly it's quick. I have made fixes and I hope that when done the other issue can be closed though with the caveat that when I go through the html files I might have to make fixes still. |
|
With commit 69c38e0 an interesting "failure to report an error" bug set was fixed. These bugs hid the impact of markdown bugs that went unnoticed ... until we were looking carefully at messages that should have been reported as fatal errors. |
Thanks for the note and the fix (though I had already seen that some fixes were made)! I hope to look at the repo again tomorrow but I am afraid it might be a few more days. We shall see. |
|
As I noted in a comment in #5 I might have come up with a way that will give me more time to work on this repo. I doubt very much I'll do anything today here though I do have some fixes in the other repo I just remembered. But I was wondering something... Several of the scripts have the gross hack because of the no On that note I was pondering something. Although it might be good for me to do the code that uses the low level json parse tree code (as it would be good to since I have the jparse repo) it might also (when the time comes to work on the three tools) speed things along a bit if we co-develop it like we did the parser itself. Just a thought. But for instance you noted that there are some things that have to be done with the option parsing that I am not sure I even followed and that could be done by you, for example. And it might be you do some other parts too. Of course I can do it all but if we were to co-develop it it would speed things along I'd think and that would mean the mock context could be here sooner. Just a thought that might or might not be worth much. I do have some minor fixes in that repo (documentation related) but then I'll be doing other things for the rest of the day. Those changes incidentally are already done I just have to update the changes file and then do a commit. As for my thoughts on this comment: I really don't know if it would be worth trying to get rid for the need of the hack but it crossed my mind so I figured I'd bring it up just in case. It would slow the progress down here and since the hack at least works it might be fine to keep it in place until the website is in good shape but I'll leave that to you. Of course if we were to do this one functionality it might also mean that things would have to be done over again. Actually I had the thought of adding to the top (in comments) that those tools are likely going to be mostly rewritten if not entirely rewritten but that's for another day I think: it's getting to the point I should be doing other things and then I'd like to do some other things that although not required I would like to do. |
|
Suggestions for the authors page. I don't know if Maybe you disagree but thought I'd bring it up as I think it'd make it a bit nicer. Anyway off for the day. Back tomorrow or the weekend (if not Friday)! |
Problem with
|
Post Great Fork Merge, writing tools such as The The code raceWe are racing to get the submit server in such a state where reasonable screenshots can be taken and the Once the above mentioned "code race" is nearly done, we plan to close this issue in whatever stare it is in (with only about two weeks notice) and start the final TODO tasks of issue #2239 (the Great Fork Merge). The important implication of "closing this issue in whatever stare it is in (with only a week or two notice)" is that any web page problems will go live on the Official IOCCC Website. Once the Great Fork Merge is done and the site goes live, any fixes to the Official IOCCC Website will be most "slow walked", updating the web site once every few weeks so as not trash the contents of the site like we do to the temp-test-ioccc web site. So NOW, while the "code race" is not yet close to the "finish line", is the time to complete this issue .. while we can. |
We seem to recall that such modifiers in a header HTML was flagged as problematic by the HTML 5 checker, but we could be mistaken. Until we verify this, please don't add such modifiers (including italics and other) inside the header stings. UPDATE 0
Please cite some examples (say 2 or 3) in a comment below, of where, in the authors page, you want to modify <h2> strings so that it would stand out. |
Okay but if the FAQ has to be modified towards the end (or kind of towards the end) should I not evaluate that file yet? As for the other web pages I'll do my best. I'm still not sure I can say I'm fully recovered from surgery but I think the real trouble is problem of being exhaustion. I'm sure I'll get it done but I do feel like it's going slower than I'd like. I have some other things I have to take care of too but the one in mind can wait a bit of time (and indeed it must wait some time). I will see about looking at this issue tomorrow. There's no way I can finish it in a single day but hopefully I can get a fair number of years done - or a few of the other pages that aren't years of the contest. I do think that most of the entries are probably in good order already: maybe a few changes in the manifest here and there but probably mostly okay. I imagine that formatting is in good shape too but maybe some needs to be fixed. I do think that being able to scroll down the pages looking for formatting and not worrying so much about content will greatly speed things up - as long as I can focus my eyes enough to see. And that is a big problem lately I must admit. But even if I have problems with that I still can go over the files even if by some chance the job is not as good as it would otherwise be (but of course it might be fine). |
|
Go ahead and work on the FAQ now. When it comes time to update the FAQ for registration and the FAQ for submission, we can just evaluate the change after the update. |
That's a good idea and for that file I think it's probably good that I read through it to make sure things look okay or at least skim through it. Maybe I can do that in the coming days. |
|
May I suggest a change in the stylesheet and an element in img{height:auto;max-width:95%;position:relative;}and then for the <meta name="viewport" content="width=device-width,initial-scale=1.0">The reason is without this images are not responsive. See the screenshot below for what I mean:
As you can see you have to scroll in order to see the image instead of it scaling based on the device screen size. FYI: this comes from my IOCCC web site but I've used it for others too. |
As per [comment-212792541](#2006 (comment)) we have added HTML italics around the "float" in "f is for float" HTML header. Perform `make gen_authors` to test the above.
With commit 194e0ad and 1289003 the "a is for It turns out that HTML header tags (e.g., Thank you, @xexyl, for suggesting this change. The "a is for atoi" is a fine IOCCC tradition. FYI: The "a is for atoi" was a C language variant and nod to the much older needlework sampler:
that was practiced by some our ancestors of the last few centuries as well as a nod to a common Nursery Rhymes so that same era. Your suggestion helps present this IOCCC tradition better. BTW: We changed the letters to lower case, out of a long standing tradition of lower case letters. on lower caseAs a bonus thank you, we offer this historical perspective on lower case: See Teletype Model 33.
|
We are working on this, but as an FYI, <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">Stay tuned ... UPDATE 0
With commit 07b8fcc and dacfdd0 the above request has been processed.
Thank you @xexyl and feel free to make other recommended improvements to |
Fair request, @xexyl. With commit 36ab67d we will do a combination of:
Now |
|
We believe we have addressed all of the current questions that still need answering at this time. If we've missed something or something else needs to be clarified, please ask again. |
Thanks for all this history! I agree with the lower case of the letters and I almost mentioned it. This comment is a lot to reply to and i have some things I need to do but it's also a lot of great stuff with some questions I might have too. I am not sure if I'll get to it today but I hope to. Still I feel like it's already afternoon even though it's only a quarter after 8! I feel like it'll be a slow day but it was a hard night (I think - it feels like it might have been) so it makes sense if it is slow. |
|
There's a bug with GitHub website right now (or maybe a glitch is a better word .. for certain definitions of glitch :-) ) that is preventing me from quoting comment 2130333823 so I'm going to reply to the comment without context. First I had forgotten about the inc/ header file. I had to try loading it on the old phone due to cache and it works fine: thanks for adding my fix! |
Thanks! I noticed it touches other files too but I forgot to mention those. Not sure if your fix takes care of those too. I'm running |
First of all I know you're busy with an emergency: I am happy to wait on the below.
Thanks!
Ah yes .. standards. What to say?
You're welcome! I wonder though: should the
Would you please explain, when you can, how the needlework is related to this? Also what do you mean by a C language variant?
I am glad. I offered up another thought above too.
I almost said something about it and probably would have, as noted earlier, so I'm glad you did it.
I knew that older terminals only had upper case but I did not know the other part (or I don't think I did .. maybe some): thanks! By preference to lower case do you mean in the unix/programming/C world specifically, as I think?
'Low cost' ? :-) ... I remember though when 1GB HDDs first came out: those things were bloody expensive too! And 'they were enough for a lifetime' too ... how funny how things turn out sometimes!
Did you have to do this too? Of course that's also not ergonomic.
And hence
I imagine that they could!
And still is of course.
Interesting! That makes sense of course. I know that Ken Thompson joked about how his only regret is that he didn't spell Thanks for the history! I'm going back to some reading now but I hope tomorrow I will be able to work more on the repo. I have company coming in a bit so won't get as much reading done as I'd like but should be nice. Anyway best wishes on the trouble you have to fix! I guess we all are familiar with some company or entity removing some service that was vital or useful without a concern for the people it affects. I certainly am. |
Hmm ... |
|
The is for suggestion I made was done (script updated and rebuilt html file) in 0239463. |
I figured out the problem here! It seems like it might not be possible to resolve either in which case I will have to just be careful with not committing those files (checking them out first to undo changes) unless I can add a check that would improve the script some to prevent this problem from occurring in the likely rare cases it happens. But it's strange: from all signs and tests I have made it should work. What's more is that it's not updating the news date to the current date but rather a date some days ago. See UPDATE 0: I might have found the real problem and I'm not sure why it's happened. Perhaps I can correct it with But the script properly detects that the stat(1) I have is NOT the macOS (well I have it but my PATH has GNU stat(1) from MacPorts in front of the macOS paths). Also the stat(1) command given for the RHEL stat command gives correct output. But here's the thing: in Rocky Linux (also RH based) it also does not work: the date is updated too but even more bizarre is that the date is different. UPDATE 0Ah! The news.md file has a different mod time ... In rocky linux: TZ=UTC stat -c '%y' news.md
2024-05-04 13:57:27.239661473 +0000and in macOS: TZ=UTC /opt/local/libexec/gnubin/stat -c '%y' news.md
2024-05-24 17:24:43.577475609 +0000So everything is actually working correctly but the timestamps are messed up. But why? ... still I made a change (not committed yet) that does UPDATE 1I figured it out. I thought it would take the timestamp from the repo (as in the commit time) when doing a checkout but apparently not: it takes the time of the checkout as the mod time instead and since I had to do a checkout before (for different reasons) the timestamp got changed. I wonder if this is a problem. It might be because someone who forks the repo and then clones their fork to make a change and does Can you think of any solution to this problem? The way the previous script that I wrote worked it did not try and detect a change in timestamp but rather only updated the values if requested; the rest remained the same. But your model is what you need (and after all mine was a potentially temporary one) so that can't work I think? But obviously this can be a problem. UPDATE 2Perhaps a file with the last update timestamps of the relevant files that the script can read from instead? That file would have to be maintained either manually (not good way) or else add an option to the script to update the respective timestamps in the file. I'd be happy to do that but you might have another thing in mind and maybe it's not even a problem worth fixing in your mind. It's just a possible solution if solution is the right word. But then again it would kind of defeat the purpose. That makes me wonder though if the last mod time is a good way to go about it. Unless no other make rule runs Well anyway this is the explanation. |
All generate HTML web pages are covered by this issue.
This issue covered all generated HTML files, including generated entry
index.htmlfiles, top level web pages (both constructed form data such asauthors.htmlandyears.htmlas well as top level HTML files generated from markdown such asjudges.htmlandnews.html) and year level 'index.htmlweb pages,bin/index.htmlandarchive/historic/index.html`, etc. If the web page is generated or updated by a bin tool, then that page a candidate for this include the "look and feel" issue.This issue focuses on these web pages "look and feel".
This is NOT about fixing content errors. (Well if you see something glaring, go ahead and fix it). This is about how the generated HTML pages look in a web browser.
Here are the types of questions ask about a generated HTML web page as viewed in a browser:
We are NOT focusing on the accuracy of the generated web page per se (although if you see something glaring, feel free to fix it under the guide of something that slipped passed the issue #3 effort). We are focusing on HOW it LOOKS with an emphasis on correcting dysfunctional presentations.
In many cases, corrections can be addressed by editing some markdown file such as the entry's
README.mdfile. Please modify the entry'sREADME.mdfile and re-build the entry'sindex.htmlin a pull request.If, however, you see an issue that may be more a matter of changing
ioccc.cssor the related bin tool, please raise the matter as a comment in this issue #2239 so we can discuss the matter before editing the CSS and/or bin tool. Again, this is less likely to happen, but if it does, we recommend a comment related discussion first. Modification to the entry'sREADME.mdfile can be done directly via pull requests.We also want to address any fix all REASONABLE "validation errors and warnings" as reported by the "Nu HTML check this web page". We emphasize REASONABLE because in the past, we have found some of those "validation errors and warnings" to be on the pedantic side of things. Moreover, when it comes to the HTML generated by
pandoc(1)we may not have much room to fix things.See also comment-2101733908 regarding links to markdown files, links to GitHub, relative links, and links with %%TOKEN%% symbols.
Please note that the top index page of this repo, as rendered by GitHub, is https://ioccc-src.github.io/temp-test-ioccc/index.html.
The text was updated successfully, but these errors were encountered: