COBOLdinosaur

You are ot going to get any of that solved when your HTML is invalid and structurally unstable. run the code through http://validator.w3.org/ and fix the errors. The browser cannot be expect to render correctly when the code full of errors.

if you use duplicate ids, then sooner or later it will fail because script, the parser, or the rendering engine cannot resolve it. The problem could range from a bunch of frustration because that looks like it should work refuses to co-operate or worst case the rendering engine gets an uncaught exception because the Document Object has been turned to mush so it hangs (Chrome, Safari, Opera) or terminates (Firefox and IE).

You will learn more from mistakes then from the things that go smoothly. Just use the validator to find the errors and search and forums like this when you don't understand something. The learning curve for frontend Web development is not real steep, and it gets easier as you go along.

You are going to have a lot of problems trying to main tain that pages because of all the errors in the markup: http://validator.w3.org/check?uri=http%3A%2F%2Fmain-site.nl%2F&charset=%28detect+automatically%29&doctype=Inline&group=0 The code is not anywhere near well written enough to considered stable and it will break easily. A lot of the errors are actually syntax and some look like sloppy typing. You will need to be much more precise if you want to do advanced effects without stability issues.

Generally tables are not used for layout except for email where they are often a good alternative. Using a table will mean you don't have to use a lot of CSS and that is the thing the email client mess ut the worst. The trick is to keep it very simple and basic like you are still in the 20th century because email clients are 20th centrury technology that has not evolved very much in terms of presentation capabilities.

That code has zero hope of working across multiple email clients. Each email client has its own rules about what they will accept. Gmail will not permit anything that conflicts with its own stylesheet. Outlook is not even consistent across version. User preferences may limit or block HTML, and some clients by default will block html. Plus spam filers may dump it into a spam folder. You need to look at: https://www.campaignmonitor.com/css/ where you will find a matrix that should make it clear that you are not going to meet your goal, and if you manage to get it so 60% of the email you send that way is readable you will be doing well. The only certain way you have of the email being delivered as you have sent it is to use straight text.

A link to the site would help. I can't tell what is being cascaded looking at an image, and incomplete markup is not much help considering how the inconsistent CSS. How is it you think margin:auto can be applied to an element that has a width of 100% or how you float something that is 100% width?

To start with you cannot determine what anything on a web page is going to look like by previewing it in Dreamweaver. It is not a browser and does not render the same as a browser. If you are just learning then you should only using two tools. A modern browser to see haw things are going to render, and a flat text editor that forces you to learn coding. You should not be working through levels of abstraction that you get using tools until you understand how things work at the basic code level. If you want to learn right then use a reference like this site, and and editor, not tools that encourage you to not learn detail.

From a browser standpoint the errors are an issue. The perception that browsers ignore errors is not correct. Every error the validator is finding; the browser also finds during parsing. It then has to execute additional code to create what it "thinks" is the intended code so it can serialize it to the DOM. If it just left the errors and went into the DOM with it, then during layout or painting the rendering engine might encounter an uncaught exception that would hang or crash the browser. So the best way to proceed is to use both doctypes depending on whether a page has been converted, and to validate and FIX THE ERRORS for whatever doctype you are using. If you leave errors, it is just a ticking time bomb and sooner or later a minor change will turn the page to mush because one or more browsers can no longer figure out how to parse it. If it is a commercial site then there is also an SEO issue with the errors, because the crawlers parse the same way a validator does, but unlike a browser, the crawler just keeps going and lowers the quality rating. If they get lost or confused, the simply quit indexing the page.

I don't think you should need the outer wrapper, and the prefered way to center is with margin: auto. You probably don't need the negative margin if you eliminate the extra line feed you get because of the using the wrapper. Why are you using float:left if you want centered alignment? #menu {width:70vw;text-align: center;margin: -7px auto 0 auto;.button {background-color: #000000;color: #FFFFFF;width: 100px;padding: 5px;text-align: center;text-decoration: none;float: left;} The value of the width probably needs adjustment based on actually content and the devices being targeted.

Moving it to javascript seems to make sense if you are going to use javascript for dynamic positioning rather than CSS. However the reference to a spreadsheet has me confused. I can't think of any sort of design where canvas would be an appropriate element for implementing a spreadsheet style application. What you might actually need is flexbox: http://www.w3schools.com/cssref/css3_pr_flex.asp

Based on what you have there you have 3 canvases sitting ontop of each other at the top left of the viewport. Using fixed means they are position relative to the viewport edge. If you want to move them around you will need to use Javascript to reference them by Id to alter the style. for example document.getElementById('CanvasH').style.left='200px'; would move that box to a position 200 pixels from the left edge of the viewport. If you wanted the move to be animated instead of a jump you would either need to use a javascript loop to change the value as timed intervals; but it would be easier to have a second class for the element with a different position and a transition property to do the move. Generally for this kind of dynamic you are better to use position:absolute so it positions relative to the body instead of the viewport. From a design perspective I don't see moving a canvas which, I would expect to have animation, as something the user would view as positive, unless the purpose of the site is to demonstrate impractical effects. Generally too much motion on a web page is not a good idea and stacking effects normally has a result of user leaving the site.

