Creating Forms - 10

particletree.com is not working.

@Joe: WebArchive to the rescue:

http://web.archive.org/web/20100811001848/particletree.com/features/rediscovering-the-button-element/ 

So far so good .... but now I'm wondering if I know enough to be dangerous ....

Going to do some research on how the Razor view engine conforms to HTML5 standards ....

Opening Pandora's box here or is there a good resource for me to understand this ??

I am a bit confused, so are you saying it is not practical to use this now? I checked some job ads for web development and they seem to ask for (X html). SO what should you be learning to get a startup or entry job? I plan to go through ASP next or should I go over the old ways xhtml or html also?

@BrianHartung: Nice find!  Thanks for the assist, my man.

@Steve: So I'm certain Razor spits out valid HTML5.  If ever in doubt, use an HTML5 validator against the output of an MVC v3+ page to give yourself peace of mind.  

@Bill: I'm guessing that in the near future, most companies will be looking for HTML5 skills almost exclusively (unless they must support an older application).  Even then, I would say this ... the differences between HTML5 forms and XHTML forms -- you can learn the differences in less than a day ... most IDEs like Visual Web Developer 2010 Express Edition or the upcoming Visual Studio Express 2012 for Web have built in validators for just about every version of HTML.  Try something ... if you see there are squiggly lines under something you've written in the code window, you can hover your mouse cursor over it and get some feedback on what you'll need to change to make it conform.  Hope that helps!

Hi Bob,

you're telling us that one of the benefits of using action="POST" instead of action="GET" is that the form values are encrypted inconjunction with https. I guess this is not true as form values should also be encrypted with a GET request.

https does not only encrypt the HTTP body, but the complete HTTP data stream as it sits inbetween TCP and HTTP. So this includes not only the HTTP body but also the HTTP header (very first line of the HTTP protocol) which contains the URL (with all the form parameters in case of a GET request) as well as all HTTP header fields.

At least this is my understanding of the matter.

Besides that: Thanks a lot for this great and delightful series. You're videos are fun to watch, very informative and well worth the time watching.

Cheers, Chris

This will help me a lot.

@candritzky:  Hi Chris, after further investigation, I realize that you are absolutely correct.  For others who want to learn more, this Q&A will point you to several valuable links:

http://stackoverflow.com/questions/2629222/are-querystring-parameters-secure-in-https-http-ssl

... Thank you!  Still so much to learn.  

I thought I knew the difference between get and post before, but now i'm totally confused. Bob, as far as what you were saying, I definitely heard something similar to that, but I know Candritzky is also correct. Now, I I have to go and research this again, because Candritzky just confused me with his explanation.  Maybe a follow up comment with the bottom line differences would do us some justice.

@s3curityConsult: I hope this helps... Think of HTTP REQUESTS and RESPONSES as envelopes.  The REQUEST has two envelope types, GET and POST.  My **assumption** for like, the past 18 years (!!!) is that a HTTP GET shows the entire address, including the querystring parameters, the same way you see them in your web browser's location bar.

http://www.whatever.com/?id=123&user=bob

Therefore, my assumption was that it was IMPOSSIBLE to encode these important querystring parameters (id, user, in this example) in SSL otherwise ... well, no one except the original web server would be able to read them!  The routers would be like, "this is encrypted, what the heck do you want me to do with this?!"

However, this understanding was incorrect.  There's not a lot of great documentation about this, so I'm not going to beat myself up about this too much.  Apparently, the querystring parameters are sent in an optional message body of the HTTP GET REQUEST, and are encoded in SSL (when the web server is using SSL & HTTPS, obviously ... otherwise, all bets are off ... anyone between your web client and the web server would be able to read the HTTP GET REQUEST body.)

EVEN THOUGH THE QUERYSTRING PARAMETERS ARE ENCODED IN SSL, the article:

http://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/

... explains that this should not be taken to mean that it is 100% secure and locked down, that the querystring data could potentially leak out in a few scenarios.

Bottom line:

(1) Everything on the web is insecure.

(2) Try your best to make your application less insecure.

(3) Use SSL when dealing with user data unless you have a good reason not to.

(4) You probably should declare a privacy policy somewhere on your website that explains what you do and why.

(5) Lawyer up.

Collect as little data as possible.

... that's my bearish, crotchety old man position on this.  :/

Hope the technical explanation helped a little.

On a somewhat related note to my previous post ... I didn't realize that ( 6 ) would create ... kind of creepy.

Hi Bob. I found these videos are very useful, but in #10, When you were talking about the default values for the text field and then mentioned about setting descriptions in the text field for instruction purpose, which need to be achieved by "a combination of javascript and JQuery". Actually with HTML5, you can use the a placeholder form attribute to get this done.

Hi Bob. First of all...greetings from Croatia! So... basically I would just like to point out (as LynnYang did on comment above) that you can put light gray description in text field using only HTML5 code.

Using lesson 10 example, I did this:

<textarea name="comments" cols="50" rows="5" maxlength="1000" placeholder="Write something..."></textarea>

I would also like to point out that you are doing awesome job, thanks a lot. 

"Srdačan pozdrav" something like best regards on Croatian...