I could only imagine how complicated it might be. Your explanation is proof of it. I believe you did great and more than expected (and even requested). It is going to be fine even without the real-time function.
Much more importantly: may I really use it? 
If you would like to try one more test to see how the real-time JS vs. the brown bubble JS interact, try this:
(1) Restore (enable) the real-time JS and its listener (the last stuff that we commented out).
(2) Comment out <script src="scripts/bubble6a.js" type="text/javascript"></script>
That will run the new JS without the brown bubble. You can see the brief “jump” when the fitMenu JS acts as the user changes font sizes. Otherwise, the menu adjustment works fine.
If you were willing to forego the brown bubble, you would not need any JavaScript to create the menu. The “self-adjusting” feature can be accomplished with CSS using {display:table} and {display:table-cell} much more easily.
I wouldn’t give up on the brown bubble just yet, though. If you can find the source of the brown bubble JS, you may find that the author left more information about it. If he did, it may be possible to make some alterations to the code that improves the way it works. I am JS challenged but I’m guessing that a good JS person with lots of spare time on his hands might be able to improve the way these scripts interact.
Of course! You can use whatever you wish.
When is the jump supposed to occur? What do you mean by changing font size?
I’ve found these;
The latter seems having very similar, if not identical, versions of it.
Yep, menucool it is.
What browser do you use? I ask because Firefox allows you to zoom the font-size only. That’s how I test for potential differences in the size of the font in the user’s browser. If you do not use Firefox, I suggest installing it for that feature.
Yes, I do use it. I wanted to be sure that by ‘‘changing font size’’ you did actually mean the act of just zooming. I did how you instructed and haven’t notice anything of the sort.That means it should work. By jump you mean something similar to the one it does on page load?
Zooming text only.
Similar but different. Using the JS that I sent, on pageload or when the page width changes, the menu adjusts itself to fit the width of the page (within an 8px “drift range” at each end; 16px end-to-end). That’s easily accepted as an initialization routine and is barely noticable if it occurs after pageload.
It’s a little more dramatic when the menu adjusts to compensate for a change in font-size only (which would only occur after pageload). The latter creates the “jump” that I’m referring to.
Fortunately, most users don’t go around changing page widths and font sizes.
Because your site is a fixed width design, the only change that a use might make is a change in the font-size.
[quote=“ronpat,
post:47, topic:96365”]
and is barely noticeable if it occurs after pageload.
[/quote]
Yes, as I said I haven’t noticed any jumps other than the one on pageload. It must occur quite quickly.
Ok then, I’ll be proceeding on the migration.
Returning to our discussion about updating the whole layout I just happen to stumble upon something (http://www.aeroporto.catania.it) very similar to what I had in mind. I as well thought of diminishing the header’s height so to get rid of that annoying double scrolling. I don’t think though the site be fit for mobiles, they too adopted a different layout for them.
Most obvious difference is that their site is responsive, yours is not. I’m not sure what similarities you see to your site or would like your site to emulate.
Sorry, but I don’t know what “double scrolling” you are talking about. Could you explain? An annotated screen shot might help.
As far as the JS menu code that I sent is concerned, I will send you a demo page showing only your menu in a fluid page. You will be able to drag the width of the page slowly to see how the fitMenu routine adjusts the width of the menu within that 8px “drift range”. The menu remains centered and extended to the edges of the page (font size permitting).
Likewise, you will be able to change the font-size only using Firefox and watch fitMenu do its thing there, too. You will see that changing the font size after pageload is when the “jumpiness” occurs.
At all times you will be able to evaluate the interaction between the brown bubble routine and the menu adjusting routines.
As promised, this is a “proof of concept” test page that demonstrates the capabilities of the rewritten CSS and the added JS scripts with the bubble menu code.
There are some notes at the top of the HTML page and a few notes in the CSS.
Disclaimer: I’m not a JS person. I still have no idea how that menu JS knows which page is active so I did not attempt to test multiple pages.
Good luck.
Addendum.
After running through some font and page width resize exercises with the testmenu page, try commenting out the <script> near the bottom of the HTML page that calls the JS bubble code:
<!--
<script src="scripts/bubble7a.js" type="text/javascript"></script>
-->
and then repeat whatever resize exercises you have already tried while the bubble was visible.
You will notice right away that the additional JS performs very quickly without the bubble JS in the mix.
That is why I suggest that the bubble JS needs some experienced TLC to hopefully make it work with the added JS.
By it I’m referring to that disruption in the act of scrolling by which users are forced on in mine. In other words you (and especially who don’t expect that “feature”) need to scroll two times - one externally, the other inside the box - having, the second time, to move the cursor within the box to continue the scrolling.
Red: externally; yellow: inside the box;
As for the test page; I tried it with both bubble and not, yet again without noticing great differences. It is in both cases, for all I know, instantaneous at adjusting. I did notice the second flaw you indicated in the HTML (bubble must move to adapt to menu width or font-size changes).
Ok, I’m not sure but <script type="text/javascript" src="https://code.jquery.com/jquery-latest.min.js"></script> seems to be conflicting with the other jquery item (image slider).
I renamed menu6a.css keepeng the original menu-2.css so to avoiding changing the name on every page.
Other than that everything should be the same, yet:
If there is another jQuery call at the top of the page, delete it. Keep the new one at the bottom of the page. You should only summon the jQuery library once.
Did you replace menu.js with bubble6a.js ?
As far as I know there are three on top:
<script type='text/javascript' src='scripts/jquery.min.js'></script>
<script type='text/javascript' src='scripts/jquery.mobile.customized.min.js'></script>
<script type='text/javascript' src='scripts/jquery.easing.1.3.js'></script>
In your ilcontadinobio6a.htm you ruled the first one out, but that one is needed to make the slider works I noticed.
Yes, I added bubble6a.js in the same folder as menu.js (and deleted the latter).
EDIT
Nothing happens (the menu keep remaining as showed on second screenshot) even if I delete all of those three…
Is <script type="text/javascript" src="https://code.jquery.com/jquery-latest.min.js"></script> strictly necessary?
Solved! I forgot to specify class="buttonBox" in <li>
Still remains the libraries conflict.
The first one can be deleted as long as you leave the new one at the bottom of the page. No, the new line isn’t strictly necessary, but it does link to the latest version. If you decide to keep the old and trash the new, it would be best to move them to the bottom of the page just before the </body> tag.
As a matter of routine, JS scripts and links should be located at the bottom of the page just before </body> tag. Usually, it is best if JS is invoked after the HTML and CSS loads. There are exceptions, of course .
Hopefully, this “advice” will solve the libraries conflict.
If I delete the first one (<script type='text/javascript' src='scripts/jquery.min.js'></script>) and keep the new one (<script type="text/javascript" src="https://code.jquery.com/jquery-latest.min.js"></script>) the slider does not work.
You’re right. According to the author, jQuery must be in the head of the page and called before the slider.
I don’t understand why your older jQuery can’t be replaced with the newer jQuery, but the slider fails with the newer jQuery.
Your version of the slider is 1.0.7, the current version is 1.3.4 and it is declared to be valid in HTML5. Might be worth upgrading your slider. Maybe the newer version is compatible with the newer jQ, too.
Otherwise, I’m at a loss. JS isn’t my forte.
Also noted, your stored, minimized copy of jQuery is v. 1.7.1. The series 1 current version is 1.11.2.
Please read the info near the top of this page http://jquery.com/download/ comparing versions of jQuery before and after 1.9. It looks like you need to replace your jQuery as well as the slider… and there may be more.