Posts by MattEvans

Hm.. That's a bit too lazy for my liking.. it certainly took a lot of messing around to diagnose that type of statement as being the error cause!

I thought this might be a PHP thing, but apparently not; the same applies in C++ aswell.

Swapping the two operands to && around seems to have the desired results; in PHP and C++.

Thanks for the info.

Consider the following code:

<?php

function important_function( $i )
{
  printf ("<p>Called for the %sth time.</p>\n", $i);
  return ($i < 3);
}

function loop_with_and( )
{
  $ret = true;
  for( $i = 0; $i < 10; $i ++ )
  {
    $ret = $ret && important_function( $i );
  }
  return $ret;
}

function loop_without_and( )
{
  $ret = true;
  for( $i = 0; $i < 10; $i ++ )
  {
    if( ! important_function( $i ) )
    {
      $ret = false;
    }
  }
  return $ret;
}

?>

<div>
<p><b>Call with And</b></p>
<?php loop_with_and( ) ?>
</div>

<div>
<p><b>Call without And</b></p>
<?php loop_without_and( ) ?>
</div>

Can anyone give me a good reason why the output is:

<div>
<p><b>Call with And</b></p>
<p>Called for the 0th time.</p>
<p>Called for the 1th time.</p>
<p>Called for the 2th time.</p>
<p>Called for the 3th time.</p>
</div>

<div>
<p><b>Call without And</b></p>
<p>Called for the 0th time.</p>
<p>Called for the 1th time.</p>
<p>Called for the 2th time.</p>
<p>Called for the 3th time.</p>
<p>Called for the 4th time.</p>
<p>Called for the 5th time.</p>
<p>Called for the 6th time.</p>
<p>Called for the 7th time.</p>
<p>Called for the 8th time.</p>
<p>Called for the 9th time.</p>
</div>

To me, that makes no sense; I didn't instruct the loop to finish on the first encounter of a 'false'; if that's what I'd wanted; I'd have put in a conditional break. All I can assume is that this is some kind of bug (where the loop continuation becomes dependant on the validity/return from an inner …

Anyway unless you are running linux on something like Sparc or PowerPC you are still using a PC

I was gonna say something similar; but I thought about it a moment, and came to the conclusion: when you put linux on a pc; it becomes a "workstation" ^_-

Whether that implies that you have to put more work in, or that you get more work done... I guess that's upto linux users to debate.

It's a religion. They plagiarized the Baha'i Faith to make Political Correctness.

I don't think it's plagiarism when political ideals are based on a religion. Ignoring elitist or anti-inclusionist cults; surely it's the aim of all religions to adhere to some kind of truth; and promote and share that truth as widely as possible.

Political correctness is just two unrelated ( perhaps mutually exclusive ) words stuck together, with an implied concept of social harmony. What it connotes though, is that social harmony has to be upheld by holding one's tongue or keeping one's beliefs private to avoid offending anyone. Which almost implies, that it can only exist if created or adhered to by individuals with otherwise disharmonious social misgivings.

By definition, social harmony cannot exist as a result of legislation. Inner harmony is more important; because without it, it's difficult or close to impossible to integrate with any kind of society. Inner harmony fluctuates; and if we see an individual, with a potential mixture of inner beliefs and personal conflicts as …

You should be able to just , refresh the page ; this will clear HTML on the page.

There are a number of Javascript methods; discussed here, don't use the <meta> tag atall, because it seems you want to 'invoke' the refresh rather than have an automatic (timed) refresh.

http://grizzlyweb.com/webmaster/javascripts/refresh.asp

If you're trying to send a sparse stream of information at undetermined intervals to any browsers 'watching' a certain URL; you might want to consider AJAX ( An overused term that should relate to Javascript's inbuilt HTTP request objects ); by that means, you can execute very small requests back to your webserver from a page, but without refreshing that page. The server can send back a result, and Javascript in the page can then check the result; either request again, or modify a page based on a result.

You can make basic web-based chat clients for example, using CGI + AJAX - the browser can keep asking the server for changes in the master stream using Javascript's XMLHTTP object, add any new messages to an onscreen-buffer; and handle sending messages back to the CGI, which adds messages to the master stream, and then broadcasts them to any browser that requests a stream update; without needing to refresh the page atall.

http://www.w3schools.com/dom/dom_http.asp

Ah, don't worry; we all make them.. I made one myself in that post; see edit.

<input type='button' 
	onclick="isEmpty(document.getElementById('name'), 'Please Enter a Value')"
	value='Check Field' />

that won't validate on submit, it'll validate, but not submit. if you want to validate, you have to conditionally stop the submit, which is done by returning false within an onsubmit event. the function is right, but the call to it is not making full use of its potential.

