ECMAScript Fahrenheit to Celsius Converter, minor problem.

@tommyweb22Apr 27.2010

So I just enrolled in a JavaScript class and I’m getting stuck with a small problem with my ~~[b]~~Fahrenheit to Celsius[/b] portion of the two way conversion.

~~[i]~~To convert F to C, you subtract 32 from the F and multiply the remainder by .55.[/i]

~~[i]~~To convert C to F, you multiply the temp by 1.8 and add 32.[/i]

Seems simple enough, yet I’m having problems with the F to C function ~~[b]~~temp2(form)[/b]

You can view the page live here:
~~[url]~~http://sfbaywebsites.com/js/ConvertTemperature.html[/url]

~~[b][size=3]~~The code[/size][/b]

[code] <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<html xmlns=”http://www.w3.org/1999/xhtml” lang=”en” xml:lang = “en” dir=”ltr”>

<head> <title>Covert Temperature</title> </head>

<script language=”Javascript”> <!–

function temp (form) { form.fahrenheit.value = form.celsius.value*1.8+32 }

function temp2 (form) { form.fahrenheit.value = form.celsius.value-32*.55 }

//–>

</script>

<body>

<table cellpadding=”0″ cellspacing=”0″ style=”width: 100%”> <tr> <td style=”width: 80%” valign=”top”> <form> <input name=”celsius” size=”15″ type=”text”> <b>Degrees Celsius</b> <input onclick=”temp(this.form)” type=”button” value=” = “> <input name=”fahrenheit” size=”15″ type=”text”> <b>Degrees Fahrenheit</b> </form> </td> </tr> </table>

<div style=”margin-top:50px;”>

<table cellpadding=”0″ cellspacing=”0″ style=”width: 100%”> <tr> <td style=”width: 80%” valign=”top”> <form> <input name=”celsius” size=”15″ type=”text”> <b>Degrees Fahrenheit</b> <input onclick=”temp2(this.form)” type=”button” value=” = “> <input name=”fahrenheit” size=”15″ type=”text”> <b>Degrees Celsius</b> </form> </td> </tr> </table>

</div>

</body> </html> [/code]

I’m not sure if I’m supposed to subtract 32 and convert 0.55 into a fraction or what. Any help would be grateful. Thanks.

to post a comment

JavaScript

27 Comments(s) _↴

@SpinnerApr 27.2010 — #I responded in your other thread.

- Christian

http://christian.lassem.com

@svidgenApr 27.2010 — #[code=html]form.fahrenheit.value = form.celsius.value-32*.55[/code]
looks like it should be
[code=html]form.fahrenheit.value = (form.celsius.value-32)*.55[/code]

@SpinnerApr 27.2010 — #Nono, the problem was quite another one.

Please check the identical thread.

@svidgenApr 27.2010 — #I don't see any other posts by this user ... link?

@SpinnerApr 27.2010 — #Oh joy..The duplicate thread in which I replied seems to have been deleted now.

Lets try this again:

1: Place your script-tag inside the HEAD-element, not between the HEAD and the BODY.

2: Cool guys add type="text/javascript" in the script-declaration

3: It is often a good idea to give items an id so you can access them by the id rather than form2.fahrenheit etc.

4: Your error is not mathmatical, but logical. Take a close loo at the content of your 2 functions:

form.fahrenheit.value = form.celsius.value*1.8+32

form.fahrenheit.value = form.celsius.value-32*.55

I have a hunch the last one should be

form.[B]celsius[/B].value = form.fahrenheit.value-32*.55;

5: It is always a good idea to finish your assignments with a semi-colon ;

