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.

Conclusion: the cycle post - edit now strips two levels of escaping from
the text, instead of a single one.

AMPERSAND lt ; shows up as <, and I write a > to make sure it terminates a false tag. AMPERSAND amp ; lt ; shows up as <, and I write a > to make sure it terminates a false tag. AMPERSAND amp; amp; lt ; shows up as &lt;, and I write a > to make sure it terminates a false tag. AMPERSAND amp ; amp ; amp ; lt ; shows up as &amp;lt;, and I write a > to make sure it terminates a false tag.

...and now I can't edit my comments again.  I checked the script, my change
is still there; so I don't know what the problem is now.

Oh, sorry H.G., I was referring to Kevin Pacey's remark that editing
comments was impossible altogether.

I was delaying adding code to escape html characters because I thought
perhaps a new entry system might take care of it for me.  But now I think
it will take me too long to work out the details of that, so I will try to
add the escaping later today or tomorrow.

Perhaps the problems with your user-submitted page have to do with the
transfer?

It doesn't really seem so. In fact my member-submitted article on interactive diagrams was totally messed up even without me editing it, and the usual work-arounds for getting the less-tan signs to display in the HTML or escape sequences for them to be present in the embedded JavaScript do not seem to work anymore either, so I could not correct it by editing.

There are have been some hiccups while moving to a new webhost. I'll look
into this.

To editors, FYI

I'm having troubles editing my posts at times, until I make a fresh post.
Then I'm allowed to edit my posts for a little while, only, it seems.
Otherwise, when I've attempted to edit a post of mine what's been happening
is that I'm told I must sign in, even though it seems that I already am (in
fact, I don't think the 'edit' option for my posts would show if I were not
signed in). 

Anyone else having this problem?

Ben,

Can you make the comment system responsive rather than just designed for
mobile? The header sets a variable called $mobile, which can be used to
provide different code for mobile and desktop displays. Something like what
we used to have would be more suitable for the desktop.

If I can post this, the problem with posting to "We're Moving to England"
is that it has an apostrophe in the title, not that I made it before the
move.

Indeed, it seems important that the retrieval + resubmission (for the purpose of editing) does not alter what was not touched during the edit.

The problem seems to be that the submission somehow processes the submitted text TWICE for escape expansion. If I use a single escape for '<' (the usual &lt;), it has exactly the same effect as when I write a plain '<' (namely mutilate the text because it thinks what follows is a HTML tag). And indeed, after retrieval, it is a '<'. I have to escape it twice, writing &amp;lt;, so that after the first processing a &lt; is left. This is then printed as a '<' in the text rather than mistaken for a HTML tag, but on retrieval will only be singly escaped as &lt;.

This happens also during posting comments; you don't want to know what I had to write to get the above text printing as I wanted it... It doesn't matter whether you tick 'using HTML'.

Evidently the problem with special characters is an issue with textarea
elements in general.  From what I can tell, the best solution is to escape
all such characters when pulling the information from the database to
populate the textareas; then the textarea (for whatever reason) will
collapse all of that escaping back into what actually lives inside the
database.

I now equiped the article describing the interactive diagrams with a 'Design Wizard'. This will (after the user specified all the parameters and selected available piece images from a list) eventually show the HTML code he will have to paste into his own member submission to get the same diagram there.

In making this I noticed something very sick in the submission script:
Less-than signs are of course interpreted as HTML tags, but the normal way for escaping them (by writing "'ampresand' lt >" does not work: this is apparently already converted to a less-than sign during submission, and then interpreted as HTML tag anyway. It even does that within JavaScript things. The only way to make a less-than sign appear in text generated by the JavaScript is to use a double escape in the JavaScript strings: "'ampersand' amp ; lt ;" or in HTML text that you write yourself. Super-annoying thing is that every time you then edit the article it will have removed all "amp ;" from this, so that you have to substitute them back in by hand everywhere in the article where a less-than sign should occur!

I see that CKEditor can be extended with various plugins. Maybe there is
one that would make the HTML editor more sophisticated.

I looked at the demo for CKEditor. It seems like a powerful WYSIWYG editor,
including several features we won't ever need, but when I clicked
"Source" to edit the HTML directly, it ghosted out nearly everything. I
would favor something that is more sophisticated on the HTML end and a bit
simpler on the WYSIWYG end.

I was assuming the worst about possible malicious code; a bit of searching hasn't come up with anything that I am too worried about at this site. (As for editor review, I was worried about modifications to an existing page, which doesn't require an editor's sign-off; or sufficiently subtle scripts that wouldn't be noticed without examining the source.)

