Check out McCooey's Hexagonal Chess, our featured variant for May, 2025.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

EarliestEarlier Reverse Order Later
Trouble making submissions[Subject Thread] [Add Response]
(zzo38) A. Black wrote on Mon, Mar 28, 2016 02:52 AM UTC:
Ah. I wasn't sure if it was intentional, although posting about it here does seem to be a report, anyways. <strike>However, it is still wrong to me in the print preview, whether or not my custom CSS is enabled (I tried it both ways), and regardless of the scale setting and other settings for the printout. The file I used for testing is: <a href="/invention/mitred-framing-3-6x6-to-8x8">mitred-framing-3-6x6-to-8x8</a></strike>(I fixed it; the problem was that I needed CTRL+F5 and then it worked. However, now it says "stylesheet could not be loaded", even though the stylesheet does exist as as I can confirm, and does execute. Perhaps the error message is a bug in Firefox and is harmless.)

H. G. Muller wrote on Mon, Mar 28, 2016 10:00 AM UTC:
<pre>Fergus Duniho wrote on 2016-03-27 None The main purpose of the sidebars is to make the content narrower, because this makes a page easier to read. It also helps contributors who are designing pages on desktops with wide-screen monitors to design them in a way that will work on mobile devices, for which extra width is not even an option. So, yes, they have to go all the way down, and they should not be hidden unless it is for a page that requires the extra width and is not intended to work on mobile devices. Using the space for advertising is a side benefit of having the extra screen space available. </pre> OK, that sounds reasonable. The Design Wizard is a rather specialized function, however, occasionally used by people who want to generate HTML code for pasting it into the web page they are designing. I don't think it is imperative that they could do that from a mobile device. <p> It would still be nice if you assigned a unique id to the side bars next to the article, and the 'main' HTML element, so that they could be accessed from the JavaScript through getElementById. To restore full width I had do set the display style of the side bars to "none", and the MarginLeft and maxWidth properties of the 'main' element. I now have to reach those elements through getElementsByClassName (for 'leftcol' and 'rightcol') and getElementsByTypeName (for 'div', 'main' and 'article'), which is a pain because they return arrays, out of which you would have to pick the proper element. <p> Although what I have now works fine, it is critically dependent on the structure of the page. Somy worry is that at some time in the future, the current code would cease to work because you re-organize the layout in the display scripts, making the article reside in the second 'DIV' element of the page instead of the first, or adding other elements with class 'leftcol'. The system could be made more robust by assigning an id to the elements that need to be affected, which would be kept the same no matter where they go. <p> Of course it would be even nicer if all displayed pages defined a JavaScript function FullWidth() by themselves, which would do whatever was needed to make the side bars disappear. Then people that would need the extra space for whatever reason could just call that function, without being dependent on any assumption on the current or future layout of the page. (Which they would depend on if they had to implement this function themselves, as I now did as part of the handler for the 'Design Wizard' button press. <pre> var adbar = document.getElementsByClassName("leftcol"); adbar[0].style.display = "none"; adbar = document.getElementsByClassName("rightcol"); adbar[0].style.display = "none"; adbar = document.getElementsByTagName("div"); adbar = adbar[0].getElementsByTagName("main"); adbar[0].style.float = "left"; adbar[0].style.marginLeft = "1px"; adbar[0].style.maxWidth = "100%"; adbar = adbar[0].getElementsByTagName("article"); adbar[0].style.float = "left"; </pre>

🕸Fergus Duniho wrote on Mon, Mar 28, 2016 01:30 PM UTC:
If you need greater width only at the bottom of your document, you may be
able to get it by closing the ARTICLE and MAIN tags before the code for
your design wizard. Technically, the sidebars do not run all the way down the article. They are both closed in the HTML before MAIN and ARTICLE even appear. They only appear to go all the way down, because MAIN is given a width that fits it between the sidebars.

H. G. Muller wrote on Mon, Mar 28, 2016 03:56 PM UTC:
But I cannot place anything outside the ARTICLE, can I? The submission script wraps everything I submit, including the Design Wizard, inside that ARTICLE inside MAIN inside DIV class="middle". And the ASIDE side bars are sibblings to that DIV.

I have not experimented with this, but the CSS file defines a float style for the side bars, suggesting that the text would drape around the ads, if it were not for the setting of the margin. So perhaps there isn't any need to hide the ASIDE elements, if I just want more space at the bottom, and an I just reduce the marginLeft and increase the maxWidth of the MAIN element.


🕸Fergus Duniho wrote on Mon, Mar 28, 2016 08:08 PM UTC:
I did it for you, and I noticed what seemed to be side effects. The text
was going over the inner nav bar, and the wizard wasn't working. So I undid
it, but the text continued to go over the nav bar, and the wizard still
didn't work. So it didn't cause those effects, but they are something you
want to fix. In general, closing the ARTICLE and MAIN tags is just a matter
of inserting the HTML for closing these in your code. This will leave you
with some unexpected tags for closing ARTICLE and MAIN further on in the
document, but the page should still work. Unlike BODY, ARTICLE and MAIN are
completely optional in HTML documents, and you are free to place code
outside of them. It is just that headers and footers are set up here so
that MAIN and ARTICLE get opened in the header and closed in the footer,
which places the main content of a page between the two ARTICLE tags, which
are inside the two MAIN tags.