Best of luck (:

- Spinner

http://christian.lassem.com

@svidgenApr 27.2010 — #At the risk of sounding like a douche, your suggestions are all pretty good, but none of them are necessary and none of them will solve the issue :o

I didn't even notice this one, though ...
1: Place your script-tag inside the HEAD-element, not between the HEAD and the BODY.[/QUOTE]
... most browsers will still load the script just fine--but you should have your scripts in either the head or the body--not between the two ?

5: It is always a good idea to finish your assignments with a semi-colon ;[/QUOTE]

Great idea, but not necessary. JavaScript "assumes" that the statement ends at the newline. Ending statements with a semicolon is necessary only when multiple statements are present on an single line.

4: Your error is not mathmatical, but logical. Take a close loo at the content of your 2 functions:

form.fahrenheit.value = form.celsius.value*1.8+32

form.fahrenheit.value = form.celsius.value-32*.55

I have a hunch the last one should be

form.celsius.value = form.fahrenheit.value-32*.55;[/QUOTE]

If you'd taken a look at the forms, your hunch would different. His form field and variable names are stupid. (sorry tommy) But, his script is successfully updating the target field with something. So, we know that it's not a field-name or general scripting error that's preventing a proper calculation.

Again, good suggestions -- but none of them solve the problem. Chances are, your teacher will harp on you for all the things Spinner mentioned. But, you're not getting the wrong "answer" for any of your syntax issues. Refer to my first post: JavaScript uses the same order of operations you were taught in gradeschool math class.

@svidgenApr 27.2010 — #2: Cool guys add type="text/javascript" in the script-declaration[/QUOTE]

That's actually a pet-peeve of mine. The language attribute is becoming outdated. As spinner suggets and the XHTML doctype requires, use [I]type='text/javascript'[/I] instead.

@SpinnerApr 27.2010 — #Gah...

Here is the whole coded working sample. The names of the input-fields are now correct, like I meant. All sorted out. closing-slashes have been added to the input-fields as well, and brackets are in the right place.

[CODE]<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang = "en" dir="ltr">
 <head>
 <title>Covert Temperature</title>
 <script type="text/javascript" language="Javascript">
 function temp (form) {
 form.fahrenheit.value = (form.celsius.value*1.8)+32;
 }
 function temp2 (form) {
 form.celsius.value = (form.fahrenheit.value-32)*0.55;
 }
 </script>
 </head>
 
 <body>
 <table cellpadding="0" cellspacing="0" style="width: 100&#37;">
 <tr>
 <td style="width: 80%" valign="top">
 <form>
 <input name="celsius" size="15" type="text"/> <b>Degrees Celsius</b> 
 <input onclick="temp(this.form)" type="button" value=" = "/> 
 <input name="fahrenheit" size="15" type="text"/> <b>Degrees Fahrenheit</b>
 </form>
 </td>
 </tr>
 </table>
 
  <div style="margin-top:50px;">
   <table cellpadding="0" cellspacing="0" style="width: 100%">
   <tr>
   <td style="width: 80%" valign="top">
   <form>
   <input name="fahrenheit" size="15" type="text"/> <b>Degrees Fahrenheit</b> 
   <input onclick="temp2(this.form)" type="button" value=" = "/> 
   <input name="celsius" size="15" type="text"/> <b>Degrees Celsius</b>
   </form>
   </td>
   </tr>
   </table>
  </div>
 </body>
 </html>[/CODE]

- Spinner

http://christian.lassem.com

@NicTltApr 27.2010 — #That's actually a pet-peeve of mine. The language attribute is becoming outdated. As spinner suggets and the XHTML doctype requires, use [I]type='text/javascript'[/I] instead.[/QUOTE]
And as the XHTML doctype is also now outdated, there is no need to garnish the script tag with attributes since, despite Mr Gates' best efforts, what alternative is there to javascript?:p

@svidgenApr 27.2010 — #And as the XHTML doctype is also now outdated, there is no need to garnish the script tag with attributes since, despite Mr Gates' best efforts, what alternative is there to javascript?:p[/QUOTE]

The XHTML doctype is outdated? I was unaware ... Inform webdeveloper.com at once!

@SpinnerApr 27.2010 — #The XHTML doctype is outdated? I was unaware ... Inform webdeveloper.com at once![/QUOTE]

I think he means the Transitional part of it ?

@svidgenApr 27.2010 — #I think he means the Transitional part of it ?[/QUOTE]

I certainly [I]hope[/I] he means something other than how I interpreted it!

@Declan1991Apr 27.2010 — #You've been given incorrect data, you're code is now perfect. The conversion rate is to divide by 1.8, which is .5555555..., which is where the inaccuracy arises.

function temp2 (form) {
 form.celsius.value = ((form.fahrenheit.value-32)/1.8).toFixed(2);
 }

That will solve all your problems.

Given that it was never possible to send XHTML to the majority of web-users, to say it was even "in" is misleading to say the least. Just because you put an XHTML doctype on a page, does not make it XHTML, it simply makes it invalid HTML unless served with an XHTML mime-type.

EDIT: You could also just multiply by 0.55556 or something like that too, but I prefer dividing by 1.8.

@svidgenApr 27.2010 — #You could also just multiply by 0.55556 or something like that too, but I prefer dividing by 1.8.[/QUOTE]
1.8 / 1 = 0.55555 ... Given the fuzzy nature of division and the fact that you can't get more than 2 significant digits from a temperature calculation, multiplying by .55 is just as good. If you wanted a "perfect" solution, you'd store all numbers as integer pairs (numerator, denominator) and perform all math with a custom library ?

But more notably ...

Given that it was never possible to send XHTML to the majority of web-users, to say it was even "in" is misleading to say the least.[/QUOTE]

... [I][B]?![/B][/I] I'm having a tough time thinking of a browser that struggles with XHTML. Thinking back on [I]my[/I] struggles with cross-browser compatibility, I seem to recall most of my issues vanishing after changing to XHTML 1.0 Strict ... Even invalid, broken XHTML has always rendered more consistently across browsers than valid HTML. (in my experience, both developing and [I]viewing[/I] sites)

If you can provide a [I]verifiably[/I] good reason to avoid XHTML, I'll start switching all my applications right now. Otherwise, the integrity granted by forcing all tags to be closed and values to be quoted outweighs the inconsequential validation errors associated with sending the wrong header, omitting the xmlns attribute, or using attributes that are not technically allowed in the XHTML [strict] doctype ...

@Declan1991Apr 27.2010 — #1.8 / 1 = 0.55555 ... Given the fuzzy nature of division and the fact that you can't get more than 2 significant digits from a temperature calculation, multiplying by .55 is just as good.[/quote]
Well multiplying by .556 is just as good, multiplying by .55/.56 can be off by a degree or more, which isn't good enough in my opinion, and why the OP though it wasn't working. In general, it's better to divide by a number you can express accurately, regardless of the accuracy you are looking for, which is why it is more usual to express 3/sqrt(2) as 1.5sqrt(2).

... [I][B]?![/B][/I] I'm having a tough time thinking of a browser that struggles with XHTML.[/quote]I hope you are joking. Internet Explorer does not support XHTML whatsoever. Simply putting a XHTML doctype on a page does not make it parsed as XHTML, so you get absolutely no benefit. In fact, if you use an XML declaration, which admittedly is not required, merely recommended, your page will be parsed in quirks mode in IE. I simply find it ridiculous to pretend to use XHTML when in fact it is always parsed as HTML in IE, and most likely in all other browsers too (unless you specifically send the appropriate header).

Don't forget the false sense of "XHTML validness". A lot of so-called XHTML on the web at the moment ([url=http://www.webdevout.net/articles/beware-of-xhtml#broken_xhtml]for example[/url]) would fail immediately if parsed as XHTML truly. Since it isn't parsed as XHTML, isn't necessarily valid XHTML, there is not point in using an XHTML doctype. There are times that is should be used, web-development isn't one of them.

And a reason to change? Hopefully HTML 5 in the near future.

@svidgenApr 27.2010 — #Internet Explorer does not support XHTML whatsoever.[/QUOTE]

On the contrary, IE has supported XHTML 1.0 Strict ("with system identifier and without an XML declaration") is the [B]one of three[/B] doctype that IE has supported in non-quirks mode since [I]Mac version 5[/I].

Source: http://en.wikipedia.org/wiki/Quirks_mode#Comparison_of_document_types

A similar chart (in a book that I don't have handy) led me to decide on XHTML 1.0 Strict to begin with. My experience with its consistent rendering across browsers is why I've stuck with it.

@svidgenApr 27.2010 — #And a reason to change? Hopefully HTML 5 in the near future.[/QUOTE]

hehe ... HTML5 comes with XHTML5 ...

@NicTltApr 27.2010 — #OK, seconds out!

It was a flippant comment - I have an XHTML book right in front of me on my desk here - bought new all of 10 years ago.

I think we can agree by now that it is not a universally accepted standard ?

@svidgenApr 27.2010 — #OK, seconds out!

It was a flippant comment - I have an XHTML book right in front of me on my desk here - bought new all of 10 years ago.

I think we can agree by now that it is not a universally accepted standard ?[/QUOTE]

Moot point. I can just as easily say that HTML 4 is not "universally accepted." (it's not)

@Declan1991Apr 27.2010 — #On the contrary, IE has supported XHTML 1.0 Strict ("with system identifier and without an XML declaration") is the [B]one of three[/B] doctype that IE has supported in non-quirks mode since [I]Mac version 5[/I].[/QUOTE]

Forgive my inaccuracy, I though it was implied since I went on to say it. IE does not support the parsing as XHTML as XML. Others do, but don't because the correct header isn't sent. In other words, XHTML is parsed as HTML for all browsers, and as I've said, many sites would fail if actually parsed as XHTML. There is no benefit in using a XHTML strict doctype over HTML strict doctype, and I've already outlined the disadvantages twice.

I like XHTML, but given that it seems it will never be fully supported, I have decided to stick to HTML 4.01. Nevertheless, my HTML is influenced by XHTML, all tags lower case, no implied attributes, attributes always quoted etc.

@svidgenApr 28.2010 — #... alright. Last post for the thread for me:

[B]1.[/B] [I]Declan, you're just wrong this time[/I] -- not for thinking you're right, but for thinking I'm wrong. You're right in saying that XHTML isn't supported fully, blah blah blah--but NO doctype is fully supported in all browsers. So, ... [I]who cares?[/I] My point was that the initial statement(s) [in this thread] regarding XHTML being obsolete and/or unsupported are just wrong. I supported that claim with a link to a table showing doctype compatibilities. [I]And that's my whole point.[/I] If you prefer not to use XHTML, I don't care ... at all. Really.

[B]2.[/B] The OP's issue is completely and entirely unrelated to choice of doctype. It was a mathematical error. And while some folks rightly pointed out that the document was structured like crap, that crappy structuring was not causing the issue. I preferred to answer the OP's question and let his teacher do the teaching ... Other's had a different preference. And that's fine.

However, I find it a touch irritating when folks find the need jump in with continuous "corrections" -- particularly ones that are irrelevant and incorrect.

Fin.

@Declan1991Apr 28.2010 — #You either are choosing to ignore, or don't understand my point, so I'll say it one more time. IE has no XML parser, so cannot parse XHTML as XHTML, therefore, IE does not support XHTML, it is parsed as HTML using the tag soup parser. That was my only ever point. You are obviously fully correct that an XHTML strict triggers standards mode, I have never said anything but that. You are totally wrong if you think there is any difference between a HTML doctype and XHTML doctype, they are both parsed as HTML by the tag soup parser. You are also sorely mistaken if you think IE can parse XHTML.

To be honest, I can't believe you don't understand that distinction given your record here, I hate having to reiterate it even once more, but unfortunately since you failed to clarify folks, I want to insure that it is perfectly clear what my correct correction is, especially considering that we were the two who solved the original problem.

@svidgenApr 28.2010 — #Alright, I lied -- one more post. I get what you're saying. But, it's not what I was refuting. I was refuting [B]your original post[/B] in both it's message [I]and relevance[/I] to the OP:

Given that it was never possible to send XHTML to the majority of web-users, to say it was even "in" is misleading to say the least. Just because you put an XHTML doctype on a page, does not make it XHTML, it simply makes it invalid HTML unless served with an XHTML mime-type.[/QUOTE]

Even if IE doesn't parse it as XML, it's still capable of reading it and displaying perfectly. Not to mention, IE has been under the 50% usage mark for several years: http://www.w3schools.com/browsers/browsers_stats.asp

I'm not saying IE parses XHTML using an XML parser--and I don't care whether it does. I care that it recognizes the doctype and does what I expect with it.

... And I care that doctype has no relevance to the OP. That's all. Didn't mean to fuss over it ... just didn't want the OP to spend hours pondering and refactoring that won't solve his problem, particularly in light of him being under the guidance of a teacher who will undoubtedly outline precisely what doctype he wants him to use, and why the SCRIPT tags need to be in the HEAD and/or BODY and so forth ...

@Declan1991Apr 28.2010 — #Alright, I lied[/quote]So will I, but just to make peace
I get what you're saying.[/quote]I'm happy with that, even if we disagree. HTML 4.01 and XHTML 1.0 are virtually the same doctype as far as modern browsers are concerned, I find it silly to use the latter.And I care that doctype has no relevance to the OP.[/QUOTE]
While I am certainly guilty, in fairness, you posted irrelevant material first, with no relevant material. I never intended to get into this discussion again.

@svidgenApr 28.2010 — #So will I, but just to make peace

While I am certainly guilty, in fairness, you posted irrelevant material first, with no relevant material.[/QUOTE]

I provided the original solution. (in my very first post even) And then someone had to go and say XHTML was effectively obsolete--which is just wrong. So, I posted irrelevant material first (with no relevant information) because I later addressed some misinformation?

I think not. And I don't appreciate the childish attitude emanating from this thread. Solve the problem or don't. Don't make a person's question an opportunity to attack someone's preferences, particularly if you provide misinformation in the process, whether directly or by inadvertent poor phrasing.

@tommyweb22authorApr 29.2010 — #His form field and variable names are stupid. (sorry tommy)[/QUOTE]

None taken, the fact that I put the JS code in between the head and body, effectively in no man's land, is retarded. Using a depreciated tag like language is beyond me, and the variable names aren't that self explanatory. I guess it was very obvious somebody put their homework off til last minute. ?

[code=html]form.fahrenheit.value = form.celsius.value-32*.55[/code]
looks like it should be
[code=html]form.fahrenheit.value = (form.celsius.value-32)*.55[/code][/QUOTE]

That makes much more sense in my head now. Thanks.

You've been given incorrect data, you're code is now perfect. The conversion rate is to divide by 1.8, which is .5555555..., which is where the inaccuracy arises.

function temp2 (form) {
 form.celsius.value = ((form.fahrenheit.value-32)/1.8).toFixed(2);
 }

That will solve all your problems.
[/QUOTE]

Awesome, that is a great method. I barely know any right now as I'm just beginning to learn the language. Thx for the addition to my mental method database.

--

Thanks for help guys, I got to this info right as it was posed and it helped for my assignment a lot. As to why there were two threads is weird, I know for a fact I only click submit once. Big MySQL DB I suppose, things happen.

As for the doctype stuff. All that does it make the page invalid as far as WC3 is concerned. It will still display perfectly fine. I don't know who to agree with on that one other than, if it's wrong, fix it and make it W3C compliant if you can. It's always great to be on point, but some times you gotta let little things go with people.

Thanks for all the help again guys.

@svidgenApr 29.2010 — #All that does it make the page invalid as far as WC3 is concerned. It will still display perfectly fine.[/QUOTE]

Yep. W3C compliance is neat, but unnecessary. Google doesn't validate. Yahoo doesn't validate. And [U]this forum[/U] doesn't validate.

In any case, I'm glad you got a solution. Sorry for my part in the bickering ...

Also in #JavaScript _↴

streaming videos swapimage <tr> color swap onmouse over

Success!

Help @tommyweb22 spread the word by sharing this article on Twitter...

Tweet This

ECMAScript Fahrenheit to Celsius Converter, minor problem.

27 Comments(s) _↴

Also in #JavaScript _↴

Success!

Social

Version

ECMAScript Fahrenheit to Celsius Converter, minor problem.

27 Comments(s) ↴

Also in #JavaScript ↴

Success!

The web is an endless sea of information. Don't miss the boat... Subscribe!

Social

Version

27 Comments(s) _↴

Also in #JavaScript _↴