I did a little looking for a text entry system and right now I like CKEditor.

> So, perhaps, we could allow JavaScript on pages, though not in comments, and just police against any misuse of JavaScript.

Yes, this was what I was proposing from the start. It seems obvious that if you want to allow people to submit their own contributions, you should allow them all the tools they could get to deliver the best result. I don't know what kind of 'misuse' you are afraid of. It seems they could do little harm other than wrecking their own page. For which they probably would not need JavaScript.

If you want to minimize the work involved in policing, the submission form could get another checkbox "Using JavaScript" similar to the one we have now for "Using HTML tags", so that the editors reviewing the submission are made immediately aware whether they are dealing with a page that is static, or one with one that might contain surprises, and deserves some closer inspection.

One sticking point remains. Although I managed to separate JavaScript from
HTML, I cannot separate JavaScript from PHP. The JavaScript my diagrams use
includes arrays of spaces and legal moves that are written by PHP because
they are specific to a particular game. So, if we forbade JavaScript on
pages, no one would be able to include the JavaScript that is needed for
showing the legal moves in a diagram. Also, when we let people include
JavaScript files, they still need to run functions in those files. So,
perhaps, we could allow JavaScript on pages, though not in comments, and
just police against any misuse of JavaScript.

> Disallowing arbitrary use of scripts sounds good.

Actually disallowing scripts sounds very bad, in the member-submitted articles. There is no reason why the submitter should not be in full control over how the page looks, and what it does. We have an approval period during which editors review any contribution, so if it turns out that there can be undesirable applications of scripting, the contribution can simply be rejected. It is not like you couldn't do arbitrarily unacceptable things using pure HTML, or even only plain text...

This of course would be different in forum posts, like this comment listing, where the user postings share a page with postings of other users. In theory scripts could be used there to alter the way other people's comments are displayed in the client of anyone that views them.

