Why are browsers so picky?

HTML & CSS
21

The code that I posted applies the margin left and right to all table tags, thus centering them and eliminating the “align” attribute.

The second appearance of “table” is here

.outer > table {

where the table tags being targeted are the first level of table tags (children) inside of div.outer, none deeper (no grandchildren) will receive the padding. I’m not sure what you mean by addressing “table” as a class. Are you asking if you could use the word “table” as a classname? The answer is “Yes”, but it is not semantically appropriate.

Perhaps some example code would help.

22

Very interesting @RyanReese I totally ignored the importance of !important. About, instead “#sses2` li a” I had to place it in menu-2.css regardless then.

@ronpat

I understand now, so I may very well clean all the align attributes present on tags table now. At least those inside the div other (I don’t think there are others though).

As for the outcome of your changes, everything went back the way they were in the beginning. The menu got thrown again on the left (on mobiles) and the background image doesn’t get loaded. I leave them online till your next reply so you can verify by yourself.

23

Class or ID? Does it matter?

I specified

<div class="outer">

In this latest trouble report, the HTML has been changed to

<div id="outer">

but the css still says

.outer {}

Go figure.

I recommend ditching “id” and replacing it with “class” as was written. There was nothing wrong with “class”.

Restated… I recommend using classes for everything except where required by JS, for fragment identifiers, or by third party code.

Fix the class-vs- ID problem however you wish. Let me know how the page behaves (at the very least, the blue background image should reappear) and what you wish to work on next.

At this time, the menu is centered in all of my browsers. At narrower widths, it may lose that centering (depends on the width and the font-size). Please mention the width at which you are testing the “mobile” view. And be sure your browser is still set to its default font size else it’s a sure bet that the font will wrap.

I have suggested several times that you consider a different menu or at least be willing to change the behavior of the one you are using. No response means no progress. If you are wedded to the one currently in place, that’s OK, but I can’t help any further with it. The behavior is controlled by JS and I do not do JS. Someone else will have to pitch in, but they will also need for you to describe your expectations/vision of how you expect to behave/look at “mobile” widths because what you have now is impractical.

Unrelated… At the bottom of csss.css, there is still an HTML tag

</style>

Again… HTML tags on a stylesheet are a nono.

More Unrelated… During the process of developing a web page, it is a good idea to save frequent backups of your files. Landmarks, if you will. If something goes wrong, you can then revert to the last working copy and start again, if necessary.

24

You’re soo right :laughing:

After all that talk I didn’t even substitute the id attributes. Sorry for that…

So, visually these last changes haven’t yielded, I think, anything. The menu continues to wrap on some of my mobile browser as chrome, opera (which now doesn’t even support the internal scrolling) and firefox. Dolphin was fine even before.
My mobile works on 1280x720.

What did I do? I further decreased the padding, from 24px to 20. Now it doesn’t wrap anymore (it shouldn’t).
But now the text dimension is different. See how much space to the sides now? But then if I increased the padding, the text gets bigger and wraps. Why? :frowning:
All along I did accept it, i said: ‘Ok, all right, text visualization behaves differently on mobiles’. And now it’s behaving like it does on desktops. :angry:
Yes, I’m probably missing something here…

It’s not that I’m wedded to it. I’m keeping it only because of the background images match between it and the box. if I change it I need to change the container aspect as well and that would mean change pretty much everything at that point.

25

Staying with the menu that wraps in some devices. Please respond to the following list of questions and more questions.

How are you testing the mobile behaviors? Is that a feature in Dreamweaver? or are you using real devices?

I may have been misunderstanding the extent of the problem and your goal.
Do you remember my admonition in bold in post #18 to reload the page after each change in font size or page width? That’s important because of the way the menu is controlled by JS. JS autosizes the width of the menu on page load only. It is given a fixed width with no wiggle room for changes in the way a font might be rendered (width) if the text or page is zoomed. The set width of #sses2 is not auto-readjusted when the page (or font size) is zoomed larger or smaller until the page is reloaded.

In my copy of Opera 24, your web site shows and responds appropriately to the internal vertical scrollbar in the lower (content) section. Which version of Opera are you using?

Does the size of the text actually change or does the space between the menu items change? In other words, does “text dimension” mean menu width? “Bigger” is ambiguous.

I agree with you that the ends of the menu are visually unappealing… too much space.

More than likely, I am missing something.
Once again I ask… Would you please describe in precise language what you mean. In what ways is the menu behaving like it does on desktops? How do you expect the menu to behave at mobile widths? Include annotated screen shots, if necessary for clarity.

Matches which box? I don’t know which “the” box you are talking about.

Which container? and what aspect? Are you talking about the height? I don’t understand what you are talking about.

Which is what I have tried to explain and why I have repeatedly asked you to describe your expectations for the page clearly, specifically, not ambiguously. Unless I am not paying attention very well, you have not described how you expect the whole page to behave. You are focussing on the menu but neglecting the banner and bottom content area. You seem determined to keep the fixed height content area with its vertical scrollbar. That is why I think I am missing something. You seem to be troubled because the menu wraps on certain mobile devices. Not interested in a “responsive” web page design.

Unrelated… at the bottom of csss.css, there is still an HTML tag that should not be there:

</style>

26

I’m testing them on mine mainly but also on my family’s and friends’ devices.

I always reload pages twice after every change regardless of what would it be. A lesson i learnt long ago.

About Opera it was my fault, it had the off-road function set on.

1280×720 102 KB

First one: padding at 24px mobile; second: 20px mobile (visualization is the same as on desktops); third: 24px desktop…

See the difference in text dimension between 20px and 24px both on mobile?
I believe it’s the dimension of single items what actually change.
On desktop the text dimension seems to be coherent and always the same.

Sorry for not being clear, box=container=fixed height content area

I’m focusing on the menu because it’s it presenting the most pressing problem.
The banner and bottom content area are “fine” even with all their defect.
The banner could easily be substituted with a simple image (I made it, I have all the material to modify it)
The bottom content area seems to behave well both on desktops and mobiles, I set its height so it, along with the menu, could fit vertically on the majority of mobile screens.

My expectations (for now):

This’s with padding 30px on desktop (items spread through the entire menu area).
Make it work on mobiles. This’s what it’s all about!!
If I (…We. You) won’t be able to fix it I’ll leave it set to 20px and whatever…

Again I don’t want to make big changes (which I’d have to, if i want to make it responsive) because they would mean total reschedule. Both menu and fixed height (and width) content area have fixed dimension background images not to mention all the table maze (fixed dimension as well) layout on the home.

Hope I’ve made myself clear :smiley:

Edit: I tried it at 30px on mobile and it’s not wrapping now :open_mouth:

27

I’ll bet the font-size in the mobile browser has been lowered to the default size.

This still means that it will not render as desired on many other devices.

I’m working up a menu experiment which I would be grateful if you would try (I’m not set up to test mobile devices). Haven’t quite finished.

28

I couldn’t say. I didn’t t touch any such feature in the browsers.

What about your menu experiment?

29

Hi, dRyW ! Long time no see

The menu experiment, as far as I took it, works very nicely. It requires JavaScript as yours does; however, I do not speak JavaScript, and since you disappeared (and sounded puzzled but satisfied in your last post), I put it aside to work with other posters. We can post it in the JS Category and ask for some JS help, if you are still interested.

Keep in mind, it will only fix the menu (and only “within certain limits” because the menu is not designed to wrap). It will not affect the boxes at the bottom of the page that seem off center or that overflow to the right. Those would still be problems… but I believe that the menu would be quite satisfactory.

30

Regarding your menu your main mistake is to expect that text + margin = available width. That will never be true as devices have different sized text and different fonts which means that over the course of a single line there can be over 100 pixels difference. It will never add up exactly and you will find that some devices will wrap the last menu item (or two) and some will be much shorter than others

What you need to do is distribute the items across the bar but without using padding or margin to make it fit. You can do this in a number of ways and perhaps the simplest is just to give widths to each item that add up exactly to the available width and all browsers will honour this. You just then center the text in each menu item. This allows for masses of breathing space between the text and should render everywhere without problem.

An alternative is just to use the display:table properties (my prefreered option these days) and items auto distribute without the needs for widths padding or margins and thus can grow or shrink very well.

In your example this would equate to something like:

#sses2 ul{display:table;width:100%}
#sses2 li{float:none;display:table-cell;text-align:center}
#sses2 li a{margin:0}

Of course the automatic distribution may not be exactly to your liking but there would be no harm in adding some padding to one or two items or sizing one of the items.

e.g.
#sses2 li:nth-child(4){width:15%}

Of course if you do that then you spoil the auto distribution a little so its best to live with the browser default.

31

Hi rompat!
:smile:Puzzle but satisfied. Yes, you could say so.

Do you mean the code your menu is set with is going to fix mine?

What do you mean by boxes at the bottom, overflowing to the right?

Anyway I asked out of curiosity. My menu is behaving fine with my mobiles (it’s not wrapping). And hopefully devices will continue to improve at resolution so I won’t be too troubled for the time being untill I decide to change layout. Tell me if I am wrong! As soon as it stays this way I’ve no reason to tamper with it.

@PaulOB Great idea. To be honest, in my ignorance I thought it was structured sort of this way already, from what I visually detected from the dw preview frame. Pretty ambiguous I know!
I’ll take it into consideration as a possible cure if I’ll have more of these troubles.

32

Hi, dRyW.

As offered a few months ago, this is a modification of the menu that allows it to autoadjust to changes in the user’s font-size or changes in the width of the page. Since your site isn’t fluid, I doubt that the latter feature is of any value, but the ability to change the spacing of the menu items should the user change their font size may be of value.

New or modified files:

(1) menu6a.css at top of page – replaces menu-2.css (deleted)
(2) bubble6a.js at bottom of page – replaces menu.js at top of page (deleted)
(3) added menu text-spacing adjustment JavaScripts at bottom of HTML page.

I increased the default size of the menu font a tad. See the comment in menu6a.css. To undo the increase, either comment out or delete the font-size property in menu6a.css, #sses2 li a

The full width of the brown bubble is clickable. The original behavior in which only the text is clickable can be restored, if preferred.

The menu text spacing adjusts to changes in the font-size, font-family, or page width in real time. No need to reload the page. (The font-size does not change - that would require a media query; the space between the text items changes.)

menu6a.css replaces the menu’s background image with a background-color and inset box-shadow. I made that change for my convenience rather than create an expandable/shrinkable version of your background image. You can change it back to your background-image by uncommenting your background shortcut and commenting out (or deleting) my background-color and box-shadow just below your shortcut in #sses2

Be sure to check the paths to your resources. I may have changed a few for my convenience.

You will have to test to see if the brown bubble comes to rest on the current page.

As always, “try before you buy”.

Download the folder in this dropbox. Open it and double-click ilcontadinobio6a.htm. It should open in your browser and allow you to test the menu.

Best of luck.

33

Brown bubble tested! It appears to be all right.
I’d be tempted to make the swapping if it wasn’t for the animation, it just seems to be slightly less fluid and jerky than the original.
The bubble as well does not behave very nicely on loading stage. Namely, every time the page (hence the menu) gets loaded, the bubble comes all the way from the right side of the menu, beyond its background boundaries to take position on the selection. The entire process happens not fast enough for you not to notice. I tested it with two browser; the result does not change.

I agree about extending the clickable area to the bubble’s, along with the increasing of the font’s size.

As far as I know and may appreciate it, it is a remarkable job.

Let me know what do you think of those flaws.

34

The animation is definitely not as smooth as the “unenhanced” version. The animation is created by the bubble JS and runs for several milliseconds while the bubble is positioned. The additional JS is competing for some of that CPU time. The author of the bubble JS included an option on lines 38-39 to eliminate that initial “slide-in” animation. You can try swapping the author’s comment marks to eliminate that opening animation and see if that helps.

Plus there is the JS used by the slider…

In the JS that I added, the ability to respond to changes in font-size on-the-fly seems to want a share of the CPU time. There must be a conflict of interest in need of better integration, I guess. If we eliminate the real-time listener, and allow the changes to take place on page load, the transition is much faster. It’s easy to turn off the listener temporarily.

First though, try the author’s option to eliminate that initial slide-in animation and see if that helps.

website (www.ilcontadinobio.it)

35

Much better now with the lines 38-39 swapped.
Yet it remains jerky and noticeable slow on response time. Does it really need the real-time adjustment with mobiles? Would it be enough it settling just on page load?

36

It sounds to me like you’ll be happy with the basic ability of the menu to adjust its width on page load.

At the bottom of the home page, comment out or delete the first long function, and one closer to the bottom shown below.

(function(){
    var attachEvent = document.attachEvent;
    var isIE = navigator.userAgent.match(/Trident/);
    var requestFrame = (function() {
        var raf = window.requestAnimationFrame || window.mozRequestAnimationFrame || window.webkitRequestAnimationFrame ||
            function(fn) { return window.setTimeout(fn, 20); };
        return function(fn) { return raf(fn); };
    })();

    var cancelFrame = (function() {
        var cancel = window.cancelAnimationFrame || window.mozCancelAnimationFrame || window.webkitCancelAnimationFrame ||
            window.clearTimeout;
        return function(id) { return cancel(id); };
    })();

    function resizeListener(e) {
        var win = e.target || e.srcElement;
        if (win.__resizeRAF__) cancelFrame(win.__resizeRAF__);
        win.__resizeRAF__ = requestFrame(function() {
            var trigger = win.__resizeTrigger__;
            trigger.__resizeListeners__.forEach(function(fn){
                fn.call(trigger, e);
            });
        });
    }

    function objectLoad(e) {
        this.contentDocument.defaultView.__resizeTrigger__ = this.__resizeElement__;
        this.contentDocument.defaultView.addEventListener('resize', resizeListener);
    }

    window.addResizeListener = function(element, fn) {
        if (!element.__resizeListeners__) {
            element.__resizeListeners__ = [];
            if (attachEvent) {
                element.__resizeTrigger__ = element;
                element.attachEvent('onresize', resizeListener);
            } else {
                if (getComputedStyle(element).position == 'static') element.style.position = 'relative';
                var obj = element.__resizeTrigger__ = document.createElement('object');
                obj.setAttribute('style', 'display: block; position: absolute; top: 0; left: 0; height: 100%; width: 100%; overflow: hidden; pointer-events: none; z-index: -1;');
                obj.__resizeElement__ = element;
                obj.onload = objectLoad;
                obj.type = 'text/html';
                if (isIE) element.appendChild(obj);
                obj.data = 'about:blank';
                if (!isIE) element.appendChild(obj);
            }
        }
        element.__resizeListeners__.push(fn);
    };

    window.removeResizeListener = function(element, fn) {
        element.__resizeListeners__.splice(element.__resizeListeners__.indexOf(fn), 1);
        if (!element.__resizeListeners__.length) {
            if (attachEvent) element.detachEvent('onresize', resizeListener);
            else {
                element.__resizeTrigger__.contentDocument.defaultView.removeEventListener('resize', resizeListener);
                element.__resizeTrigger__ = !element.removeChild(element.__resizeTrigger__);
            }
        }
    }
})();

var myElement = document.getElementById('navList'),
myResizeFn = function(){
    fitMenu();
};
addResizeListener(myElement, myResizeFn);

You can still set the menu font size to whatever you wish (within reason) on the site and the user’s browser will adjust the width to fit on page load.

37

Seems ok now. The difference is really subdle expecially once it fully loads. Shame for that lack of responsiveness…
(Is there any way to improve that CPU time?)

38

What “CPU time” effect are you concerned about? What are you seeing that you don’t like?

39

So that there wouldn’t have been the need of desabling the real-time function.

40

The JS for the brown bubble takes a long time to run through its routine. It and other JS files wait in line for an interrupt opportunity, do their thing, then continue. It’s a very slow routine and there are several JS routines running.

The real-time function alone is annoyingly jumpy, but fast. I believe that the interaction between the real-time function and the time-hogging bubble JS conspire to seriously slow down the performance. You have a busy site from the CPU’s perspective.

With nothing added, the bubble JS is slow and flawed in that the bubble can land on the wrong menu item. Adding the real-time function makes it much slower and more error prone.