Comments/Ratings for a Single Item

When I look at my list of authored items they are showing "Missing description"

How do I amend this?

Add descriptions.

I have added overflow-x: auto to the main section when there is an ad on only one side. This seems to stop overlap problems when it otherwise can't narrow enough.

Since this site has much more bandwidth available than it actually uses, I'm not going to gut functionality to save on bandwidth.

to Fergus

Yes I will add some descriptions at least

But where do I go to do this?

Go to the bottom of each page, click on Links, and enter a description.

Thanks, I'll come back and perhaps add some when I can

It doesn't matter too much as I write descriptions within the page anyway

Thanks for the answer

Since this site has much more bandwidth available than it actually uses, I'm not going to gut functionality to save on bandwidth.

Wow, I would never have guessed that, from the number of times that I get the message "This server is currently not available due to maintenance or capacity problems". Or from the time it requires to load pages...

And why do you think it would require "gutting functionality"? Proper design is usually not an enemy of functionality.

Wow, I would never have guessed that, from the number of times that I get the message "This server is currently not available due to maintenance or capacity problems". Or from the time it requires to load pages...

If the server ran out of bandwidth, you wouldn't be getting any message from the server, and pages wouldn't load at all. Also, multiple servers just call themselves the server. There is also the MYSQL server, the Apache web server, and the PHP server. I'm not sure which one is giving this message, but I have since optimized a lot of PHP code and MYSQL queries.

Between using WIFI and being on the other side of the Atlantic, there might be a slowdown for you. I often find that WIFI is slower than a direct ethernet connection to the router.

And why do you think it would require "gutting functionality"? Proper design is usually not an enemy of functionality.

I have no idea what improper design you have in mind. The code you mentioned serves a purpose, and getting rid of it would be gutting functionality.

Especially since in the shown case the banner is not 'squeezed out' at all: there is plenty of space to display it.

The banner is centered on the screen, and as soon as there isn't room for it to remain centered on the screen between the logo and the share widget, it drops down lower.

It doesn't matter too much as I write descriptions within the page anyway

The link description gives someone a reason to visit your page, and a description on the page itself would not serve this purpose.

I have no idea what improper design you have in mind. The code you mentioned serves a purpose, and getting rid of it would be gutting functionality.

Well, I wasn't suggesting you were just using that code as a filler to drive up hosting costs. But if the code to serve that purpose is nearly the same for nearly every page, the proper design would be to locate it in a separate file, and just put a link to that file in all those pages. Then the code would need to be loaded only once for every user visiting the site, and all pages he would access for a long time to come would use the version cached in his browser.

What do you think requires more functionality on this page, the menu bar, or the interactive diagram for Golden Age Chess? Now take a look at the page source. The diagram makes up about 25 short lines of that, the menu bar about 500 sometimes excessively long lines (line 11-59 for in-page style definitions, and line 80-513 for the HTML and JavaScript). The HTML source of all pages here seems about 10 times as long as one can reasonably expect from their content.

The banner is centered on the screen, and as soon as there isn't room for it to remain centered on the screen between the logo and the share widget, it drops down lower.

Indeed. This is a bit like explaining to a person whose house you just set on fire how chemical reactions with oxygen work, so that what he is seeing is a quite natural phenomenon, and nothing to worry about.The point is of course that it is wrong to require that the banner is centered when there is obviously not enough room to center it in-line with the logo. What is so important about centering that banner that justifies it taking extra vertical space pushing content off screen? Who would die if it was right-justified instead?

No website I have ever seen does this with its header. Have you conducted a poll under users, and did the majority all say "Wow, this is really how a page header should look! Amazing no one else ever invented such a beautiful layout!" when you presented them with the header screenshot I posted? I would be surprised if you could find anyone who didn't think it sucks big time. Worrying about how much a descender of a capital Q protrudes under these conditions seems a very strange priority.

to Fergus

Is it simple and straightforward to use the link description

I don't kow how to use it - perhaps someone could tell me

But if the code to serve that purpose is nearly the same for nearly every page, the proper design would be to locate it in a separate file, and just put a link to that file in all those pages.

That's a good idea. Stick to offering contructive solutions, and you will be good.

