Validation woes

[lmbarns]

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 (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>
</ul>

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.

[jscheuer1]

<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>
 </ul>

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;
}

Or:

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

[lmbarns]

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...

[lmbarns]

edit:solved

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()
{
name=(y[s].getElementsByTagName("name")[0].childNodes[0].nodeValue);
title=(y[s].getElementsByTagName("title")[0].childNodes[0].nodeValue);
classs=(y[s].getElementsByTagName("class")[0].childNodes[0].nodeValue);

txt2="<img src="+pic+" alt='Character Image'>"+ "<div id='titles'>" +"<b>Name: " + name + "</b><br /><br />Title: " + title + "<br />Class: "+ classs;
document.getElementById("showModel").innerHTML=txt2;
}

Adding the red S fixed it lol....

[jscheuer1]

Don't all programming languages have reserved words and predefined constants?

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

http://www.javascripter.net/faq/reserved.htm

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.

[djr33]

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.

[lmbarns]

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...

[djr33]

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.

[jscheuer1]

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.

[djr33]

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.