How does HTML form function? - html

How does HTML form function? and what I mean by that question is not what a form does (It sends the information of all the input elements to the server), but I mean "How does the form know what to do"? Isn't HTML just a mark-up language, which means that it's not for programming? Is there some code hidden somewhere?
I hope it was clear ;)

HTML is processed by the browser, and the browser has programming which "makes the form work". All the form really does though (for most standard uses), is collect the user input and provide it as a POST request to the HTTP server.

Its just part of the web browser to serialize the contents of the input fields and send that up to the server.

Related

HTML Form: Can submitted GET/POST parameters be suppressed using only HTML or CSS?

I am volunteering on a website-based project that is trying to make all pages fully operable JavaScript free before adding any JavaScript for enhancements, and I was asked to investigate whether or not a particular scenario could be handled purely through HTML/CSS.
What we have is a form that is populated to help us filter a list of tickets that are displayed on the screen after a page update through a GET action, which itself works fine, but the concern with the current implementation is that the URL cannot be made into a permanent link. The request, however, to keep the permanent link as minimal as possible, is to only send GET parameters for fields that are populated with something (so, suppressing GET parameters for fields that are blank) instead of having a different GET parameter for each form field on the page.
I have thought of several ways that could be done, most including JavaScript (example: create fields with ids but no names and a hidden field w/ name that uses JS to grab the data from the fields), but also one that would be a POST action with a redirect back to the GET with a human readable string that could be permanently used. The lead dev, however would prefer not to go through the POST/redirect method if at all possible.
That being said, I'm trying to make sure I cover all my bases and ask experts their thoughts on this before I strongly push for the POST/redirect solution: Is there a way using only HTML & CSS to directly suppress GET parameters of a form for fields that are blank without using a POST/redirect?
No, suppressing fields from being submitted in an HTML form with method of "GET" is not possible without using JavaScript, or instead submitting the form with a POST method and using a server side function to minimize the form.
What fields are submitted are defined by the HTML specification and HTML and CSS alone cannot modify this behavior and still have the browser be compliant with the standards.
No, you cannot programmatically suppress any default browser behavior without using some kind of client scripting language, like JavaScript.
As a side note, you say "JavaScript for enhancements", but JavaScript is not used for enhancements these days. And no one in the real world would except a decent front-end without the use of JavaScript. I would suggest you simply use JavaScript.
I do not think you can avoid Javascript here to pre process before submission to eliminate unchanged /empty form fields.

Html encoding TextboxFor input

Please bare with my ignorance for now as I have just started learning web related programming. So, I have a web project written in MVC that has a login window with Username textbox bound to a property:
#Html.TextBoxFor(model => model.UserName, new {#placeholder = "Username"})
As I understand, Razor automatically html encodes input to help preventing cross-script attacks. However, when I test username with a javascript I get an exception from MVC:
A potentially dangerous Request.Form value was detected from the
client (UserName="...hp?name_1=code
Which makes me think that the input is NOT html encoded. My idea was to resolve this issue with html encoding/decoding but looks like I am not getting this whole idea right. Could someone explain?
NOTE: one of SO's related posts provides an unsecured solution but it is not an option for me to simply allow html.
It is not HTML encoded, that is correct. You will have to do the HTML encoding in the Action that form posts back to.
Also, you will need to add [ValidateInput(false)] attribute just about your action.

HTML Multiple Form Actions/Outcomes

Basically Im trying to build a page menu but in the form of a "Search users..." box. So basically when user enters the text "John Smith" the action="JohnSmith.html" but if they type "Mary Smith" the action would ="MarySmith.html".
From what I've been told so far there can only be one action per . Would what I wan't be possible using only HTML, If not how could I go about making this "Search User/Page Selector"?
Thanks!
Before you submit your form you can change the action depending upon the value of your text box in a java script function.
if(textboxValue=='John Smith'){
document.form.action="Action1";
}else if(textboxValue=='Mary Smith'){
document.form.action="Action1";
}
document.form.submit();
HTML marks up documents. It's a markup language. When browsers hit the markers, the HTML tags, they respond. By itself, HTML will not be readily usable to process data conditionally. Another program will be needed to process the HTML form. For these reasons, I suggest, No, HTML will not be a good choice for this task.
PHP, ASP, JSP or maybe even javascript would be good choices for processing form data. A stronger answer would require more structure to the question. Thanks.

Is Form Tag Necessary in AJAX Web Application?

I read some AJAX-Form tutorial like this. The tag form is used in HTML code. However, I believed that it is not necessary. Since we send HTTP request through XmlHttpRequest, the sent data can be anything, not necessary input in form.
So, is there any reason to have form tag in HTML for AJAX application?
Apart from progressive enhancement as already discussed (don't make your site require JavaScript until it really has to), a <form> with onsubmit would be necessary to reliably catch an Enter keypress submission.
(Sure, you can try trapping keypresses on separate form fields, but it's fiddly, fragile and will never 100% reproduce the browser's native behaviour over what constitutes a form submission.)
Sometimes, web apps using ajax to transform their data either use forms as a fallback when the user has no JavaScript enabled (a sometimes expensive but very good thing to do).
Otherwise, if an application builds and sends an AJAX request, there is no compelling reason to use a form except in rare special cases when you actually need a form element. Off the top of my head:
when using jQuery's form serialize function
when monitoring all fields in a form for changes
when there is need to make use of the reset form button (that to my knowledge is available in a proper <form> only).
I see at least two possible reasons :
Graceful degradation (see also Unobtrusive JavaScript) : if a user doesn't have Javascript enabled in his browser, your website should still work, with plain-old HTML.
Behavior of the browser : users know what forms look like and how they behave (auto-completion, error-correction, ...) ; it's best not going too far away from that
And I would add that, if you want the user to input some data, that's why <form> and <input> tags exist ;-)
Using the right tags also helps users -- as an example, think about blind users who are navigating with some specific software : those software will probably have a specific behavior for forms an input fields.
It really depends what you're doing. If you're wanting to take form content submitted by the user and use AJAX to send that somewhere then you're going to want to use the form tag so your user can enter their data somewhere.
There will be other times when you're not sending data from a form and in that case, you wont have a form to be concerned about :)

Why is a html form post to a restlet resource not working?

Restlet's (2.0M6 on Google App Engine) annotations are actually sensible to the order of a resource's methods.
When posting html form data, make sure that the #Post("html") method stays above the #Post("xml") method in the receiving resource.
At least Firefox puts both content types into the request's Accept header, so the first matching method will be processed.
The question is, if there is any other way to achieve control over method precedence?
For example I would like the client to accept text/html only.
As per your comment that you're asking whether there is some kind of client-side html form attribute or JavaScript to modify the accept header, the answer would be, AFAIK: no. Not for links clicked or forms submitted by the user. As you mentioned in your comment, you might be able to use JS to intercept link clicks and form posts, and use XHR instead, but that'd probably be tricky, if possible.
BTW, XmlHttpRequest doesn't really have anything to do with XML. It can handle any sort of content, for both requests and responses. It's very common to return a snippet of HTML to a XHR request and use DOM injection to dynamically update the page.