What do you think requires more functionality on this page, the menu bar, or the interactive diagram for Golden Age Chess? Now take a look at the page source. The diagram makes up about 25 short lines of that, the menu bar about 500 sometimes excessively long lines (line 11-59 for in-page style definitions, and line 80-513 for the HTML and JavaScript).

To be precise, code should be measured in bytes, not lines. My JavaScript for the menu takes up 7474 bytes, while your betza.js file takes up 57,438 bytes. Your comment with the Golden Age Chess diagram adds 1237 bytes.

The HTML source of all pages here seems about 10 times as long as one can reasonably expect from their content.

That doesn't seem to be based on accurate measurement, and it is probably incorrect.

Indeed. This is a bit like explaining to a person whose house you just set on fire how chemical reactions with oxygen work, so that what he is seeing is a quite natural phenomenon, and nothing to worry about.

That is a completely disingenuous analogy. I was explaining why there was no more room for the banner ad when there appeared to be more room for it.

The point is of course that it is wrong to require that the banner is centered when there is obviously not enough room to center it in-line with the logo.

That is a matter of personal preference, not of morality. Do not imagine that every personal preference of yours carries the weight of morality.

What is so important about centering that banner that justifies it taking extra vertical space pushing content off screen? Who would die if it was right-justified instead?

Who would die if you had to scroll the screen? Do you know how ridiculous you sound?

No website I have ever seen does this with its header. 

So what? Argumentum ad populum doesn't work with me.

To be precise, code should be measured in bytes, not lines. My JavaScript for the menu takes up 7474 bytes, while your betza.js file takes up 57,438 bytes. Your comment with the Golden Age Chess diagram adds 1237 bytes.

But the point is that it is almost never loaded, because when you have seen one diagram, you have seen them all: the browser caches the file, and keeps it around for a long time, probably forever as long as you regularly view diagrams (or until you decide to flush the browser cache for the page). If someone views 10 pages and has to load the menu script in each page, you are already up to 74,740 bytes. Load 20 pages per day for a week and you are at a megabyte.

The HTML description of the menus is also quite large, and could probably easily be generated by a JavaScript program (residing in a separate file shared by all pages). Or, when you don't want to rely on JavaScript, by including it from a separate URL through an <object> tag.

That is a completely disingenuous analogy. I was explaining why there was no more room for the banner ad when there appeared to be more room for it.

The analogy is about how this misses the point. The question is not about the cause, but about the reason. Why do you want to waste space on the page when there is no compelling need for it?

That is a matter of personal preference, not of morality. Do not imagine that every personal preference of yours carries the weight of morality.

That is just nitpicking over whether the use of the word 'wrong' is correct, against a non-native English speaker. Of course I do not mean that it is immoral or criminal to do this. Just that it is ugly, and an embarresment for the site.

Who would die if you had to scroll the screen? Do you know how ridiculous you sound?

Well, so what would happen that you want to avoid by forcing the banner in the center, that is so important than it takes priority over wasting vertical space on a page that doesn't fit entirely on the screen?

So what? Argumentum ad populum doesn't work with me.

Well, that seems to be part of the problem, then. Because very often there is a good reason why people do things in a certain way, and not in another. IMO it never hurts looking around to see what 'state-of-the-art' websites look like.

But to not digress from the actual issue: do you want to maintain that this staggered header design is just what you intend, better than any possible alternative and more usual design? If so, it raises questions about the status of this website: should it be considered an expressionist work of art, that people can admire or puke over according to how well their sense of aesthetics agrees with that of the artist, or is it supposed to service the chess-variant community in the best possible way.

@Fergus:  I agree with H. G. that the header droping like that isn't ideal.  Finding something better, IMO, would be good.

@H.G.: Wow.  You are becoming seriously cantankerous in your old age.  I've been reading your posts here and on talkchess for well over a decade and I've never seen you so agressive and adversarial.  You seem very upset.  I do understand having strong feelings about this site.  You have been a very active supporter of chess variants.  Between Winboard, Fairy-Max, your other engines, carefully evaluating piece valuations, etc., you have put an incredible amount of time into this area.  So it is understandable that you want this site to be as nice as possible.  I'm with you.  But this conversation is going down-hill.  You are now jumping from thing to thing, seemingly looking for things to point out to try to demonstrate that the site is a disaster, in what I would consider, frankly, a mean-spirited way.  I'd ask you to dial that back.