keeping your function Fungus1487; try:

[incorrect]

EDIT:

I tell a lie! onsubmit is a form event not a submit button event:

<form action="anactionhandler.cgi" method="GET" onsubmit="return ! isEmpty(document.getElementById('name'), 
'Please Enter a Value')">
Name : <input type='text' id='name'/>
<input type='submit' value='Submit!' />
</form>

Well, thanks; but I must say, any thanks should really lie with those inspirational smilies. I'm rarely that lucid on my own. Or cliched for that matter.

That post took a good few minutes to orchestrate; I almost wish I'd resisted the urge to click the 'More' button and see which other faces I had at my disposal...

Y'kno, personally, I find these smilies more intuitive; I certainly use them more. They're also very widely supported; and they degrade well : they'll look acceptable on any system with a screen really:

^_- wink
^_^ bigsmile
-_- leave me alone
O_o eh?
O_O OMG
>_> err...
>_< grr..

of course... they look optimum in Courier/System..

You can certainly use form controls as javascript controls; there's no point implementing drop-down lists in Javascript manually for example.

Things to consider are just that; you have to put form controls in forms to validate pages correctly; and if you put a submit button on a form, it'll try to send it by whatever 'method' attribute you provide, i think you have to provide one of GET or POST as the method in order to stay compliant, but i think 'action' would be optional because a page can be its own form action. Use <button> instead of <input> for a button... Erm, catch the onClick event on the button using Javascript, and use it for whatever means neccessary.

You can access form field's data using [element].value, and there's a document.forms collection for addressing elements within forms.

So, it's certainly possible, and lots of sites do it for one-page interactivity.

