23 lines
2.7 KiB
Plaintext
23 lines
2.7 KiB
Plaintext
|
# Questions
|
||
|
|
|
||
|
|
1. Why does the expression `0.1 + 0.2 === 0.3` evaluate to `false` in javascript?
|
||
|
|
|
||
|
|
Because of how most programming languages represent fractions, not all numbers can be represented correctly. Just like how we can't represent 1/3 in our base 10 number system, neither 0.1 nor 0.2 can't be represented without recurring digits, and therefore we end up with an approximation. `0.1 + 0.2` is a pretty common example of this, and it resolves to `0.30000000000000004`
|
||
|
|
|
||
|
|
2. What does the `method` attribute on a `form` element decide?
|
||
|
|
|
||
|
|
The `method` of on a `form` decides what kind of HTTP request to send on submission. `POST` and `ADD` are the most normal ones to use for this. You might use `GET` if the data isn't sensitive.
|
||
|
|
|
||
|
|
3. Explain why the form fields appear in the URL when the `method` on `form` element is changed to `GET`?
|
||
|
|
|
||
|
|
There are several types of HTTP requests. Some of them are quite similar but named differently for semantic purposes. `GET` and `POST` however, are quite different. `POST` is a generic request used for sending data to a server. Therefore, the packets contain data fields, and it can even be encrypted. `GET` however is only supposed to be used to fetch information from the server. `GET` requests have no data fields. If you want to include any modifiers or data in the request, it has to go in the URL of the request (with a few exceptions for metadata such as some kinds of system information, cookies, authentication certificates etc.)
|
||
|
|
|
||
|
|
4. Why is it considered bad practise to only validate form input with HTML5 and/or Javascript?
|
||
|
|
|
||
|
|
You can't run all kinds of validation in HTML. There are only basic, but often used options for HTML validation. Javascript however can do a lot more advanced validation, but using this to reimplement everything that the browser already does for you is bad practise. You would essentially be reinventing the wheel. It also means you'd have to take care of things like giving the user feedback on what's wrong. In the end, you would also want backend validation on a real project so no one can just bypass the html and javascript validation with sending an http request directly containing bad or even malicious data.
|
||
|
|
|
||
|
|
5. When is it appropriate to use `textarea` over `input`?
|
||
|
|
|
||
|
|
`textarea` is used whenever you have a long text, such as a tweet, a paragraph or really just anything longer than a few words. If the user is going to write more than one sentence, textarea is usually easier to work with than `input`. While it is still possible to force `input` to act as some kind of textfield, it's bad practise to do so. The text type `input` tag is really only meant for short entries such as names, usernames, food preferences etc.
|
||
|
|
|
||
|
|
[//]: # vim: set syntax=markdown:
|