I would respectfully suggest: First, letting it rest for a day or two.  Then, we start freah, in an email thread with you and the editors, where we can discuss.  A public confrontation, which is what this is, is not helpful to anyone.  If we need community weigh-in on the subjective merits of anything, we can always start a new thread.  This discussion is no longer about typography anyway.

Well, I am not really upset (although I think I have every reason to be). What you see is more the result of problems I raise bouncing off from a wall of indifference, so that I have to storm the ivory tower with more force in the (re)retry. And when I make a helpful suggestion for improvement of something I happened notice when going through the page sources in order to assist in diagnosing the real problem, it is suddenly elevated to a issue in itself, rather than embraced, which admittedly throws the discussion off track.

I don't see any disadvatage in a public debate over something that concerns us all. (I mean, why open a thread on 'improving typography' if it is not to sollicit for feedback?). But if you rather conduct it by e-mail, that is fine with me. Is there some sort of mailing list for editors one can mail to, so that they get it all? As far as I am concerned we can start imediately; what I'd have to say in two days wouldn't be any different from what I would say now.

Public debate is fine if if it is constructive and corgial.  As for the belief that 'storming the ivory tower' is going to make people more receptive to your ideas, I can only respectfully disagree.

I know you bring a lot to the table and I value your opinion and I believe Fergus does too.  Lets try to take things one at a time and stay positive.  I will try to help but I must appologize for my limited utility as I know almost nothing about CSS and absolutely nothing about JavaScript (although obviously it's time I started learning.)

Well, when they could not possibly be less receptive, there is nothing to lose. At least it succeeded in attracting your attention.

JavaScript is nothing but a C-like programming language that is loaded from a website and executed by the web browser, and that can generate or alter the HTML on the page it comes with in any way it wants, spontaneously or in response to mouse clicks or key strokes. That is really all you have to know about it, if you don't want to write a program yourself.

This is not a discussion about technical issues anyway. It is about whether the site performs as it should for the majority of non-technical users, and whether we have a policy that sufficiently respects the work of contributors that do not happen to be editor or site maintainer.

I have noticed that the fonts Average and Volkhov are very similar to each other. Average is the font used for large screens, and Volkhov is the font used for small screens, though Malabar may be used in place of Volkhov if you have it installed.The main difference between Volkhov and Average is that Volkhov is darker and heavier, making it more suitable for small screens. The particular characters to look at to tell them apart are Q, 4, and the question mark: ?. In Average, the Q has a straight tail, the 4 is open, and the ? does not look like it would actually hook onto anything. In Volkhov, the Q has a curved tail, the 4 is closed, and the ? has its normal hook shape. Both are also very similar to Malabar too. Malabar and Average have similar question marks. Malabar's Q has a curved tail that is longer than in the other two. Its 4 is closed like Volkhov's, but the base of the 4 includes some serifs that Volkhov does not. Also, in Malabar, the T has top serifs, but in Average and Volkhov, it does not. In comparing Malabar and Volkhov, Volkhov is darker and heavier, yet it is also narrower. This makes it more suitable for small screens. Looking at individual letters, I prefer the A in Malabar and the Q in Volkhov. For other letters, I don't have a strong preference one way or the other. Looking at punctuation, Malabar has nicer quotation marks and commas, but Volkhov has a nicer question mark. Also, in Volkov, the forward and back slashes match each other in size and angle, but in Malabar, they do not, so that \/ and /\ look awkward in Malabar. Overall, it looks like Volkhov could be a better choice for the small screen than Malabar. So I'll try that out.

I have now compared Volkhov to Malabar on both my desktop screen and on my Kindle's browser, and Volkhov comes out the winner. On the desktop, it is much more legible. In comparing Volkhov and Malabar text side-by-side in two different Kindles, Volkhov seems to have the advantage. In Malabar, the 8 is bottom heavy, and the 9 is top heavy, but in Volkhov, these two digits both look more balanced. Also, Volkhov appears more legible, and I often notice that it fits more words onto the same line of text. This is not to say that Volkov is better in every way. In favor of Malabar, I do like its italic better, and I feel more comfortable with its top-serifed T. But overall, it looks like Volkov is the better choice. So, I have removed Malabar from the CSS, and each page will just choose between Average and Volkov, both of which are Google fonts, which means they will be used on any browser that supports Google fonts. In my experience, this is most browsers. For some reason, the one Android browser I actually paid for, Boat Browser, does not, but the default Android browser will.

I saved the JavaScript code for controlling the menu to two files, and the header now loads one or the other, depending on whether it is on a mobile device. I copied the code directly from the generated source code, setting the user agent to a mobile device to get the mobile code. I tested it on an Android phone and with Edge on a Windows tablet, and it worked with both.

Although I could use JavaScript to include the static part of the menu, it wouldn't be available if someone had JavaScript disabled. The regular desktop menu works as a hover menu, which can usually work without JavaScript. But for mobile devices and the Edge browser, the JavaScript controls are there for when a hover menu cannot work.

I shaved between 2 and 3 kilobytes of the header size by removing the domain from local images used in the menu.

I read somewhere that with a HTML <object> element you can (amongst other) include HTML from another file. E.g. I tried

<div style="background:blue"><object type="text/html" data="external.html" height="30"></object></div>

where I used the <div> with the backgroud color just to see how large the <object> was, and the file external.html just contained the text

<p>External HTML element</p>

This did indeed make the text appear in the place of the <object> element. (But initially with quite a lot blue space below it, which I could cut away by explicitly limiting the height of the <object>.

I wonder if this could be used for the constant part of the menu definition, or whether it would be harmful for the functioning of menus that there is an extra level of organization between the main menu bar and the sub-menus. Most likely it would work if you packed the entire <NAV> section in an <object>, but then I don't know how you would get the user-specific sub-menu.

But perhaps the 'HTML' that you include through the <object> can in reality be a server-side script. The browser would not know that, request the URL once, and cache what the script sent it, and then keep using that from its cache, rather than requesting it for other pages. If the script to provide a menu bar would need CGI arguments, e.g. for indicating which user (if any) it should customize the menu for, the browser caching will be smart enough not to confuse data loaded from the same script with different arguments. (I.e. it caches data based on the entire URL, also the part behind the '?'.)

If the user is automatically logged out, the main script for displaying the page would know that it has to generate a 'Login' sub-menu rather than a user-customized sub-menu, and it could generate a link to the menu-providing script in the <object> element with an argument that would specify the user is not logged in, and the menu bar would then be generated by the other script accordingly.

I haven't tested this, but it sounds like it could work. Once a user has cached both the menu bar customized for him, and the login menu bar, he would not have to access the menu-providing script anymore, no matter how many pages he loads. Unless he did something that would change his customized menu. But presumably that would change the argument in the URL to the menu-providing script (which could contain a kind of checksum on the contents of the customized sub-menu in addition to the user name in its arguments part).

I noticed that in some of my articles where text used to wrap around a diagram, this suddenly doesn't happen anymore. Some investigation revealed that this is due to the "float:left" style of the image being rendered ineffective by wrapping all of the article text in <SECTION> tags, which have a defined style "clear: both", forbidding invasion by floating elements. Before, only the section headers were wrapped in <SECTION> tags (so that new sections would not start beside a floating element), but the text itself could accept floating images.

Is this a new layout policy that is going to last? Currently the design wizard for interactive diagrams produces HTML for an image that would float left, but if floating is not possible, it makes little sense to do that. (And floating causes problems on the comments page anyway, because the individual comments are not wrapped in elementst that would restrict the range of floating to within them, so that a large image in a small comment would protrude into the comment under it. So if it is not functional elsewhere, I'd better remove it.)

It also affects the place where I would put the image in the source; if the text wraps it is usually best to define it at the beginning of the section, so that the paragraph actually referring to it gets displayed next to it, or just below it. If it would display without wrapping, it would be better to move the definition to just above the paragraph in the section that refers to it.

Ughh. Does this happen just because my FireFox on Linux is rather old, and buggy? On Windows this does not happen for me, and the pull-down menu displays nicely covering the main menu bar. I noticed you assign a z-index to the menu bar. Somehow the pull-down menu doesn't seem to get a higher z-index here.