jeffman

I'm not sure what's going on with the div. You lost a closing paren ) at the end of the h3#slideshow ruleset.

That's really, really old code that doesn't use best practices, so I updated it while adding comments. <script> function show2() { // get a reference to the element using its id attribute theElement = document.getElementById("tick2"); // create a date object set to this exact moment var Digital = new Date(); // get the hour // note that it's on a 24-hour basis var hours = Digital.getHours(); // get the minute var minutes = Digital.getMinutes(); // get the second var seconds = Digital.getSeconds(); // create a string with the initial value "PM" var dn = "PM"; // if the hour is before noon, change the value of the string to "AM" if (hours < 12) { dn="AM"; } // if the hour is greater then 12, subtract 12 so the hour is between 1-12 if (hours > 12) { hours = hours - 12; } // if the hour is 0 (midnight), change it to 12 if (hours == 0) { hours = 12; } // if the minute is between 0-9, put a leading 0 in front of it if (minutes <= 9) { minutes = "0" + minutes; } // if the second is between 0-9, put a leading 0 in front of it if (seconds <= 9) { seconds = "0" + seconds; } // using the data created above, build a digital time string var ctime = hours + ":" + minutes + ":" + seconds + " " + dn; // embed the time string in a <span> element with certain style attributes theElement.innerHTML = "<span style='font-size:14;color:black;font-weight:bold;'>" + ctime + "</span>"; // set a timer that calls this function every 1000 milliseconds setTimeout(show2, 1000); } // when the document finishes loading, call the show2 function // this initiates the clock window.onload = show2;</script> What I changed: there is no longer a need to test for document.all (obsolete versions of Explorer) or document.getElementById. The last one has been a standard since the last century. :)I added spaces for readability. The internet is faster than it used to be, so there is no need to save a trivial number of characters.I added a semicolon at the end of each statement. This is not a rule, but a good habit.I changed the name of thelement to theElement, which is a lot more sensible. You'll be less inclined to mistype it later.It's bad practice to create a <b> element and add further style attributes to it. I changed it to a span and added a font-weight property to the attribute string. Ideally, all that would go in a style sheet. Even better practice would be to use setInterval instead of repeatedly calling setTimeout, but I'll leave that for you to figure out. Hope that helps.

Should that be more like this? <%dim FormOpenFormOpen = Request.Form("FormOpen")%>

You can do this with XML or a relational database like MySql. XML has some advantages. It's very portable. If tag names are chosen with care, the raw data can easily be read by humans. Corrupted documents are easily fixed in a plain text editor. An entire XML document can be sent from a server to a browser and manipulated on the browser. There are times when this is convenient. A database is generally preferred when you need to make complicated matches, or when you need to search through a lot of information very quickly. Browsers also get cranky when searching and XML document longer the 150K or so (that number increases as microprocessors get faster).

You are ending your PHP documents with a .php extension, right?

It should. I just tested it. Obviously, if you want to receive something, change someone@example.com to your address. Since the form is looking for a document called mailform.php, your document should be named that. Or leave the action attribute an empty string and the form will automatically get posted to itself.

PHP has access to your entire file system (HTTP does not) and there's a lot of stuff under your webroot. You can still work out absolute paths if you want to, but do what's easiest. Glad you got it working.

It looks like you're using relative paths (all that dot stuff). If you use absolute paths, that shouldn't be a problem. That is, if "index.php" is in the webroot directory, "/index.php" points to the same file no matter where it's pointing from.

It's probably this ruleset that prevents that from happening: #dropmenu ul li:hover ul { display: block; position: absolute;} Try removing the position rule.

When you include HTML that way it works like copy and paste, so yeah. If you want to template a bunch of pages, it's the way to go. And it makes updates a snap. A huge number of corporate type pages you see out there don't really exist as permanent documents. They're just mixing include files and database results.

Some part of the drop menu (the ul and/or the li elements) needs a background color (so it's not transparent) and a z-index of 1 or higher (so it is rendered "in front of" the rest of the document). Doing that with the right combination of selectors can be tricky, so experiment. You'll also notice that your li elements don't always fit quite right, so you may want to change some dimensions as well.

At first glance, I see several things out of whack. 1. In the original, the bar seems to be contained by <td id="right">, and you removed the bar from that element in the testpage. That is not a problem, but several items are defined in the CSS like this: #right h1 { . So that partially explains why several elements don't have the style they should. 2. You changed a little of the CSS in the new CSS document. For example, #right h1 is completely missing. So I think I would start with a new, exact copy of the original CSS document. Then track down every element in the original bar and find all the CSS rulesets that apply to them. This is easily done if you play with your Inspect Element tool in Firefox (right click on something, select Inspect Element from the pop-up menu).

Do you have a live link?

Are the new documents linked to the correct style sheet? Tip: have a unique stylesheet just for the bar. Pages that include the bar should link to that style sheet.

Here's a PHP tutorial that does exactly what you want to do, and with minimal PHP knowledge.

It depends on your goals. You can communicate with your server quite effectively without knowing any JavaScript. But if your long-term goals include serious web development, then I recommend mastering JavaScript. The good news is that PHP and JavaScript have similar syntax, so knowing one helps you know the other.

When you change the structure of the HTML, the meaning of references like 'parentNode' also changes.

The tutorials here will get you started on both. Then you can work on some small projects of your own. Learn how to send form data to your server and echo it back to a browser. Learn how to save it in a database, then how to search for it. Then make a simple login system. Keep the HTML to the barebones, just enough of a framework to make stuff go. If you do go with PHP, php.net is the greatest online manual on the Internet for any purpose. Once you have the basics, you'll just sort of live there for a few weeks.

All this stuff is possible. It's also difficult. You need to know a server-side scripting environment like PHP. You need to know a database like MySql. I would learn how to do some very simple things with those before taking on the project you have described.

Sometimes tutorial writers need to choose their words more carefully. Originally, HTML was a language used for structuring simple reports, like the kind you'd give your boss. There were paragraphs, lists, headings, and not much more. The different elements had different meanings. You don't put the same content in a paragraph that you put in a heading. But you also make a heading distinctive, by using a bold font and a different font size. So formatting went along with meaning. The formatting tags also have meaning. <blockquote> isn't just a way of making a piece of text look a certain way. It also tells you something about they way you're supposed to understand that text. Furthermore, different types of browsers are encouraged to render a blockquote (or any other kind of formatting element) in their own way. So for screen-type browsers, a blockquote usually appears indented and with a vertical line to the left. A browser that reads text aloud for the blind doesn't do it that way. But both browsers use some signal that helps the reader understand that a blockquote is not the same as other kinds of text. Back in the "browser wars" of the 1990s, a lot of elements were introduced that had no meaning at all. They just changed the appearance of things. An example is the <font> element. These elements have all been removed from the standards, and we use CSS to do the job that they used to do. For me, the formatting tags are not something to remember. All I need to know is that they exist, and if I need one, I remember what kinds of things are available, and I can look them up. Someone who spends a lot of time publishing scholarly articles might need to remember a lot of those tags. Whether you need to remember them depends on the kind of work you do.

I don't know what you mean by HTML source code in this context. What you seem to be looking at is your browser's internal way of representing the CSS rules you defined as well as the default values for that kind of element. The default background color for most elements is transparent. If you had a rule that defined a background color, I'm sure that is the value you would read. Either way, a background image is always rendered instead of (or you could say, in front of) the background color. Whatever problems you might be having are NOT being caused by the transparent background; something else is causing it.

async: false Add a comma after this line.

I meant that as a last resort. The solution you've been trying should be robust enough. If you want to post all your code, maybe one of us can see something else that's affecting the process. A live link would be ideal. You could even PM me the address if you don't want the whole world to see it.

OK. Here are the two documents I used, exactly. I doubt the jQuery version matters. Tested in FF10 and IE8. HTML <!DOCTYPE html><html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title></title> <script type="text/javascript" src="jquery-1.9.1.min.js"></script> <script type="text/javascript"> window.onload = function () { var resultat = $.ajax({ url: 'serveur.php', dataType: 'xml', async: false, success: function (data) { var noms = $(data).find('photographie'); alert(noms.length); } }); } </script> </head> <body> </body></html> PHP <?php $doc = '<?xml version="1.0" encoding="UTF-8"?><serie> <photographie> <nom>_DSC4689</nom> <format>3_2</format> </photographie> <photographie> <nom>_DSC2359</nom> <format>3_2</format> </photographie> <photographie> <nom>_DSC4632</nom> <format>3_2</format> </photographie></serie>'; header("Content-Type: application/xml");echo $doc; ?>

I checked the javascript I sent you with the XML you posted in #7, and the same content-type header. I also validated the XML at W3C. It's fine. If that is the same output that your PHP produces, then it should be OK. What do you mean when you write this: "There is simply no display."? By any chance are you using MSIE? Older versions had problems recognizing XML text as an XML document; I assumed jQuery used one of the known workarounds. As a last resort, you could always convert the string.