View Full Version : Validation woes

12-05-2011, 03:00 AM
I'm reading about block line vs. in line after being nailed by the validator.

Basically I've spent several days designing, laying out and working on the functionality for part of an online resume, on my local computer, and within Firefox while hopping over to IE every now and then to make sure it didn't explode.

I'm trying to demonstrate an understanding of html/javascript and user interfaces lol :eek: (to land an internship) but had 100 errors upon my first validation after uploading...and it's broken in IE......which basically killed any confidence I had up until that point.

It was broken on IE locally, but only after I added some ajax which I've had nightmares with trying to run locally, so I put it off because previously those types of problems went away when I upload it to a web host.


Main Question: Is there a different particular doctype that would help me? Or anything to minimize my errors and get this running in IE?

Link: http://pugetsoundtraining.com/Portfolio/index.html

Please open it in firefox only and only pay attention to the top 800px of the screen. I have a bunch of unorganized crap rotating content below the main screen I haven't given any thought to yet. It likely will be removed and linked to on external pages.

Honestly, I'm ready to just put a redirect to firefox.com for anyone that tries to access the page with IE and call it good........problem solved :) (Microsoft does that...)

I'm not begging for someone to solve all my problems, clearly there's an underlying issue in my understanding.....but any pointers as far as switching to a different doctype or something would be a tremendous help....

Or any good references you've come across.

One example of what I've been trying to debug, which is redundant in my coding, it's saying I'm using block inside in-line with this:

Line 80, Column 17: document type does not allow element "ul" here

<ul class="tabs">

is the error from this block:

<div id="charTab"><b>
<ul class="tabs">
<li><a href="#tab1">Profile</a></li>
<li><a href="#tab2">Skills</a></li>
<li><a href="#tab3">Tools</a></li>
<li><a href="#tab4">Contact</a></li>

No closing </div> tag because there's a lot more stuff within "charTab".

I would change it but that's how my tabs work for the tabbed div.......those links within the <li></li> tags are for tabs on a tabbed menu......how else would I do it?

Should I be doing classes instead of divs? I imagine I have to go back through this entire damn thing but most of my errors are groups of errors so once I solve a few I'll have solved lots.

12-05-2011, 04:04 AM
<div id="charTab"><b>
<ul class="tabs">
<li><a href="#tab1">Profile</a></li>
<li><a href="#tab2">Skills</a></li>
<li><a href="#tab3">Tools</a></li>
<li><a href="#tab4">Contact</a></li>

Without looking at anything else that's why ul is not allowed there. (the <b> tag is an inline element and cannot contain a block level element like ul. If you want all the text in charTab to be bold, skip the <b> tag and instead add this rule to your stylesheet:

#charTab {
font-weight: bold;

As long as that's not contradicted by other rules, it will work. If it is contradicted, or - say IE 7 just "isn't getting it", you can go very specifically for the li's like:

#charTab ul.tabs li {
font-weight: bold;

Or use the !important keyword:

#charTab {
font-weight: bold !important;


#charTab ul.tabs li {
font-weight: bold !important;

12-05-2011, 04:20 AM
Thanks so much John, you solved my problem in the other thread I had, I really appreciate the help.

I got it down to 8 (currently)!!!!!! errors, actually 60 of my initial 100 errors were pretty silly, not closing out a <img> tag at the end and not supplying an alt="" on the same image tags.

new build with 8 is at http://pugetsoundtraining.com/Portfolio/indexDev.html still broken in IE but chipping away...

12-05-2011, 04:29 AM

Browser makers are terrible people. Honestly other softwares' let you write far more complex programs and abstract the differences between architectures allowing cross platform compatibility.....Unity 3d does this where you can write code and port it to use in the web browser, mac, iOS, android, ps3, and other consoles with the same code.

...yet this piddly javascript/html gets held up by and completely explodes when you use a variable named "class" when I was looping through a document that has a tag called "class" and after changing it to "classs" everything operates fine in IE and FF.....

One of my javascripts had the following which broke everything until discovered:

function displayModel()

txt2="<img src="+pic+" alt='Character Image'>"+ "<div id='titles'>" +"<b>Name: " + name + "</b><br /><br />Title: " + title + "<br />Class: "+ classs;

Adding the red S fixed it lol....

12-05-2011, 06:01 AM
Don't all programming languages have reserved words and predefined constants?

Anyways, here's a list for javascript. There may be others:


But I would think almost any programming language would have the word class either reserved or predefined. So don't be too hard on javascript for that.

The main frustration in javascript and HTML is that IE often has its own way of doing things. Fortunately, with IE 9 this is coming to an end. IE 9 still supports the proprietary IE stuff. But it also will follow almost everything written for 'more normal' browsers.