Well :zzz: . I've been subscribed to this thread since I posted at the very beggining; I wouldn't think that a discussion on smilies would turn into war.. :| Chill out people :@ . You're upsetting me :'(. Or maybe amusing me :D. I dunno. :yawn:

With regard to rep :-/, if for example, someone posts something malicious in a PM :angry:, surely they're still subject to regulations :?: ? Is the information relating to the rep giver not kept atall :X ... It's a frightening :scared: system if people are allowed true anonimity :ooh:

My point, aside from the obvious attempt to remain on topic by utilising as many of the new smilies as possible in a single post :idea: - act in a happy way :) we all love daniweb :* or i guess we'd be doing something else right now. don't make each other sad :(, even if you enjoy doing so :twisted:; because that's an embarrassment to your own intelligence :sad:.

Er. this one still scares me senseless by the way: :pretty: Whatever way I try to look at it; those are eyes, not cheeks.

I still get an error when i have the <hr /> out of a <p>. It says that it shouldn't be there...

Hm.. maybe it needs to be in a container; but not the body, that is, you should enclose {everything} inside a big div in order to be able to use <hr/> at top level. It's a wierd rule that, only in XHTML strict I think.

I'm afraid I can't change the textarea now, everything depends on that...may I ask the "haky" way? thanks again

Well. One way is to set the textarea's borders to nothing ( I think, in CSS "border-style:none;" should do that ) and put it inside a container div with the same background color, which is a little bit higher than the textarea itself; then apply a border to that div. That way, it'll appear like the textarea never changes size, even though it does a little. It should only be a little bit bigger; because the size difference is just a compensation for the textarea not being at a multiple of the row height high; BUT that'll only work if you set a specific height for the textarea, and make sure that you DON'T specify the textarea's 'rows' in its attributes (because will probably override the prefered height).

If you're not using borders on the textarea anyway, and it's just pushing the content underneath down a bit, still put it inside a div with a slightly oversize height... It's a bit like, …

So how do I make a real copy of the array that I can change without affecting the original? Do I need to loop through all of the elements and copy them individually?

Pretty much; unless Javascript has an Array.copy() function or similar... inbuilt functions might be better optimized, but I doubt it'll make much difference in this case.

.. well, according to this page, one can hijack the Array.slice() method ( which is supposed to return a copy of a segment of an array ) to copy the whole Array.. I really don't know if that would be any more efficient than manual copying, but maybe it's worth a benchmark if you need the speed:

http://www.sematopia.com/?p=12
( Read the comments; the original poster seems to have ommited a neccessary parameter, and someone there explains what happens if you copy arrays of arrays or other arrays of references with .slice(); if you do so, you might want to do it manually, just to retain control )

you cannot put a <hr/> inside a <p>... you shouldn't put anything that constitutes a block ( this includes hr, a div, or another p ) inside a p

For example:

<p>This is a paragraph!</p>
<hr/>
<p>And this is another</p>

It's usually quite easy to terminate <p>s correctly..

To horizontally center any block level element (like a table) you can use CSS like this:

table.center
{
margin-left:auto;
margin-right:auto;
}

With your textarea; in some browsers, they adjust their height to a multiple of the row height ( which is affected by the font-size/family ).
I would say, you might be better off using a different element to display content. If you don't want the textarea font to change but you're changing a page-wide (body) font; you might want to exclude the textarea, by means of giving it a certain font/size in CSS. Otherwise; you may have difficulty getting around this in a 'non-hacky' way. You can set the 'line-height' in CSS; but if it's small, it crops the top/bottom of big text..

You should use a CSS style to set margin or padding attributes, the W3C won't like it otherwise, infact, I would personally advise that you do so; for reasons pertaining to better project mangement, quick continuity, reducing code repitition, and 'staying cool'.

On the body; these two properties get a bit mixed together, because the body's margin takes from the same space as it's padding, which isn't normally how margin and padding work.. So, to clear the margins on the left and top completely:

<body style="margin-top:0;margin-left:0;padding-top:0;padding-left:0"/>

or put this in the <html<head>:

<style type="text/css">

body{
margin-top:0;
margin-left:0;
padding-top:0;
padding-left:0
}
</style>

or stick it in an external stylesheet and use it everywhere! The possiblities truely are endless.

It's neccessary to manually refresh every page after navigating to it. This is OK, but I keep thinking old pages are current (i.e. if I navigate into a forum that I visit frequently, it might still be a listing from a few hours ago, thus I wont see any changes, unless I remember to refresh).

This wasn't always the case, pages used to come fresh on every request, except 'back' button which is a browser thing..

To Dani of Daniweb; I'm guessing from your post in HTML/CSS/JS, that you're refining the cache rules for pages.. Have you decided on the 'fresh' time for pages that show things that change frequently? Maybe expiring them every 30 mins or less would be good... Otherwise, I can't give any suggestions; cache rules are a bit of a beast for forums especially...

It's not a real concern, I can learn to live with it, but is this going to be a permanent thing?

the problem you're having is related to references/pointers vs values, which is something JS handles automagically.. ( by passing all non-primitives by reference, similar to Java )

so, when you pass an array into a function, a reference to the array is passed. if you do anything via that array reference ( i.e. change the value of a subscript ) it will be working with the array instanced in the function caller; this is what's happening in the case of 'd' or 'z'.

however, the assignment operator in Javascript (i.e. y = z ) will not affect the referenced array, it will affect the reference itself. There's certainly two different approaches that could be implied by '='. Indeed that's why languages like C++ have values, references, pointers AND operator overloads to clear up any ambiguity.

Think of it like this, in an abstract sense, you have your array, which is made up of a 'handle', an 'array' and some values. They are connected like this:

( we don't see the italics )
[I]handle > [/I] array > *[values]

your calling routine has a handle, when you pass the array to your function, it gets it's own handle to the same array. So in a called routine:

array[n] = 0

means; via my handle, access the nth element of the array, and set it's value to 0. Anything else with a handle to the same array will see the change; so inside, we can imagine it …

Personally; I'd prefer to recieve plain text email.

The biggest problem you're likely to hit with email + CSS is linking... for the same reason pictures from remote locations don't load by default; linked CSS ( i.e. link href="" ) isn't going to load by default. There's a risk of someone operating spam emails that invoke cross site scripting attacks (webmail only) even attempt distributed denial of service attacks ( webmail or email applications ) if remote resources are requested upon opening an email.

The only other problem you might run into would be if email clients used their own stripped down parser/renderers; and if those renderers didn't implement CSS fully. For the reason I've already mentioned; CSS shouldn't be implemented fully in email clients; because there are CSS properties that can invoke downloads from remote locations ( background-image for example ).

Ideally though; an email client shouldn't block all CSS to prevent such occurances; it should block whatever module it is that fulfils remote downloads.

How exactly are you using CSS?

<span style="font-family:Arial;">inline?</span>

<style type="text/css">
span{font-family:Arial;}
</style>
<span>embedded?</span>

<link rel="stylesheet" type="text/css" href="http://yourdomain.dot/email.css"/>
<span>remote?</span>

The only other problem you might hit is rendering differences in email applications, if they use OS specific controls; those'll likely be the system's lowest common denominator (i.e. My old MS Outlook will use the same HTML rendering component as MSIE5; regardless of the fact Opera is my default browser ).

These pages might help; they …

Folder nesting doesn't need to be too deep.. About a depth of 3 is probably more than enough; provided there's some top level grouping*. Any more; it is just over-classification, that could probably be better solved by tighter / stricter classification.

I gotta say, there's a big difference between centralizing the application and centralizing the navigation experience / interface about an all serving singularity.. The application can be centralized and act upon a distributed collection of files as they are requested; by means of handlers; even mod_redirect. That's quite different from using one script as the means of serving all requests; it's certainly my prefered technique =P. Hey; I'd rather not go too far divulging my own behind-the-scenes work; but I use that as a way of getting the best of both worlds - I can keep my application high up in /home/me; but still use it to process XML-based scripts in any folder a user requests... as long as the file ends '.xrm'.

Hey... with Java; it's worth the trade-off sometimes. Other times; perhaps not. The whole Java structure-of-an-application, although rigid, affords flexibility; and forces a developer to conform to good organisation practises ( hey; that's an opinion =P ). C++ is a more interesting language for sure; but Java is a powerful language in terms of capability; and the fact it doesn't need to be recompiled for every target OS is a huge advantage in my eyes.

Hm.. C++ Templates whup Java Generics 10 times …

Mmm... for web dev I like URL based file organisation to a degree... It depends alot on the system that's in use though; some systems work better if you organise your application code around the locations where a user is likely to use it, and in a way that's a background intention to PHP; "I can put a program anywhere on my server!". Although; personally, I don't think PHP itself brings many new principles to ANY kind of development.

What I personally dislike; is the seemingly magical index.php; which spits out different content based on a 'page' query string - I like folder division and file-naming based about functionality; in the same way as I would when working with Word documents offline; I like to see 'descriptive URLS' that indicate the web developer has a modular, flexible, and most importantly content-centric site... Otherwise; if it just feels like a site, that is clearly organised around one central, versioned 'application', that feels like it isn't going to be a constant source of useful information. And hey.. don't use URL rewrites to mask out your index.php?page=home.. I'll see right through it ^_-

That applies with or without server-side code; HTML pages have an inner hierachal structure; it makes a helluva lot of sense for that hierachy to spill up into the filesystem aswell..

Program code organisation; I need some levels in there; it pertains to easier updates; plugins; automatic compilation rules; even runtime 'special effects' if it's an interpretted …

Take out the ;charset=UTF-8 part of the content type meta header, and any UTF-8 content type header you may be sending at the server. If you are using an <?xml etc ?> directive, take out the charset (or is it encoding?) attribute.

Your page reports being encoded as UTF-16LE... But if you try to serve it as that when it's not encoded as that, then it wont help you much. Is that page the result of server side software ( i.e. PHP etc ) that might be adding anything to the page's HTTP header?

Can you post the original page source? In view source it comes up with those foreign characters also.

Mm, maybe so with regard to planning for the future; but the original poster is clearly using frames at the moment; which are likely to be supported in major browsers for at least a few more years.

XHTML and HTML strict do not have the target attribute; it wasn't deprecated, but it is not a part of those standards. There is a big difference.

Not all web development involves producing latest standards-perfect HTML creations. If I am demonstrating some purely functional server side code for example; and I know a web designer is going to be making a fancy standards compliant frontend for it; there's no reasonable reason why I shouldn't use frames and targets temporarily.

Many professional sites still use frames, and even archaic document types. Offline HTML help for big products often uses frames; they work offline without giving security warnings, and pertain to a handy split between an 'index' and a one-page display.

Mmm.. I didn't read your original words clearly with regard to the component internals; seems we agree. It's a point worthy of being re-iterated numerous times though; that it's more important to maintain consistency than conform to someone else's practices.

With type prefixing; the developer at some point has to make a reasoned abstraction of the variable's type description - and that abstraction has to facilitate flexibility; there's no point calling a variable iNum if it might be changed to a long-integer at definition later; and prefixing all long's as 'i' to avoid that problem is obscuring type information informally, that would pertain to lesser readability, even confusion.

That was a somewhat contrived example. In a perfect system; there wouldn't be many names of fully qualified classes sitting around in hard-coded routines; but unplanned systems often start out imperfect =P.

MidiMagic; again, please; do not jump to the assumption that the person posting is using a strict document type - the target property does not exist in the strict document type definitions for XHTML 1.0 and HTML 4.0.

It has not been deprecated; and is a part of the XHTML and HTML transitional doctypes; and the XHTML and HTML frameset documents - infact, the frameset DTDs exist in order to provide support for this property into the future.

Notice; the html version number in this link, which explains frames / targets in alot of detail:

http://www.w3.org/TR/html401/types.html#type-frame-target

Well. Until now, 'mashup' for me; meant something done at the weekend (or any time) involving copious amounts of alcohol, etc, and an ample recovery period.

I figured this wasn't what you meant; so, I asked a good friend, Wikipedia, and by its own definition, it could be described as a mashup.

So, although I didn't know it until today; Wikipedia is my favorite mashup... oh, except for those weekend ones..

try target="_top"

In a word; No.

HTML is delivered to users as 'source code', which the user's browser then interprets. There is nothing you can do to protect HTML code; except trying to enforce your copyright if it's stolen.

Also, you can't easily 'scramble' or obfuscate HTML code as you would with other types of code; because even subtle changes will often have some visible effects.

The best you might get, is encrypting the page, saving it somewhere on your server; and responding to requests with a blank page that runs a Javascript function to collect, decrypt and display the page content.

But, as you can't encrypt Javascript programs either, and since you'd have to send a link in the page to a program that can collect and decrypt your pages; it's gonna by like holding sand in a sieve...

Still, you might be able to do some funky business at the server to hide the Javascript code by means of checking the referer in an HTTP header... so that only your pages can link to the JavaScript code. This still has drawbacks; some browsers might let a user see post-JS source code ( and all browsers have to download the code, and most cache it somewhere ); and it's going to greatly increase the loading times for your pages; and the pages' contents will be totally indeterminable by a search engine spider.

Check out this page:

http://apptools.com/examples/tableheight.php

the important part is this CSS snippet:

html,body{
      margin:0;
      padding:0;
      height:100%;
      border:none
   }

in a test with a new w3c doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html style="height:100%;padding:0;margin:0;border:none;">
<head>
</head>
<body style="height:100%;padding:0;margin:0;border:none;">
<div style="height:100%;background-color:blue">Anyone would think I've used a background color...</div>
</body>
</html>

This seems to work as expected in opera and firefox..

So, if you use that style in your page, anything you make as 100% high should be the height of the page at minimum, and otherwise as big as the content on the page, and not only in quirks mode..

The margin isn't an addressable area; it takes the colour/image that is assigned to the background of the outer container.

A given container has a padding (space inside) a margin (space outside) and I suppose a border (space between). Setting a margin or padding sets an amount of spacing around the border or inside the border; you can't change the background in a container's margin without changing the background of the container that respects the margin (usually the container's parent container), and you can't change the background of a container's padding without changing the background of that container.

Border is quite a useful property... you can make partial borders that are 0 - ? px / % / pt thick, and set a block color, this will act like a big coloured margin.

Margin styles don't exist per-se... The margin of the body tag works more like padding does in other containers; that is, a non-zero ( and positive ) margin on the body pushes content into the middle of the page. On any other element; a positive margin pushes content away from that element. <edit> or perhaps, it pushes that element away from other content.. depending on which way you look at it</edit>

I'd be interested to know if min-height: 100% works... if it sorts out scaled elements, it should sort out the half-page backgrounds I keep getting...

sorry, my mistake, that first example should be:

<body onload="document.forms[0].elements['uname'].value = GetParam(username);">
...same as before...
</body>

you're not calling the function, you're writing the function name. calling the function is only possible from a <script> block or from an event handler attribute...

to call the function when the page has loaded; you could do this:

<body onload="document.forms.uname.value = GetParam(username);">
...same as before...
</body>

alternatively, replace the input with;

<script type="text/javascript">
document.write('<input type="hidden" name="uname" value="');
document.write(GetParam(username));
document.write('">');
</script>

(beware of the quoting here, each document.write uses a ' to quote its parameter, but there are " quotes inside each parameter..)

both of those methods are a bit 'hacky' for various reasons; neither is perfect and neither will work without Js. I'd certainly advise using PHP or similar to get the form data and alter the page; it's not a good job for javascript.

There are quite a few errors... Firstly, the keyword is 'function' and not 'fuction'. Secondly, in this line:

<!---Hide from non-JavaScript browsers
//This function Displays the Daily Dinner Specials at Kelsey's Diner

The phrase "Hide from non-Javascript browsers" will be parsed as script; you can stop that with commenting, a'la:

<!---//Hide from non-JavaScript browsers
//This function Displays the Daily Dinner Specials at Kelsey's Diner

Thirdly, maybe it's just been missed in your post, but there's no calls to either function DishName or DishDesc; so, it does't matter what happens in those functions, they will never be used.

Fourthly, perhaps this is a problem with the way you've pasted the code, but there should be line breaks in there. The most important ones are the ones that follow lines of comment; without a linebreak, everything from here: "//This function Displays " to the end of the script element is a javascript comment. Otherwise, linebreaks are good practice; they make it easier for you to read your code, and certainly make it easier for other people to read your code..

Using a debugger is good advice, but most debuggers will fail at the first error, and won't give helpful feedback ( like the line number where an error occured ) if your code is on one line..

:ooh: they're not so bad..

i don't see how this one is 'pretty' though: :pretty: looks to me like it's got red eyes and enourmas eyebrows.. :scared:

I'd be up for that. My girlfriends been wanting to go to Liverpool forever ( she's an LFC fan ), so she'd enjoy coming aswell.. but maybe not; because nothing bores her more than 'geek-talk' =P

Liverpool's about as far from the south-east that I'd be willing to travel to... I don't drive.

I would suggest not using layers. Split your background frame image into more pieces ( top, 2 sides and a bottom ). Use a single table with the top image on the top cell, side images on the side cells, and a bottom image on the bottom cell. Something like this:

__________
|     T    |
|__________|
|  |    |  |
|L | C  | R|
|__|____|__|
|    B     |
|__________|

Where L = left image, T = top image, R = right image, B = bottom image.

Where "C" is, you should be able to use a background color rather than an image. If you must use an image, it should be a repeating background image on the table cell rather than an img element.

In the "C" cell, write your content.

The problem with layers like that is a lack of any kind of relationship between the layers... You can't enforce a relationship without using hacks or scripts.

I'd be more inclined to run Perl on Windows than I would be to run ASP on *nix ^_-

Java is a good bet for sure-fire compatibility; but, to the original poster, you'll need to know and understand the difference between compiled programs and source code. I suppose, the main advantage ( and strangely the main disadvantage ) with PHP/Perl etc, is that the source code is the program.

Unfortunately, I've never found a good "beginners tutorial" to CGI, that isn't focussed on a specific language, too complicated, or too empty of substance; The best advice I have is to Google "CGI" or "form handling", and follow links until you have enough information to do what it is that you need to do.

Try using a padding-top:10px for the main div instead of a margin-top:10px for the child div, and a padding-top of 10px on the body instead of a margin-top on the main div.

I can't tell you why it doesn't work; but it doesn't seem to work on Opera either o_O

Document.write( ) only works reliably in the 'loading' period of your page. Something like this:

<html>
<body>
<h1>Title</h1>
<script>document.write("My page content");</script>
</body>
</html>

Will work how you might expect; but calling document.write( ) after the loading context ( i.e. from a user-invoked event like clicking a button ) has that effect of re-writing your page entirely. I don't know whether that's the officially specified behaviour, but most browsers do that.

document.write( ) is a frowned upon technique these days. anything you can do with it can be done using a server-side script, which can make efficient use of caching; and doesn't depend on the client end to perform page generation.

You can use code as below to get 'seamless' output on a page; this is equivalent to putting the output in a textfield/box/iframe, but the output text won't have special wrapping/rendering rules:

<html>
<head>
<script type="text/javascript">	
	var rem=0
	var t
 
	function startT(t)
	{
		rem = t
		timedCount()
	}
 
	function timedCount()
	{
		if(rem==0)
		{
			document.write("Time Over.")
			return
		}
		[B]document.getElementById("output").innerHTML = "Time Remaining: " + rem + " msecs."[/B]
		rem = rem - 1
		t = setTimeout("timedCount()",200)
		
	}
</script>
</head>
<body>
	
	<input type="button" value="Start" onClick="startT(10000)">

[B]<span id="output">?</span>[/B]
</body>
</html>

You need to write some kind of program to run on the server; that accepts the data submitted in the form and outputs it to the text file. Such a program might only be a couple of lines long; but it needs to be there.

This program needs to be stored on your server in a publicly accessible folder with execute permissions ( I can't give any specific tips without knowing your server OS, and what lang you'd want to write the program in; but putting the program in the cgi-bin folder if you have one is usually a good way to give it execute permissions implicitly ). You then set the form's action attribute to the URL for your program.

For writing the program; if you use a scripting language like Perl, PHP ( or ASP if you have a windows server ); then you won't need any special tools other than a text editor and an FTP client.

Do some research into CGI ( the common gateway interface, which is a part of the means by which form submissions are sent to programs ), the languages PHP, Perl, and/or ASP, and file access in those languages.

hmm.. you could try this approach:

have the page load up with the <body> element either disabled or un-visible, specified in the element's inline "style" attribute. i.e.

<body style="visibility:hidden;">..

at the end of the javascript file that you want to be loaded; add the line

document.onload = function() { document.body.style.visibility = "visible";};

You might even get away with just putting

this.style.visibility = 'visible';

into the body onload attribute directly; because onload shouldn't be called until the page is infact loaded.

you may need to put the page content inside another container object (<div>) if you find that visibility doesn't work on the body element.. display:none; is another way to turn of visibility; to undo that, set display to nothing ( ..style.display = ""; )

erm; also, the page wont show atall unless a script is linked that turns it's visibility back on.. so, think carefully about non-JS users who still have CSS =P

Aaah... it's a difficult one. Height 100% doesn't work in XHTML; it means '100% of the height of everything on the page'. So, if there's nothing on the page, 100% height is nothing. This even affects background images in some browsers... specifically Firefox if I remember correctly; the background image only covers the area from the top of the page to the bottom of the last piece of content; so if the page is very short in terms of its content; it gets a short background.

Wierd; but it seems that the functionality is either, not well standardised, or deliberately standardised in a way that goes against the largest of 100%-of-inner-window and 100%-of-content approach, which, in my opinion, is more intuitive and useful.

You can keep using 100%, and force the height of the div's immediate parent container to have a non-zero height that's close to a reasonable average screen height ( even specifying this on the <body> element should work ). The div should then always fill the same height that all content on the page fills, and it shouldn't ever be smaller than a screen, but, it might always be bigger than most screens..

I can't give a good one-size-fits-all solution to this problem, because I've never found one myself and it's a problem I've encountered quite a bit with various layouts.. Personally, I'd design without that aspect deliberately because I know it'll be problematic, or if it's absolutely essential, use Javascript to adjust with …

What does the code look like when you view-source in a browser ( i.e. after the PHP code has been executed ). Post the same code after PHP, and check to make sure those echos don't put invalid characters inside the value attribute.

Are you using an XHTML DTD, a HTML DTD, or no specified DTD? [ that code uses HTML tag closure rules, so you shouldn't use an XHTML DTD, a HTML DTD is preferable, but no DTD should work functionally ]

Try putting the form element outside the table element ( i.e. <form><table>..</table></form> rather than <table><form>..</form></table> ). Only certain things should go directly inside <table> elements ( tbody, tr etc )

EDIT: Oops; I didn't see the solved marker on this thread... How did you solve the problem in the end?

try this:

<h5><a href="deapajobs.html#job1">PA Maine's Community Health Centers</a></h5>
...
<td colspan="2" class="jobtitle">[b]<a name="job1">Physician Assistant</a>[/b]</td>

I think, you should be able to use anything with a name as a bookmark target ( but I can't seem to find anything that confirms that explicitly ). Old behaviour used to only use names of <a> elements as bookmarks; perhaps IE7 is only respecting that behaviour..

Are you using a document type definition?

I use iNum, sNum, isNum, hasNum, lNum, dNum, fNum, etc. which are C & C++ common naming conventions... camel case and all.... I am sure most of you looking at those have NO trouble figuring out what TYPE each of them would hold...

I stopped using those conventions when I started using object orientated languges... iNumber, etc, works ok for numbers, strings etc, but when you're using references to custom types/classes; what's correct?

Something like objReference is always going to work; but it's as bad as just 'reference', I suppose it's always possible to abbreviate a class: vctMyVector, lstMyList etc, but it's harder when using custom types/classes that have very literal names, I have an anecdotal 'box' class for example, that draws boxes ( as a classic example ) - so all references to objects of the box type can start with the prefix box - a'la boxTheBox; but I might have another class that acts as a 'box' of variables ( maybe a 3D array ), we have boxForDrawing, boxOfVariables, or drwboxMyBox, memboxMyBox... ahh... I like not...

So, I stick with short, unprefixed names that describe the context of an object within another; memoryPool for the memory box, drawObject for the drawing box. Heck I don't like camel notation either : so it'd be memory_pool and draw_object. Then, if I change the type of a memory pool to some 8 dimensional structure, it can still be a memory_pool, if I decide circles are nicer than boxes, it …

i comment as much as i can, but only in short bursts.

ahah... same here, i think 1hour's documentation to 10 hour's coding is a reasonable ratio... it's not just laziness either; i might change something, and then I'd have to rewrite the documentation aswell as the dependancies =P

i don't like inline comments anywhere. just big explanative descriptions infront of functions or at the end of each file. i like doxygen/javadoc type tools; that make funky documentation minisites based on "super comments" in code. commenting inside functions; only ever to disable parts of the function, or to say "//\todo FIX THIS!" or similar

i would certainly never comment HTML except as a means to prevent it being displayed temporarily; i indent HTML to my own style - completely rigid nested indentation rules makes some files look like the himalayas sideways ;)

i think languages like PHP, Javascript, and to a lesser extent Perl (and others, [ including VB6 without Option Explicit]), almost encourage lax instantiation of variables, and maybe "bad programming practices"; just because they allow it to be done, if they didn't allow it, people wouldn't do it. but because the interprettor doesn't care, certain developers don't care.

in my opinion; it's even MORE important with an interpretted type-loose language to follow , at least some kind of standard. it's much easier to make stupid mistakes than with a strictly typed language.

but saying that, i take much more pride in work that …

it's permissable to write <script> in the body section; be aware that the script will run at weird times though ( as the script element is parsed ). the only way the script you have got WILL work is if part of that script runs as the body is parsed; because you use document.write( ); which is parse/position dependant ( i.e. you NEED the script to run as the script element within the body is parsed )

be aware; document.write( ) doesn't work in browsers like Firefox - when they goes into 'true' XML parsing mode. That XHTML DOCTYPE might send Firefox into XML mode... in which case; Firefox will do unpredictable things with document.write ( i.e. nothing ):

http://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff

I would say you'll be alright; since I doubt you're sending your XHTML page with the application/xhtml+xml content type header - but regardless! document.write( ) isn't 'permitted' in XHTML:

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

try the code that manal posted; but stick a nice HTML4.0 transitional Doctype on top; instead of that XHTML1.0 strict one

Add some CSS a'la:

body
{
cursor:crosshair;
}

or, put it directly in the body tag:

<body style="cursor:crosshair;">
... body stuff ...
</body>

It should set the cursor how you want; while the mouse is over the browser window (or browser tab) that your page is open in.

There is an XSLT extension for PHP:

http://devzone.zend.com/node/view/id/1302

I think it's just a frontend to an existing XSLT processor.

I don't think PHP itself is designed with XML processing in mind; but you could write PHP script to parse XML/transfer XML segments between files/etc; probably even to transform XML.

But, I'm still not entirely clear on what you want to do..

Well. there are differences in the connotations each word holds; these are definitions from dictionary.com.. :):

Designer: a person who devises or executes designs.

Developer : a person or thing that develops.

I suppose, in the strictest sense, 'designers' create the foundations of ideas for products that 'developers' can then go on and create. Strictly though, 'developer' doesn't mean anything; as 'development of a design' is a valid action (which implies just 'designer'), as is 'development of a product', which, if based on an existing design is merely implementation.

In reality, both these jobs are interchangeable; and 'developer' certainly implies either designer and implementor; or an implementor working very closely with designers... that is something that can't really be judged on anything BUT the connotations/definitions of the words themselves.

Web developer is a term often used interchangably with 'web programmer', or 'web software developer'. That makes it difficult to say exactly what a web developer is supposed to do. Strictly, 'programming' is implementation to specification; but 'software development' implies design based on requirements and then subsequent implemention.

Web designer is a term often used interchangably with 'multimedia artist', that is, someone who designs the appearance of websites rather than works on the actual code of the website; although, a designer might create HTML templates, or even pages. Generally though; 'web designer' does not imply web software designer.

In some circumstances; it might be optimum to divide roles in a workplace into …

Do you want to display the content of an XML file as HTML? i.e. transform XML content to HTML..? You can do that with XSLT. Let me know if that's what you want to do; there's no point me talking about XSLT otherwise =P

The w3cschools minisite for XSLT;
http://www.w3schools.com/xsl/xsl_languages.asp

I think this is a good idea... but, you have to remember that sites like this (other sites might be different) are like, community environments rather than on-demand services.

The biggest problems you'll hit are; convincing forum owners to allow automated registrations; making sure that lots of similar questions don't end up in the same forum(s) (it's less likely if people actually come in and look at the forums first), and making sure members of forums who are answering daily surges of 'how do i do this'/'why doesn't this work', 'tell me the answer to...' type questions don't end up feeling as if they're being treated like machines.

There are things like; newsgroups / usenet and mailing lists where you can just 'ask' questions and hope someone replies; but even with those, there seems to be a certain community aspect.

What you ask is, technically not difficult. In practice though, something like that would almost certainly be met with a certain.. political oposition so to speak.

This isn't meant personally, but in terms of your use of words: If you think that it takes alot of mouse strain to log in and post a question; don't log in, and don't ask it : because it undoubtably takes more strain for anyone answering your question to a good standard to do so; and chances are its not in their own interests to answer; or even read any question you may have. Google will give you a great …

HTML, CSS, Javascript, Flash, XML, (databases in general / SQL), ASP and/or PHP and/or Perl, XHTML, XSLT, Java and/or C++

That's not exactly the order I've learnt things in; but it is the order at which I've found learning more / using those technologies useful; and I tried to make sure each one in the list was a little more powerful/complicated, and led on from the last in some way.

Perhaps throw JSP in there somewhere =P. I suppose, any other programming language is useful to a degree; the things I've listed aren't the ONLY suitable things for web-based work, but I'd say they're perhaps the most popular.

Good luck; aside from tools it's just time, imagination, dedication, and all that other stuff; to reach wherever 'optimum' is these days =P.