Ingolme

I downloaded your file acp.zip and tested the page and I don't see any bold text where it shouldn't be.

Both columns had the same width, so when stacked upon eachother they looked the same. When they have different widths, they'll appear different when stacking. As Dreadful_Code mentioned, a media query would solve it. For example: @media only (max-width: 600px) { col-c35{ width: 100%; } col-c65{ width: 100%; }} That means that when the screen is 600 pixels or smaller the columns will stack.

-webkit is the Chrome and Safari prefix. You should probably substitute it for -moz. -moz-appearance That is if Firefox supports the appearance property.

I'm not assuming they use the same procedures to get the job done, I'm saying that the end result, in theory, should be the same as the W3C says. Yes, the website looks wrong in Internet Explorer, and the problem should be quite simple to solve. Once the website is properly working in other browsers only minor changes need to be done to get it to work in Internet Explorer. The problem now is that text is appearing bold where it shouldn't be. This appears more likely to be a mistake in the code rather than an Internet Explorer bug. Until I see the actual page in question and inspect the DOM I cannot pinpoint the core of the problem.

You wouldn't have to be two hours decrementing the percentage. There's a particular mathematical reason why the elements are stacking and it's important to get to the core of the problem rather than continue making adjustments until it works. If subtracting small amounts from the percentage values to prevent rounding errors doesn't prevent the stacking on the first try that means that padding or margins are causing the problem. So just get straight to it. If the padding or margins are in pixels the stacking will always occur at one point or another, so for the outermost containers I recommend setting any margins in percentages as well. So here's a two-column example of percentages that will add to 100%, and taking rounding into account to prevent stacking. To prevent these rounding errors, we can assume that 100% is 960px, so 1px would be 100 * 1/960 which is approximately 0.1042%, we can make that 0.11% to ensure that smaller screens don't cause stacking either. Left column: - left-margin: 0.5% - right-margin: 0.25% - width: 64.25 - 0.11 = 64.14% Right column: - left-margin: 0.25% - right-margin: 0.5% - width: 34.25 - 0.11 = 34.14% Total: 0.5 + 0.25 + 64.14 + 0.25 + 0.5 + 34.14 = 99.78% If your window is 960 pixels wide your page will only be off from the desired layout's position by two pixels. The layout is guaranteed not to cause stacking assuming you don't add padding to the boxes. If you want to add padding you'll have to also take it into account when doing calculations.

I'm just bringing up general conventions that web developers follow and the reasons why they're followed. Standards compliant browsers all render websites the same way. A lot of sites that look great in Internet Explorer could appear to be a mess in other browsers. Internet Explorer isn't t he "lowest common denominator" in the way that it's the one that makes pages look worst, it's just different which means that pages that look good in it look bad in other browsers, pages that look good in other browsers look bad in it. Though recent versions are much closer to standards than versions 8 and under.

Setting to 30% and 60% is exaggerated. When working with percentages, a 1% difference can easily be up to 10 pixels. Since the rounding errors caused by converting percent to actual pixels will cause a difference of, at most, one pixel you only need to make tiny changes to the percentage values to prevent stacking. You only need to change probably 0.5% at most.

That is a bad idea. If it looks decent in IE it could possibly be a total mess in other browsers. Because Internet Explorer is the odd one out, you should get your page to look right in other browsers first and then make small tweaks to get it to look right in Internet Explorer, using conditional comments to load IE stylesheets, for example.

Remember that percentage widths aren't including margins and padding. Be sure to set those to percentages as well and that adding them won't exceeed 100%.

<!DOCTYPE html> works as it's the HTML 5 doctype. Unfortunately, I can't find anything in the code you've shown that could make the text bold in Internet Explorer. One problem in your CSS is forgetting to specify units for the non-zero value in this line: margin: 0 1 0 0; If you could show a link to the working page I'd be able to find the problem quickly.