There are still some differences among browsers in general, but these are getting less as time moves on. However, with the current proliferation of hand held devices comes a whole new set of cross platform issues.

12-05-2011, 08:12 AM
Well, most programming languages give you an error when there's a mistake. With Javascript, it often just doesn't work and you have to guess what's wrong. True, there are some ways to get some error feedback, but when everything varies by browser, etc., it's often difficult to deal with and it's time for guessing again.
If Javascript were actually held to strict standards (for example, giving a "parse error" as in PHP when there's a major issue), most websites would break. But eventually getting there would help-- then we'd get strict feedback and know how to write better code-- I've never had a problem with PHP telling me there's an error in my code then refusing to run until I fix it.

12-05-2011, 05:11 PM
Yea the way I finally tracked it down was by installing the dev tools for IE, which showed the problems with the js when I refreshed the page.

I looked it up and it's a reserved word in c# as well. I dunno what I was thinking. I was just transferring tag names from an xml file for gaming related stuff where there was a tag "Class" and it didn't even cross my mind it was a keyword.

I guess compiling code probably does bring up the quality standard by informing you very definitively what's holding things up.

But it's almost as if the browser companies try to make their stuff different to try to distinguish their market share from others, even if you're a competitor's user/dev, you have to at least consider them and compensate for their way of doing it.

With unity3d, you can write code in JS, which is compiled and runs at the same speed as c#, it's a proprietary JS, but the extension is .js for the files and it follows similar syntax but beefier.

Code you write in either JS, c#, or python is good across completely different platforms, code written for android with a couple clicks (and license) can be code for iOS or even consoles like wii, ps3, and xbox.....from the SAME CODE......probably because it's compiled and therefor strictly formed I now realize....

So maybe Unity's just a revolutionary company, or there's some laziness/agenda to the browser makers...

12-06-2011, 09:13 AM
There are (basically) three ways to use code:
1. Compiling: this means you take the source code and output a "program" that is a file that runs natively (probably) on the computer. It's fastest, but also least direct.
2. Run the raw code, "scripting": as in Javascript, the final "program" is the source code itself that is used in real time, such as in the browser, or with macros in a program.
3. With a language like PHP, there's actually an intermediate option, which is compiling at runtime. So it uses the source code (rather than exporting some sort of compiled program), but it compiles it as it runs, and that's where you get the error checking. There are also runtime errors (for example, two operations are in the wrong order so the first can't run before the second, eg., with a required variable not yet set), but for big errors you'll find out before it'll even attempt to run it.

So there's no reason really to keep (2) as an option except with simple languages. Using (3), or at least some sort of pre-checking would really be helpful with Javascript so that you have some idea whether the code should work or not. On the other hand, what you've found is that if this works in most browsers, you might actually not get an error (or you could get lots of errors that actually do work fine in most browsers), so it might not be helpful making it cross-browser compatible.

What I wish for JS is:
1. Create standards that are required. I don't care what they are, but guessing what will work in which browsers is annoying. Even selecting an element on a page is not guaranteed to be cross-browser compatible. Why's that?!
(I understand potentially having some experimental or browser-specific functions, but they should be labeled like that, and they should not replace standards, only add to them.)
2. Have some way (even if it's an independent program) to check the code for errors. Of course browsers have error displays, but those only work relative to the browsers-- maybe once (1) is fixed, this won't be a problem any more. But I'd still like harsher errors-- if you skip the semi-colons at the end of a line, it should yell at you-- that's just a lazy aspect of JS that is so widespread it may never be reversed, but requiring it certainly won't actually hurt anything and it makes it all so much clearer. And other things like that.

12-06-2011, 03:18 PM
I'm comfortable being referred to as an expert in the use of javascript. But that doesn't necessarily make me an expert in it as a programming language. Still I think there are some factual discrepancies with your take on javascript:

Javascript like PHP is compiled at runtime - The difference being it's compiled by the browser.

Inconsistencies in javascript can in large part be overcome using a script library like jQuery. With the latest browsers these are virtually non-existent.

For those that there are with earlier versions of browsers, what do you mean by labeled? There is extensive documentation on these browsers, what works and what doesn't.

Requiring the semi-colon now would break countless of installed scripts.

Just as with other languages, errors aren't so cryptic once you're familiar with the language and the error reporting system in use. This wasn't always the case. But today's browsers all have good to excellent error reporting if it's turned on.

But, being only an expert in its use, I could be wrong.

12-06-2011, 09:59 PM
I see your point(s), and the system works, but I don't think it's ideal. For one thing:

Requiring the semi-colon now would break countless of installed scripts.That's not an argument that it should be like that. It's just an argument that it is like that. It would be hard to change, and maybe Javascript is beyond repair, or there needs to be some sort of fallback option (eg, a compatibility mode setting in the script telling the browser to parse it as outdated code not written to new-and-improved standards). This is just one minor point.

As for scripting libraries like jQuery, that doesn't seem like a proper solution to me. They certainly work, but why do you need an extension on a language in order to get it to work? Why not just replace Javascript with jQuery (or another library)? Or better yet, why not just make Javascript standardized so that the only benefit of jQuery is that in some cases the commands are shorter?
At the moment, yes, using those libraries is a good idea. But that's only because of the situation.

I'm far from an expert in Javascript (although I can do well enough to find my way around a script and modify it as I need, and sometimes write my own). But one reason I don't spend more time with it is that I find it frustrating. (That's also because I do more server-side/database things though.)

I think (and part of this is a guess) that the summary of Javascript is as follows: once upon a time, browsers were boring and some browser decided to add some fun tricks. Once that happened, all of the other browsers in the internet decided they wanted to have fun tricks too. Years later Javascript has now evolved into an unstandardized often browser-specific scripting (not programming) language that really didn't start off as something that could or should be made into what it is today-- because of that (and other factors) we're left with something that "would break if [it were held to standards]" and is often difficult to use except for experts. We can't fix it because that would be too hard.
On the other hand, things may actually be slowly moving in the right direction and in 10 years Javascript may be standardized. Once IE started moving toward standards, that was a major step in the right directions. But as you said, mobile devices may everything complicated once again.

Philosophically, my problem with Javascript can be explained like this:
There are 3 components to using a programming language:
(1) "words" [functions, operators, etc];
(2) logical step-by-step methods for programming [not part of any specific language]; and syntax of the language;
(3) language-specific and function-specific irregularities that must be memorized, such as how to find the height of the window in Javascript.

In many languages (like PHP), it seems like you can get away with avoiding spending much time dealing with (3) and use mostly (1) and (2) only to make a decent script. Figure out the logic of what you want to do, then decide what pieces you will use to make that happen.
But in Javascript, it's not just about knowing the logic+syntax then adding individual items to fill in the spots in the process-- you actually need to know a huge amount about how Javascript is used to accomplish certain tasks-- how does it interact with browsers and/or users? Which method (when several are available) is best for a certain task?

As a linguist, it makes sense to remove as much of the pragmatics as possible. Pragmatics is the usage of language-- "meaning in context", as opposed to semantics, or the "pure"/logical meaning.

For example, it's very easy to explain to someone learning English what the structure/meaning of "What is your name?" is, and it's also very easy to explain what each of those words means individually. But imagine now trying to explain to someone completely unfamiliar with our culture in exactly what circumstances that phrase is appropriate (the pragmatics)? So, should you say that to a bus driver? A police officer arresting you? Friends? As "experts" in English, we know the answers, but it would be very hard to describe them in detail. It's exactly the same thing with Javascript. I think that JS takes a lot more practice to get good at compared to other languages where you can know plenty very quickly, assuming you understand logic and have a function reference manual/website.

12-06-2011, 10:23 PM
Interesting reads from both of you guys...

But as you said, mobile devices may everything complicated once again.

As a linguist, it makes sense to remove as much of the pragmatics as possible. Pragmatics is the usage of language-- "meaning in context", as opposed to semantics, or the "pure"/logical meaning.

Funny you mention that because one of the things with writing javascript within the confines of the unity engine is it utilizes something called "#pragma strict"

From their reference:

2. Use #pragma strict

Now the problem is of course, that you don't usually notice when you are using dynamic typing. #pragma strict to the rescue! Simply add #pragma strict at the top of a script and Unity will disable dynamic typing in that script, forcing you to use static typing. Wherever a type is not known, Unity will report compile errors. So in this case, foo will produce an error when compiling:

#pragma strict
function Start () {
var foo : MyScript = GetComponent(MyScript) as MyScript;

But somehow they can take the javascript code you develop, using their stricter standards and you can publish the same code across all the different mobile platforms, Android, iOS, etc. The only changes you have to make are in your input controls specific to the device you're publishing to...............

It's also cross-browser compliant, you have to have a plugin, just like flash or shockwave, to embed the game/video/application you make into a web page, but you don't have to put a single thought into what browser your users will have, the plugin abstracts that part of it......even with the current system...

12-06-2011, 10:48 PM
That's a different meaning of pragmatics than I meant. It's a technical term in linguistics (without an equivalent in the "real world").

As a quick example:

"It's cold in here."

The meaning (semantics): low temperature
The usage (pragmatics): please close the window

(Of course many pragmatic interpretations are possible in different situations, and some are more common than others.)

The idea is that you need to memorize not only the parts and the ways they go together, but also a lot of random usage facts about how to make Javascript work. Making a fullscreen window (for example) requires figuring out the screensize then making a window that size. But with popup blockers and various ways to determine screensize depending on the browser, it's not just knowing those parts and knowing the steps, but you also need to know specific information about those particular processes and about all (many?) browsers if you want it to be completely compatible.

12-07-2011, 03:04 AM
Making a full screen window isn't a task for javascript. It's not really a task for any language that doesn't have some access to the OS.

But getting back to what you were saying in the post before that, it seems like all you object to is:

(3) language-specific and function-specific irregularities that must be memorized, such as how to find the height of the window in Javascript.

Yes, you are sort of stuck with that because the browser is the compiler and parser. This is much like the server in PHP, where if I'm not mistaken different servers require slightly different approaches in some cases.

In javascript it's much the same. For the most part all browsers interpret javascript the same. There are some cases where they vary. This is getting to be less and less.

I would like to add a side note about jQuery. If all browsers worked the same, the advantage of jQuery would still be more than just shorter commands. Entire routines are already written into jQuery enabling the developer to concentrate more on the logic and less on the specifics of the code. Other libraries do this too, but tend to be more verbose than jQuery.

Now on to what lmbarns says about #pragma strict - If you need a plugin, it sort of defeats the purpose of standardizing things, at least in my mind. And that is if the end user is the one who needs the plugin. Is it?

Also - I don't see what the big deal is about typing. In ordinary javascript, if you don't want something to type convert, you can write the code accordingly. However, if I could run my code that works in - say Firefox, and have it work cross browser, cross platform and cross device, that would be worth something. But you also seem to imply you still need to know the device specific event handlers.

What I'd like to see, and it's already here in nascent form, is an add on to jQuery that allows it to work on mobile devices. With what there is so far, you still need to know what to do for which device. What I'd like to see is an intuitive framework where all mouseover type of events are translated into appropriate touch events according to something you can look up in a table, with optional code available to break out of those defaults when desired.

12-07-2011, 04:36 AM
I'm not sure about typing either. As for libraries, that's true, although in a language like PHP a single function, or class, can be written that will handle all of that, so it's certainly not the only way to do it. But I don't mind if jQuery is still around, but most of its appeal is cross-browser compatibility, and that seems backwards to me.

The full screen window was just an arbitrary example. Think of basically anything you'd do with Javascript that actually interacts with the browser (eg, not changing a variable's value, etc.). Modifying an HTML element, creating a popup, using Ajax, making a Javascript-based "animation", etc.

The main point may be that it's an issue of serverside vs clientside, true. But PHP users (and others?) are actually very picky about varied behavior and at least for advanced users, it's something that we can set in certain ways, such as how much memory on the server is allocated and what permissions are available. It's not necessarily portable, but it works for everyone. That's just like comparing a restaurant [PHP] to a restaurant-in-a-box that is shipped to various locations [Javascript]. But standards are more important for the second case, because that's where variations will really become a problem. With PHP, if it works for one person (even if it won't work on other servers), it will work for everyone else. And converting between servers is usually a minimal problem since most of PHP is working with text, not more complicated things. It can certainly be an issue, though.
The only people that really need to worry about it (except in changing servers) are those who write distributed PHP code, such as forum software. That's hard, in some cases as hard as writing cross-browser Javascript (or harder, because having access to all types of servers is difficult and expensive).

12-07-2011, 07:07 AM
Now on to what lmbarns says about #pragma strict - If you need a plugin, it sort of defeats the purpose of standardizing things, at least in my mind. And that is if the end user is the one who needs the plugin. Is it?

Well hopefully someday they'll have the market share for browser makers to include the plugin by default. Do they include flash plugins by default? I can't remember if I had to click anything or not last install.

I guess it's acceptable at the moment because most of the applications made with unity are games (better than flash) so people expecting games in a browser have to be willing to install the plugin. But that's only for browser applications, pc, mac and mobile app builds are downloaded and run like anything else. You'd have to have a plugin on a mobile to play an app via webpage.

However, if I could run my code that works in - say Firefox, and have it work cross browser, cross platform and cross device, that would be worth something. But you also seem to imply you still need to know the device specific event handlers.

It's basically that way except you have to have a license for anything other than pc and web builds, but you build your interactive content within the engine and publish to whatever device....writing custom classes in JS, C# or boo...

By knowing the device I mean the device input controls, you just need to know what type of controls your device will have, ie keyboard vs touch screen vs console controller....the function to move forward or fire a weapon (in a game for example) is the same either way just what input triggers it varies by device. But if you build a networked app for android, you can publish a web build and we could communicate between the two (share files, voip session, kill each other in a game) using the same code.

It's similar to flash but uses .net and allows you to import animated models from maya, 3ds, or whatever 3d modeling software then control them with js/c#/boo classes, or render websites to 2d textures via a www class or communicate with databases, etc.