I can add that several of my member-submitted articles now make essential use of scripting. I have incorporated the interactive diagram in most of those, now, and in most cases (such as Mighty-Lion Chess and Elven Chess) the standard betza.js script for the diagram is all that is needed. But the large Shogi variants (Dai Dai and Maka Dai Dai, and my shrunken versions Cashew and Macadamia Shogi) have unusual and complex promotion rules (pieces promote on capture, and whether such promotion is mandatory or optional, or even what you have to promote to, can depend on what you capture. Werewolf Chess also uses a contageous piece. This exceeds the general treatment of promotion the betza.js script can provide, so the pages need to define their own function to decide what the piece will become after the move.

For the Shogi variants I also provide buttons that switch the diagram between piece representations: mnemonic, western-style pictograms or kanji tiles. The 'onclick' specifier in those buttons does contain JavaScript snippets to alter values of variable used in the betza.js script, making it take the images from an other directory. See for instance the article Macadamia Shogi.

EDIT: I managed to get linebreaks more faithfully reproduced in non-HTML Comments, but some comments (for reasons I don't fully understand) had linebreaks inserted into them (after being edited?) that made this more faithful reproduction ugly.  Given two evils, I'll stick to the one that's been in practice for a while.

Hopefully we will incorporate a nicer text entry system that will obviate the problem going forward.

Disallowing arbitrary use of scripts sounds good. But that means I will
have to come up with another way of inserting the JavaScript for diagrams
that show legal moves on mouseclick. And these diagrams would still require
the use of JavaScript snippets in onclick attributes.

Please look into text entry systems. It looks like we want one with the
ability to add shortcodes, that can switch between HTML and WYSIWYG entry,
and maybe can handle file uploads. Based on my experience with WordPress, I
would prefer to have one that uses Page Up and Page Down properly.
Wordpress doesn't handle these properly, and plugins I've tried to
replace its native text entry with on my blog have been buggy.

H.G., can you link to such an example?  As far as I can tell, we just apply wordwrapping (to default 75 characters) and put PRE tags around each section.  But this should preserve linebreaks, and seems to e.g. at
http://www.chessvariants.org/index/msdisplay.php?itemid=MS4chessfourdime

Or did you mean in the comments?
Test.
Aha, ordinary linebreaks here don't get processed.  I can probably fix this reasonably quickly.

Fergus, I think one of the text entry systems I mentioned in my last comment would do the first three bullets of what you want.  And I would like to disallow arbitrary use of scripts, instead having the displaying function replace things like [diagram] with the appropriate script (for a short list of approved scripts).

Rendering of submitted non-HTML texts has been broken for years on this
site: it completely ignores line breaks, and just heaps everything typed
between empty lines into one big paragraph. Worst of this is that it
completely messes up all tables that were present in the text. I post on
many forums, and I have never yet encountered one that mutilates user input
anywhere close to what happens here.

Maybe we don't need to switch to a third-party CMS. We have code here that is already set up for Chess variants, and it might be hard to duplicate or integrate that with a third party CMS. But we could use some new features. I don't use msdisplay much since I can upload html pages, but looking it over, it seems very bare bones. Here are some features I think could help improve it:

• A WYSIWYG editor
• A more sophisticated HTML editor
• Buttons for inserting common HTML code
• An easy way for users to upload images
• Fields for metadata, particulary title, description, keywords, and an image to use with Open Graph metadata and Twitter cards.
• A reference to Game Courier and the graphics.dir directory as resources for making diagrams and displaying piece images.
• Maybe replacing msdisplay.php URLS with /user/userid/ or /category/category_name/ or /userid/category_name/ URLs.

On the Game Courier end, I'm thinking of adding the ability to selectively save Game Courier generated images to a user directory for permanent use on a webpage. This might spare the need to allow users to upload images, keeping people from using the site for general image hosting.

With regard to limiting HTML code, what did you have in mind? Any further thoughts on features msdisplay could use?

The problem with the ffen is that the diagram is generated as a HTML list,
with each list item a row of piece images. If there is not enough space,
browsers start wrapping such lines, or mutilate them otherwise.

HTML tables seem more robust against browser mutilation. At least if their
cells contain 'incompressible' images rather than text. When they don't
fit the browsers tend to use scrolls, rather than attempting to shrink
them. When I display my interactive diagrams on very cramped mobile
dislays, like phones, however, the browsers still don't seem to be able to
resist shrinking the size of completely empty ranks and files to below the
specified pixel size. I guess this can be cured by providing a full-size
image of an empty square, completely transparent, and using that
everywhere. Currently I just leave empty squares without any content.

I was hoping for a solution that would scale images enough so that lines
were not broken.  (Alignment for boards with different rank sizes is
another issue, which I had not considered yet.)  I was looking for a way
that the js output could be treated as a single object to be scaled to fit
the screen; perhaps flattening to a single image would do that in addition
to being better for other reasons.

By "transition to single images hosted on this site" do you mean on the
author's end?

For ASCII diagrams I am mostly concerned with old pages (90s ones :P) that
already use them (and whose authors might no longer be active).  I suppose
changing msdisplay to add P tags and a monospace font will make any
"non-HTML" page without an ASCII diagram better on mobile, and will make
such pages with a wide ASCII diagram bad on mobile, but just in a different
way than at present.

I had thought about introducing a more sophisticated text entry method
(e.g. CKEditor or TinyMCE), which could render "Uses HTML" obsolete (for
future pages): every page would use HTML, but the user wouldn't need to
worry about coding.  On top of that, we could be a little more careful
about what we allow our users to submit (whitelisting html elements and
customizing to allow Muller's [diagram], the ffen2diag script, etc.).  If
we think we want to and can manage to move to a third-party CMS, then I
won't keep looking into this.  (This is outside my tech comfort zone, so
it would take me a while anyway.)

No, resizing images is not the way to go. It could be done. Game Courier
can already handle resizing of diagrams, whether they are made with one
image or multiple images. But resizing images will not fix problems with
alignment, and it is not a guarantee against the images breaking up. I
would like to replace these scripts with ones that use JavaScript to draw a
single image with a canvas element. This should still use the same images
as the current script, but it would create a single image that wouldn't
break up or get misaligned.

Nevertheless, I would prefer over this a transition to single images hosted
on the site. This makes pages more shareable through social media and may
improve SEO. JavaScript generated diagrams are useless for this.

As for fixing up msdisplay, anyone who inserts an ASCII diagram should
always put it between PRE tags himself. So I'm in favor of not using PRE
tags. Besides that, ASCII diagrams are so 90's. They are ugly and harder
to read than graphic diagrams. So we shouldn't do anything to encourage
them.

What I think I would like is to replace msdisplay with a more sophisticated
content management system. In particular, I want it to handle metadata for
SEO and provide friendlier URLs. Maybe we could modify msdisplay for this,
or maybe we could switch to a dedicated CMS program, assuming we can find a
way to migrate the data.

So I should try to modify those scripts.  Ideally it would shrink all the
images (equally) in the case of a very large board on a mobile screen, but
I'm not sure how to accomplish that.  Any ideas?

Also, I was thinking about redoing some of msdisplay; specifically,
removing the {pre} tags from submissions "Not using HMTL" and inserting
paragraph breaks using a script similar to what Fergus added for comments. 
The main problem with that is ASCII diagrams: unless I make them use a
monospaced font they won't line up, and wide ASCII diagrams could
break over lines on small displays.

Displaying diagrams with multiple images does not work well, especially on phones. First, here is a screenshot of 12sharp Chess, as displayed in Firefox on my desktop.

Notice that the top two ranks are misaligned. As bad as that is, it gets much worse on my phone. Here is a screenshot taken on my Android phone with the default browser.

A single image has the advantage of maintaining integrity, no matter what device you display it on. At worst, it will display too small or too large, which is easily corrected on a mobile device by resizing the screen. But when displayed as multiple images on too small a device, multiple images get broken up, which garbles the diagram.

Game Courier provides multiple methods of rendering diagrams. Some use a single image, and some use multiple images, but when they do, they use a table or CSS to position everything. These scripts you use for your diagrams do not do this. They just display images and leave it to the browser how to align them.

I checked on my Android phone and my Android tablet with the default browser, and the menus worked fine in both. One thing to remember is that the menus change appearance on mobile devices. While you have a menubar on a desktop, the mobile version puts an ≡ sign in the corner. Click on that for the menu. As long as she is using a tablet, there is also the option to view the desktop version of the page.

BTW, I noticed this morning that on my wife's tablet (a Samsung Galaxy
running Android) the menus on the top of this all webpages here do not
appear.

Of course doing multi-image diagrams raw has its costs as well, which is why I emphasise stored. That is where ffen diagrams come in, as regards traditional computing. As far as the HTML document is concerned it is a calculated image, taking up not much more space in the text of the page than a single image but without an image file's use of memory outside the text of the page either. As far as a large enough screen is concerned they also behave like a single image, at least if nothing else is on the same line, and desktop monitors have been getting bigger all century. The problem is how they behave on the mobile devices to which this thread's title refers - and I am guessing that Ascii Art is not very mobile-friendly either.

Now there are various facilities for playing many of the variants on these pages, and I would be surprised (and indeed disappointed at the capabilities of programming) if they generated an image file for every position that ever came up. In terms of more typical programming, It would be the equivalent of every control on a Visual Studio form replicating the entire definition of tha control. What I do not know is how the playing facilities stand up to use on a tiny screen. If they can be made to behave as single images even on-screen, surely something can be done somewhere along the line that can be done to make ffen diagrams do so as well. It would be a shame to lose such a useful shorthand for want of it functioning on mobile devices.

Using a single image for a diagram instead of a diagram made from
individual components with JavaScript will make your pages more shareable
on social media, particularly Pinterest.

Any of you who have seen these in the old form and dismissed them as badly designed might wish to revisit them now that the tabulation issue has been ironed out.

Ben,

I just sent you an email from another address you can reach me at.

Fergus, my email to you in 2011 was from my general email address; after
becoming an editor here in 2013 I started emailing you from the address
listed in my Personal Information page.

I can see what you mean about the width of the comments.  (I noticed it
when I made the change, but dismissed it.)  I could enforce a max-width,
but if you want to design a nice background for the resulting margins then
I'll leave it to you: design is not my thing.

It looks like I have one email from you from 2011 and no others. Maybe
SpamAssassin is killing your emails. 

While your changes to the comments would look better on a cell phone, they
don't look better on a widescreen monitor. Reading is more comfortable
when the width is narrower. I can just resize the window when reading
comments, though I would consider defining a content area that stays within
a certain width, such as Wordpress blogs do. I could probably add a bit of
CSS that limits the width of the BODY element, add an attractive Chess
variant themed background, whose edges would show up in wide screen
monitors but not in phones.

I think "List just summaries" is supposed to cut long comments short and
provide a link to read the rest. I remember this happening a lot, but I
didn't find any recent examples of this. I knew I found this annoying, and
maybe I changed it, but I don't remember for sure. If I did change it, I
could have done so without changing the options given to the user, since I
didn't write the original code and didn't think about the options given
to the users.

I tweaked the menu a bit so the Favorites menu shows up correctly on my
mobile (made it a touch wider).  I've also added (again) some links to the
Info tab.  (Fergus, have you seen my emails?)

Also, I modified the "List all subjects" page to give names to the
post-2012 topics that have hexadecimal codes as their subjectid's.

I have hidden some of the administrative tools in the footers as well.  They are visible only when the currently logged in user is an Editor.

I have modified the display of comments in such a way that mobile devices
should be happier.

What does "List just summaries" do?  What are summaries?

I fixed the Shogi page to fit on a phone. I did a few things. The one I did globally was to add this code to the header file:

IMG {max-width: 100%;}

This will make banner ads and other large images fit the screen without making the text too small.

On the Shogi page itself, I reduced the pieces table to two columns by putting piece images and the description into a single column. I also put the two diagrams into a diagram class, which is defined like so:

@media screen and (max-width: 480px) {
IMG.diagram {width: 100%; height: 100%;}
}

And I put the diagrams in DIV.left and DIV.right containers, defined like so:

@media all and (min-width: 1110px) {
DIV.left {width:40%; float: left; margin: 5%}
DIV.right {width: 40%; float: right; margin: 5%}
}

@media all and (max-width: 1109px) {
DIV.left {width: 100%; clear: both; float: none; margin: auto;}
DIV.right {width: 100%; clear: both; float: none; margin: auto;}
}

I have checked the page with Android's default Browser, Boat Browser, Chrome, Dolphin, Firefox, and Opera, and it works fine in all of them with minor glitches in some. In a few, the diagrams get stretched vertically, though this is actually appropriate for Shogi. And in a few, the sidebar appears above the rest of the text instead of beside it.

If you have to make a choice between multi-column or single-column, I would recommend single-column, because multi-columns are harder to read on a phone than single columns are on a widescreen monitor, but it's not necessary to make that choice. You can have multi-columns on a wide screen and single columns on a phone by replacing TABLEs with DIVs that are designed to fill multiple columns on a wide display but to stack up on a narrow display. Technically, a DIV would replace the TD in the table, not the whole table. I have done this on the Game Courier homepage. On that page, I have used the CSS classes DIV.left and DIV.right to align DIVs. On a wide screen, they show up parallel to each other in two columns, thanks to this CSS code:

DIV.left {width:49%; float: left; }
DIV.right {width: 49%; float: right; }

@media all and (max-width: 1506px) {
DIV.left {width: 100%; clear: both;}
DIV.right {width: 100%; clear: both;}
}

Would it be better to stop using multi-ciolumn tables with a view to suitability for mobile phones? If so, I will have to change quite a few of my pages.

• I replaced the table form on the Game Courier Logs page with some DIVs that will flow on a desktop or lineup on a phone.
• I tweaked the CSS for forms in Game Courier.
• I got rid of comments on the mobile versions of pages in the Play subdomain, leaving a note that they can be viewed on the desktop version.
• I got rid of the piece set table in Game Courier for mobile pages.

Getting rid of big things that take up too much width serves the double purpose of keeping the page from shrinking its contents too much and of saving bandwidth, which is a concern when using a mobile device that's charging for data. It also saves me the trouble of writing code for compacting these things on a mobile device.

The main cause of width now will be multi-column tables on individual pages, wide images, and comments on member-submitted pages.

• I removed the sidebar from the What's New? page for mobile devices.
• I removed the Share applet from the header on mobile devices
• I changed the menu for the main site to work like the one in the Play subdomain.
• I put the ad code into a function, so that I could put it in a different place on the page for mobile devices. On mobile devices, the menu now appears to the right of the logo, and the banner ad appears underneath both.
• I also rewrote the ad code as a switch statement to make it easier to follow.

On my cell phone, using Boat Browser, the text on the What's New? page is now fitting the screen properly, but the banner ad and the form at the bottom get cut off for being too large, and I have to scroll the screen right to see the rest of them.

I was just noticing the same thing! The menu text also seems too large on
my mobile. I will try to help where I can, probably just sending you code
snippets.

Now that I have a cell phone, I see that this site needs to become much
more mobile-friendly. This means reducing the use of horizontal space, so
that the text on pages doesn't get reduced to too small sizes that are
difficult to impossible to read. This will involve getting rid of sidebars,
compacting comments into single columns, reformatting forms into single
columns, and replacing banner ads with smaller advertisements. I can handle
some of this, but other editors may be able to do something too,
particularly with the ads.