View Full Version : Java not working.

01-21-2005, 02:26 PM
I recently built a site http://www.highexposures.com , and while it works perfect on my pc, none of the scripts work properly when the site is viewed from another pc. Im using IE6 and haven't even started to address cross-browser compatability, but I haven't a clue why the thing will work for me (cuz I built it on my machine and have the files on there?) but not for anyone else. I see lots of red x's, BUT the red x's are appearing (java fade) like they are supposed to. Im sure you guys will gasp if you look at my code - Im no web developer. Im learning that the design is the easy part while the implementation is the real work. Please help!


01-22-2005, 10:44 PM
Nevermind, I had my paths messed up.

01-23-2005, 03:49 PM
Im using IE6 and haven't even started to address cross-browser compatabilityIt's easier to produce a generally usable site if you start with that aim in mind. Introducing it later will probably have you rewriting the entire thing from scratch. It's also best not to use IE when developing: IE is overly tolerant and riddled with rendering bugs. Use Opera or Mozilla (both are free) and cope with IE later. In addition to the rendering improvements offered by Opera and Mozilla, they both have far superior script debugging facilities.

I haven't a clue why the thing will work for me (cuz I built it on my machine and have the files on there?) [...]Certainly in one case. I believe all of the images in the slideshow pages have a (invalid) URL pointing to a C: drive.

[...] java fade [...]You have nothing on your site related to Java. Please appreciate that Java and Javascript have nothing to do with one another. They were developed by separate companies to perform different jobs. You're using the latter. I usually refer to it as ECMAScript, which is the standardised version.

Im no web developerI'm afraid I'd have to agree, at least for the moment. However, the good news is that Web development isn't that difficult once you accept certain truths.

The first one is that the Web is not paper. Most graphical types see a Web site as a fixed canvas, just as you might in DTP. Your splash screen (Optimized for viewing at 1024x768) suggests that you think the same thing. However, that simply isn't appropriate on the Web.

Even if you don't anticipate a small-screen device, like a mobile, viewing your site, a significant proportion of users still use a resolution below 800x600, just as some use one above 1600x1200. In both cases, a fixed size layout would look horrible. A page should be usable at any size (http://www.allmyfaqs.com/faq.pl?AnySizeDesign).

The biggest implication of this is to avoid pixel-perfect design. It's not possible anyway: its rare for any two user agents to render something in exactly the same way.

The second is that HTML is mark-up, not presentation. The latter is the domain of CSS. HTML is, and always was, meant to describe the content within a document. You mark-up a paragraph because it is a paragraph, not because you want the content to look the way most user agents render a paragraph. This is the first step to producing a usable, accessible site. It also allows the separation of content and presentation which makes maintenance easier in more ways than one.

If you want to change the look of a site, in theory it is only necessary to make alterations to the style sheets. No editing of the content is needed at all. Moreover, you can specify different layouts for different media types (for example, printable versions) without having to track more than one version of each page. It also offers richer presentation options: not only does CSS give you more control (far more than presentational mark-up), you can create alternate style sheets, each of which deliver a unique design and any one of them can be chosen by the user.

Thirdly, there are only two dependable components to a Web site: the server and HTML (and even then, the latter can be flaky with some agents). Everything else - style sheets, images, Flash, client-side scripts - can either be disabled by the user or aren't implemented by all user agents or platforms. Unless they *are* your content, you shouldn't rely on their presence.

Though in your case, images qualify as the content, there are still things you should change. I'll come to that later.

Bandwidth is a priviledge, not a right. At the moment, your splash page (which are generally perceived as annoying, by the way, unless they have some purpose) preloads approximately 471KBs of image data that you don't seem to use. Even worse, your gallery preloads approximately 3.3MBs. This is blatent abuse that not even broadband users should tolerate, let alone those on dial-up.

Pages should generally be 100KBs at the most including mark-up, scripts, style sheets and images. Thumbnail pages can be larger, but not by much. The mark-up for the page by itself is 43485 bytes, which is grossly bloated (the needlessly repeated inline scripts don't help).

I won't have time today, but if I do get a chance I'll present one of the ways in which your test.htm page could be written.

Now to the mark-up. Note that nothing in this post is meant as an attack. Part of the problem is your authoring software. The rest is naivety.

An immediate issue is that you've included the same script over and over. I appreciate that you might not be capable of modifying the script to a sufficient extent to make only one version necessary, however you don't need to: each gallery should be presented separately from the others.

Whilst on the subject of scripts, you should also remove out-dated practices.
Specifically, the language attribute has been deprecated for over six years. Only the type attribute is necessary. In addition, there's no need to "hide" scripts (and style sheet information) using SGML comment delimiters. All user agents currently in use understand what a script or style element is so even if they can't use that information, they'll ignore it (as the HTML specification (http://www.w3.org/TR/html4/) dictates). If, for some reason, you do need to hide that information, move it to an external file. This is where any style sheet information or client-side script should be located anyway, particularly if it's used in more than one document.

The final item in this topic is Dreamweaver. The stock scripts produced by
Dreamweaver are, in no uncertain terms, crap. They're badly written and lead to hard-to-maintain pages. Don't use them.

Obviously, this site was produced using Dreamweaver in WYSIWYG mode. If your content isn't laid out using tables (a hack from bygone days), it's absolutely-positioned using divs (what Macromedia have dubbed, "layers"). Again, this isn't how things should be done on the Web and goes back to the appropriate, meaningful use of mark-up.

If you're new to HTML in general, don't use WYSIWYG editors, or at least if you do, use them only as text editors. To author HTML properly, you need to learn it. The HTML specification (I gave a link previously) is very readable. CSS (http://www.w3.org/Style/CSS/) is also very accessible, but it needs a good knowledge of HTML first. Currently, CSS 1 and 2 are implemented to various degrees.

You have a class name, style1. You also have ids like Layer1 and dynloadarea4. These are incredibly poor choices. They lend no indication of purpose. Class names should be chosen with semantics in mind (http://www.w3.org/QA/Tips/goodclassnames).

.style1 {
color: #FFFFFF;
font-weight: bold;
font-size: 18px;
}Aside from the class name, there are two problems with this rule:

When you pick one colour, pick them all (http://www.w3.org/QA/Tips/color). If you don't, you run the risk of producing sections with little or
no contrast between text and background. For example, if you disable images on your biography page, the text is unreadable as it becomes white-on-white. Simply specifying a background colour along with a background image prevents this; if the image isn't shown, the colour is. Even if you intend to let either foreground or background colours "shine through" from ancestor elements, you should explicitly specify the relevant property with the inherit keyword.
Be careful with font size (http://www.w3.org/QA/Tips/font-size). As a rule, if you must alter font sizes (with headers, for example) never specify the size using pixels. This prevents browsers resizing the text which is an essential usability feature. It's best to use percentages which calculates font size based on the ancestor elements. For example,

body {
font-size: 100%;
}will use the default font size set in browser preferences.
I realise that this is a lot of information, but there are lots of issues to consider when producing a site in a professional manner. Unfortunately, even a lot of "professionals" don't understand them.


02-03-2005, 05:04 AM
Thanks a whole lot Mike. Thats a ton of info and I appreciate that you took the time to write it all out. Much of it is in-one-ear-out-the-other for me, but I do recognize some of it and realize that all of it is useful. I know my site aint perfect, its also the first and only site Ive ever built. Im slowly picking up this web thing and starting to see the do's and dont's as well as the reasons for them. I needed a web presence and decided to make it happen. I know the site will go through many many makeovers. Thanks again for your help and feel free to chime in anytime you want!