Comments/Ratings for a Single Item

I was trying to change the font in BODY instead of MAIN ARTICLE, but since that was having some undesirable effects, I changed it back. But I changed it back incompletely last night, and the result I saw this morning was that it was using Volkov for large screen displays instead of Average. So, the font-size was the same, but the font was one with larger characters. I have now corrected that.

Looks like the fonts on most pages just got significantly larger and bolder.  A bit too much IMO.

I think I solved that problem with an order of precedence. The header will set .leftcol and .rightcol to display: none, but the CSS file will set values for ASIDE.leftcol and ASIDE.rightcol. Since these are more specific, the CSS will favor the values for these when they're available, and when they're undefined, it will use the values for .leftcol and .rightcol.

Since the header is included after the global CSS file, turning off the display of the sidebars in the header turns them off for good. So, I need some way to test whether the CSS file has already been loaded.

Something I don't understand is going on. When the page first displays, the Amazon native shopping ad is initially set to display: none, and then it is set to display: inline-block, and it is visible on the screen. But when I resize the screen, such that it turns invisible, and then I resize it again so that it should be visible again, it remains invisible. I think it is because it is a JavaScript generated ad, and when I make the window smaller and bigger again, it is no longer running the JavaScript that generates the ad.

That fixed the problem for most ads, but Amazon's native shopping ads are still not becoming visible again.

It looks like that was caused by setting display to block-inline, which is not a legitimate value for display, instead of to inline-block, which is a legitimate value.

One hitch I've found is that when an aside with an ad in it has its display set to none and then changed back to something visible, the ad sometimes remains invisible.

Last night I was expanding the text size in Chrome on my desktop. As I do this, it changes the viewport size that CSS reads even though it doesn't actually change the window size. When the viewport width was at 960, as reported by the Web Developer extension, both sidebar ads showed up above the content. As I understood my CSS, this should not have happened. I had used min-width and max-width to set various ranges, and all ranges seemed to be covered without any gaps. But at 960, which was at a cusp between two ranges, something was wrong. Further investigation showed that it was using the Average font for both body and italics, yet every range was supposed to use Volkhov for both or Average for body and Kurale for italics. So it appeared that only the default CSS was being used without any modifications from @media clauses.

I eventually figured out that this could happen if I misunderstood how min-width and max-width work. I had assumed that min-width returned true for any value that was greater than or equal to the size given and that max-width returned true for any value that was less than or equal to the size given. But it appeared that one of them was returning false when the width was equal to the size given, effectively working as the NOT of the other one. To fix the problem for 960, I adjusted the max-width of one range to 961. This allowed a width of 960 to work with that style, as I originally intended. So, it looks like max-width returns true only when the width is less than the size given, at least on Chrome. Maybe this is an undefined detail that will be different in different browsers.

So, to avoid this problem altogether, I should stick to using only min-width or max-width in my @media entries, and I should design the CSS to work for a default screen size that requires no modification from @media. My options are the smallest screen size and the largest screen size. I think I will go with the smallest screen size for the default CSS and add elements and make changes as the screen size grows. I will also add some CSS to the header to turn off sidebar ads by default, so that they will not show up above the content on pages that do not include the global CSS file.

If I use only one, then any given screen width may fit multiple @media conditions. In that case, I have to arrange them in a way that will apply the correct styles for a given width last, and I will have to take into consideration what has already been changed by earlier @media clauses. I have four choices. I can use either min-width or max-width, and I can go from narrowest to widest or vice versa. If I use min-width and go from narrower to wider, the first one, say min-width: 600, would modify anything with a width of 600 or greater. Let's say the next one is min-width: 960. This would modify anything with a width of 960 or greater. Finally, at some width suitable for widescreen desktop monitors, all previous modifications would have been made, and each would have to be corrected or continued. Since I'll be starting out with the narrowest size as default, it makes sense to me to do it this way. I wrote it out ahead of time to help me be clear about what I will be doing and to inform any interested parties on what kinds of changes I will be making.

The main thing to change in 2015 is that the website has moved to a new
host. This can cause unforeseen changes. Please let us know if you are
regularly having this problem or if it happens only on a certain computer.

Oh, you may be right. I missed the change of context.

I thought Charles's issue was with submitting edits to a MS page. 
Spellcheck is on the user's end though, and shouldn't affect the submission
script at all.

Perhaps there is a time limit on the submission, so that if you have a
large amount of text and a slow connection it times out while trying to run
the SQL in the submission script?

As far as I understand it, your problem is with the URL in the address bar.
Spellcheck should not affect that.

This is not a site that especially needs broadband, and I don't think
connection speed is the issue. My research tells me that early versions of
Internet Explorer have a length limit on the URL of 2083 characters, but
most other browsers and later versions of Internet Explorer do not have
this limit. So the problem could be that you were using an old version of
Internet Explorer.

My best guess is that you are reaching some maximum to the URL length. Different browsers may impose different limits, which may explain why this problem happens on one computer and not the other. While the drawdiagram.php query string includes only what is different from
the default values, the diagram-designer.php query string includes
everything from the form and so will be even longer. I could fix that
problem by making the Diagram Designer use POST instead of GET, though it
will then have the inconvenience of requiring you to refresh if you go
back. The one thing that might most expand the URL is the FEN Code,
especially if you use long piece names instead of single letters. If that's
the problem, you could make a set for the images you want to use together.

Maybe not a good time or place for this comment, but in case it hasn't been
already discussed, a future project (if any editor is willing) might be to
somehow show the names of members and editors who are currently signed in,
along with the number of other visitors, at any moment, like on message
boards I'm familiar with. A tiny immediate plus could be that I wouldn't be
wondering if I were all alone looking at The Chess Variant Pages. Perhaps even a website visit hit counter is an idea too. Also,
showing the time to the minute that a comment was posted might prove
desirable.

To editors and others, FYI:

At the moment I can't manage to sign in on the main page, though I succeed
in signing in when I try to do so via the Ratings and Comments Page, at
least.

I think I have escaping working properly for editing one's own
comments.  If you find no flaws there, then I will try to make similar
changes for new posts, editor functions, and then will move on to member
submitted pages.