H. G. Muller wrote on Tue, Mar 29, 2016 06:50 AM UTC:
Well, I am not sure what exactly you did, but it pretty much destroyed the entire article. There are PRE tags now around every section, disabling the normal text formatting (and selecting a monospace font). I guess this is causing the text to overrun the NAV BAR.

All escape codes for the less-than sign seem to be gone again, so that HTML tags that should have appeared as literals in the text now again are interpreted as active HTML tags.

Whatever you did, can you please undo it?


Charles Gilman wrote on Tue, Mar 29, 2016 11:02 AM UTC:
"I just finished rewriting membersubmission.php and membersubmission2.php to use PDO methods instead of mysql functions. Please let me know how it works."

It is worse than ever. This time all I get is a blank page, when trying to edit index information not just on that page but on any page of mine.


🕸Fergus Duniho wrote on Tue, Mar 29, 2016 02:01 PM UTC:
H. G., when you mentioned the PRE tags, that clued me in on what happened.
It was treating it as a submission that doesn't use HTML. The problem was
that there were some mismatched variable names between two scripts, which
caused checking the box for using HTML to have no effect. So I fixed that
and closed the ARTICLE and MAIN tags just before your wizard.

🕸Fergus Duniho wrote on Tue, Mar 29, 2016 02:14 PM UTC:

Charles, I have temporarily listed myself as the author of Commedia dell'Arte Chess to debug the scripts.


🕸Fergus Duniho wrote on Tue, Mar 29, 2016 03:08 PM UTC:
Charles, I have finished debugging the scripts, and I have relisted you as
the author of your page. I added a note at the end as a demonstration that
the scripts are now working.

H. G. Muller wrote on Tue, Mar 29, 2016 04:56 PM UTC:
> So I fixed that and closed the ARTICLE and MAIN tags just before your wizard.

OK, I see what you are doing: you just put an unbalanced closing tag for MAIN and ARTICLE in the submitted text, and this will locate part of that text (in this case the Design Wizard, which initially is hidden) behind those elements. The fact that the display script still adds another {/MAIN} and {/ARTICLE} behind the Wizard does not matter; these are simply ignored by the browser.

With the screen width I have (enough for adding the left ad side bar), this makes the "fineprint" end up partly behind the article text, and mostly in the left side bar below the ad, however. This is a bit ugly.

I did find a work-around for that, which is structuring the submitted text as:

{DIV class="middle"}
{ASIDE class="leftcol"}ad image{/ASIDE}
{ASIDE class="leftcol"}ad image{/ASIDE}
{MAIN}
{ARTICLE}
------------------------------------------
Normal article text
{/ARTICLE}
{/MAIN}
{/DIV}

{div style="display:none"}
Design Wizard
{/div}

{DIV class="middle"}
{MAIN}
{ARTICLE}
-------------------------------------------
{p}{hr}{div class="fineprint"}This 'user-submitted' page...{/div}
{/ARTICLE}
{/MAIN}
{/DIV}
where the part between the dashed lines is the submitted one, and that outside it what the retrieval script adds. On Firefox this has the desired effect: when the Wizard is hidden the fineprint displays normally below the article, with the same left margin, like it was in the same ARTICLE element. All tags are now balanced (after the retrieval script does it work, not in the submitted text).

Only caveat is that it is against HTML regulations to have multiple MAIN and ARTICLE elements.


H. G. Muller wrote on Sat, Apr 23, 2016 09:09 AM UTC:
This is getting a bit tedious, but the article on the Interactive Diagrams is again completely wrecked w.r.t. displaying the less-than characters in it. The Design Wizard does not work at all, when the requested board should appear for placing pieces on it it just displays garbage text. <p> It was working perfectly before, and the fact that the Design Wizard opens in an area without side bars shows that this same version is still being used. So you must have altered the display script again.

🕸Fergus Duniho wrote on Sat, Apr 23, 2016 10:37 AM UTC:
No, the script did not change again. It was brought to my attention that
the changes I previously made were affecting the display of other pages.
(See the Decima page for details). To correct this, I did a search and
replace on the MemberSubmissions table. When I was doing a search and
replace for the Notes field, I did see your page get caught up in it. So
before I went through with the replacements, I opened another tab with the
entry for your page in it, and after I made the replacements, I changed the
value of Notes back to what it was. But Notes was the last field, and maybe
your page got caught in the search and replace earlier. All it changed were
HTML entities for less-than and greater-than signs. You can fix your page
by putting HTML entities back where they belong.

13 comments displayed

EarliestEarlier Reverse Order Later

Permalink to the exact comments currently displayed.