Comments/Ratings for a Single Item

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.

Since we're talking about bugs, I often see what appears to be "code" mixed with the display.

Right now, just under the title, I see text which reads, "Database Query: SELECT * FROM Comment WHERE IsDeleted=0 ORDER BY CommentID DESC LIMIT 25"

At least I assume this is a bug. I don't know what it means, and it just takes space away from the other (usually) interesting stuff.:)

I noticed that in some of my articles where text used to wrap around a diagram, this suddenly doesn't happen anymore.

I noticed this happening on your Interactive Diagrams page, but I assumed it was your doing, since I had just previously fixed the problem with this page.

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.

Wrapping each section in its own <SECTION> tag should have nothing to do with it, and this has been what it does since at least last year. The only change I made recently was to change the lower sections after the first two to display as blocks. This would not affect anything in the first two sections, one of which will usually be where your diagram is found. It will also not affect the ability of elements within the section to wrap around each other. The CSS code you're referring to looks like this:

<STYLE>
MAIN>ARTICLE>SECTION + SECTION {display: block; clear: both;}
</STYLE>

This is for a section that follows after another section that is an immediate child of an article that is an immediate child of main. So, it would have no effect on the first section, which is where your diagram is on this page. Besides that, the "display: block;" section is overridden by the "display: inline;" that appears in the HTML for the first two sections. If "clear: both;" had had the intended effect, I would not have needed to change the other sections to display as blocks, which I recently did to stop the text of the Pieces section from wrapping around stuff from earlier sections. Anyway, this code appears to be useless, and deleting it has had no effect. So, it is not the cause of text not wrapping around your diagrams.

I have noticed that your diagram has a very large margin of 40px. I'm not sure if this is a recent change or not, but you could try reducing this margin or even changing it to a margin-right, since only the right side of the diagram needs some space from the surrounding text.

Looking at your Chu Shogi page, it looks like the CSS was still doing something. So I added back this:

<STYLE>
MAIN>ARTICLE>SECTION + SECTION {clear: both;}
</STYLE>

This stopped the Pieces section from wrapping with the Setup section, but it has no effect on content within the same section, and it doesn't affect the first section anyway.

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.

Could be. I checked both Firefox and Chrome on Linux, and I didn't have this problem. I have Firefox 55.0.2. running on Linux Mint 18. Try updating Firefox or running it without any extensions to see if that makes a difference.

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.

The menubar gets a high z-index so that it will fully display over ads that have a high z-index. I didn't do anything with the share widget code, because that comes from another website.

I ran a test of object with the following code within the left aside:

<NOSCRIPT>
<object type="text/html" data="/login/external.html" width=300>
</NOSCRIPT>

When I loaded the Comments page with JavaScript disabled, it failed to display the content of the file, it destroyed the formatting of the page, and it caused the main content to disappear. On another page, it made the left aside blank without affecting anything else. In both cases, it failed to do what it was supposed to and made things worse.
 

I have a long-standing problem. The ads are sometimes dead links, and when it happens, it gobbles up an incredible amount of screen space as shown below. Fergus and I have talked about it a while ago but he wasn't able to reproduce it. So my question to the community is - is anyone else seeing this or is it just me? I have the problem in both Windows 7 (Firefox and IE) and Linux Mint (Firefox.)

And when it happens, it's always a HoS link. For example: http://www.houseofstaunton.com/chess-books-1.html?acc=eb163727917cbba1eea208541a643e74&___store=houseofstaunton_en&bannerid=24

Strange. The ad shows up on the House of Staunton, and it does include height and width values that should prevent this. Right now, as I'm writing this comment, there is a House of Staunton banner ad that is showing only the TITLE text, but it is not taking up extra space. Curiously, none of these have ALT text. So I just copied the TITLE text to ALT text with a macro.

I should also mention that I do get some HoS ads fine- I have no idea what's wrong with this one, but it comes up a lot.

Greg, Is this problem not happening on Chrome? Or are you just not using Chrome enough to notice if it does? Most of the time I'm here, I'm using Chrome.

I don't really use Chrome.  Don't even have it installed on Windows.  I do have Chromium installed on Mint, as that's the only way I can watch Amazon Prime Video, and I just tested and it does seem to work - I refreshed about 50 times and didn't get the problem.  But this doesn't make sense to me; why should your choice of browser have any effect on whether or not a link is dead?  I do have a couple plugins for Firefox, but I've disabled them and it didn't make any difference.  And I don't have any plugins at all for IE, (not sure if IE even has plugins), and it malfunctions also...