If you don't know PHP then how do you expect to be able to implement a solution or maintain the code? If you are looking for someone to do all the work for you so you don't have to learn anything, you are probably looking in the wrong place. The site name does include 'school' which means people come to the site to learn, not to have their work done for them.

I get nothing at that dropbox link. Just post a link to the page or post the code so we are not bouncing around between sites looking for code.

An image of how a page is supposed to present and behave tells me absolutely nothing about the code which is where any solution is going to reside. If you can post a link to the live page, or post the code I might be able to help but with nothing but an image I have no idea what you need.

You are looking for harm. The issue is user perception. If they don't like something then it is a negative in how they feel about the site. Unless a site is in the font business; then no one is visiting the site to see what kind of fonts they use, but if a user does not like a font that is overriding their defaults it can add nothing but negative karma. Is it possible that the user will like the overriding font better? Probably, but they are not checking out sites for fonts if they are shopping for shoes or looking for a new bank. So it is not harm to the user, but harm to a site that is putting design ahead of a user's right to control how their browser behaves and renders. If you are not sure about sarcasm, just Google COBOLdinosaur to see how long I have been working the boards on tech sites. or look at my profile at the site I recently left after starting there 15 years ago.

The research is paid for by clients and has been used to improve ranking, user engagement, and performance. I don't need independent review or validation. I get that from clients paying for my services and asking for more. And just so you know the kinds of things I do for clients is all white hat, I have never had Google impose a penalty on any client as a result of them doing SEO based on my research instead of speculation, rumor, opinion, and misleading information from Google. As for backlinks over the past 30 months they have been dowgraded 3 times in the weighting and will continue with that trend as long as Google tries to stop the gaming of SERPs with link creation schemes.

Wrong. I have been doing those kind of experiment for over 10 years. Every time Google makes a change I run experiments. It used to be the crawlers just tried to go around errors or worst case only partially indexed. Howeve startin in July 2013, they start ed penalizing pages with invalid code, and the penalty has been increasing. The April change to penalize pages that are not 'mobile friendly' is just an extension of that. In the last round of test I ran for invalid code in Feb 2015, A page with more than 5 structural errors or any serious mistagging lost on average 8% of ranking weight for most page that would be a drop of 1 or 2 positions in the SERPs. A relatively heavy penalty for just one weighting factor. Right now I am running similar testing to see the effect of the 'mobile frienly' thing and it looks like an even heavier penalty, but it is being narrowly appled depending on the user device.

Yes while I guess i am not experienced enough after programming for only 50 years. I will have to tell my clients (some of whom have been with me over 30 years) that they will need to find someone who has a better understanding of user needs and behavior because all the experimentation I have done proves nothing.

If the only way to do it is with the invalid code, then it is self defeating to run an add that way. the Search engine crawlers parse the same way as the validator, and when they see something like that they will not index the page. If you are doing it for an email campaign you will find that it gets blocked more frequently then email with regular ads because it wil look like a phishing scam to many email filers.

I generally use code for small bits that are inline but for larger blocks I prefer to use pre because it default behavior is close enough to the way that I want code blocks to render that it does not take much CSS to do the presentation. I will also uses a readonly textarea for large blocks so I get the default scroll bars and don't have to set an overflow property to control the size of the rendered block. I prefer the lazy approach of using tag defaults to reduce the amout of CSS I have to write.

It is an inline element, and used primary to use a fixed font for the display of code, it is in the same groups of tags as <b> and <em> for use localy in text instead of having to style a span.

One of the differences between those who are design oriented and those who are technical development oriented is how we view users. From where I sit forcing the user to accept anything that might be an accessibility or usability problem for them is not generally a good idea unless there is a compelling reason to do so. The purpose of a web site is to present content; not to impress them to get a "wow". Generally the WOW only happens the first time, then the site has to stand on technical merit, not how it looks. The exception to that is a site in a business related to visual or graphic arts. But what do I know most of my clients are pretty conservative and I have had some of them since before the internet even existed. On my personal site I like to play, but not so much with fonts. A special font is not going to gain any additional traffic, but even if it only increases the bounces by one a day it is a net negative. Everytime I have run experiments where I specify fonts, the results has always been a net loss.

Just a tip from an old hand. It is almost always a mistake to force your idea of good fonts on users. When you do that you override the default fonts the user has set for their computer and I the ones they like and are comfortable with. Some users may not like the fonts you select and will have a negative experience on your site as a result.

It is mainly a matter of setting appropriate widths using flexible units of measure like percentage, em, of vw. Generally yo need to be careful using fixed values like px because it makes the page rigid and you will end up with scroll bars at very low resolution and huge empty margins on very wide devices. We will realy need to have some idea of the actual layout you intend to give a definitive answer and recommendations on how to acheive it.