You cannot call the header() function after any HTML has been printed. This part of the code should be at the very beginning of the page: $login = login($username, $password);if ($login === false) {$errors[] = 'Esa combinación de Username/Password es Incorrecta';} else { // set the user session// redirect user to home$_SESSION['user_id'] = $login;header('Location: index.php');exit();}

Your HTML needs to be fixed before being considered valid. You also need a <!DOCTYPE> declaration in order to make Internet Explorer behave. Make sure your HTML is valid here: http://validator.w3.org

Sometimes, when calculating pixel sizes from percentages, the browser might round up, causing elements to stack because they're just one pixel too wide. You can change one of the numbers, instead of 35% you can make it something like 34.75%, or instead of 65% make it 64.75%

It seems like an uncommon way to open a menu so I don't think there are pre-made scripts for it. You probably will have to code it yourself. There might be an accessibility issue with this site design, how is this menu going to work for users with small screens?

I disagree with most of the answers provided there. A lot of people are making the assumption that a form element will have properties named after the elements in contains. But what if the name of the form inputs are something like "action" or "nodeValue" for some reason?

Here's some information I found about the subject: http://en.wikipedia.org/wiki/Internationalized_domain_name It involves associating unicode characters with ASCII equivalent sets, I don't know how well implemented it is right now.

I'm afraid nested tables are one of the worst ways you could build a website. If, instead of making a second table, you just add an extra column to the first table you'll have those columns the same height as the content in the other table. But using tables to make a website layout is bad to begin with. You should learn more CSS and look for CSS layout tutorials.

You shouldn't be creating attributes because that invalidates your HTML document. However, HTML 5 allows you to create special attributes that should be considered valid by prefixing them with the keyword "data-" Here's an article about that: http://ejohn.org/blog/html-5-data-attributes/ Access the data using getAttribute() for best compatibility. However, there probably are better ways to do what you want without changing the HTML of your page, but you'll have to explain your ultimate goal.

The first method doesn't allow for that. The second method should work, if I've remembered it properly A third method would involve Javascript measuring the element and setting its position accordingly.

You won't find split() or explode() in your document because you haven't put it there yet. As for finding it in the language reference, I already linked you to it earlier: split(): http://www.w3schools.com/jsref/jsref_split.asp explode(): http://php.net/explode

There's no limit to the amount of properties an object can have, or the amount of elements an array can have, but you're confusing properties with HTML attributes. in HTML, there's a fixed number of attributes an element is allowed to have based on its DTD. The alt or data attributes don't exist for the <form> and <input> elements, so there's no Javascript property assigned to them. It also means your HTML isn't valid. If you want to access the value of a non-standard attribute, use getAttribute(). var M = element.getAttribute("data");var N = element.getAttribute("alt");

I haven't encountered a situation where a URL has to be verified. You just need to make sure they aren't allowed to start the URL with "javascript:" so the user can't mess up your site. You probably only need to check that the URL starts with http: // or https: // but you could use an expression that generalizes for any protocol (excluding "javascript:")

The lang attribute describes the language that the readable content is in. Variable names and other things aren't considered a "language" so don't worry about that. If what the viewer sees is only French, then setting it on the <html> element is good. If you have a paragraph in English then you can open it with <p lang="en">

Your CSS stylesheet on its own is already 13kb. When the browser downloads it it doesn't distinguish different parts, it downloads the entire thing before reading it. I can't distinguish different part in it either. There's still the fact that more than 20 HTTP requests are being called from your site. Does your site have a mobile version or is the page I'm seeing from my laptop the same one that mobile devices are loading? If the validator is reading your ordinary site, try copying the mobile site to a temporary directory to test it.

They have a list of problems there in the validator, which you should fix. They even provide possible solutions for each one. Here are some of the problems the validator shows: There are more than 20 embedded external resources The total size of the page (969.4KB) exceeds 20 kilobytes (Primary document: 31.4KB, Images: 842.3KB, Style sheets: 95.7KB) The CSS style sheet is not syntactically valid CSS The document is served without caching information ("Expires" or "Cache-Control" header) The size of the document's markup (31.4KB) exceeds 10 kilobytes ...