I have 3 web pages each page contains 1 bootstrap form. The forms are structured the same, but each has a different number of input fields and order in which they appear in the form.
The HTML page files, local JS files are all in the same folder(no sub-folders). The <head> on each page has the same assests.
The non-functional form has a text area and button that the other forms do not. I have tried commenting these out, but that didn't resolve the problem. I have tried removing the link to local CSS, that too made no difference in the issue.
When I check the html files with W3 validator I get one Error and 2 Warnings.
Error: Element legend not allowed as child of element form in this context.
Warning: The date input type is not supported in all browsers. Please be sure to test, and consider using a polyfill. Commenting out the legend makes no difference.
I do have a date field in both the working and non-working forms.
When I look at dev tools in Chrome I don't see any errors.
I have tested on both Chrome and FireFox, so I don't think it is a browser specific issue.
Note this is all done on local machine and all coded using notepadd++.
I know this would be a tremendous amount of code to post for review, but if required I will do so. I was hoping someone would have troubleshooting suggestion.
have created 2 jsbin. first link is page with non working form. Second link is page with working form. first link is https://jsbin.com/xuwuziy/edit?html,css,js,output . Second link is https://jsbin.com/luqatel/edit?html,css,js,output
In the first JSBin: $('#cruise1').bootstrapValidator(.... There's no element with id "cruise1" in the page. Instead your form's ID is "quoteForm". Therefore the validator does not bind to it because it can't find an element with the "cruise1" ID.
Since you're including the same validation JS on both pages, in order to get the same code to validate both forms, you have to use a selector that can match to both forms.
There are two possible, simple solutions.
1) Give both forms an id of "cruise1". However, this may not be very descriptive of your quote form.
2) Give both forms the same class, and use that as the selector to initialise the validator. e.g.:
The form tags:
<form class="form-horizontal validatableForm" id="quoteform">
and
<form class="form-horizontal validatableForm" id="cruise1">
And the validator intialisation:
$('.validatableForm').bootstrapValidator( //...etc
This will initialise the same validation on all forms which match the given selector (i.e. all forms with that class). In any one page, in your situation, you might only have one form loaded with that class, but it means it will work when the code is included in both pages, and if for any reason you had two forms with that class loaded in one page it would bind those as well.
One last note, since you mentioned you were new to this: I hope you are implementing the same validation rules in your server side code (the code which deals with the submitted form data). Client-side validation such as you've used is very nice for user experience, but it's not secure - any user, especially a malicious one, or an automated spam-bot, can easily manipulate or bypass the JavaScript validation (most simply, by just turning off JavaScript) and try to send invalid or problematic data to the server. You cannot trust anything which comes from the client-side and must re-validate everything in order to protect your application and database.
Related
We currently use wysihtml5-rails to let our users edit emails before they are sent but this is not working out so well for a few reasons.
I need the comments to allow for Outlook specific comments like these . All comments are being removed, currently.
I also need the CSS classes to be untouched as the editor content will be a pre-generated email that includes CSS classes. Our editor will only keep classes that are whitelisted but this is annoying as we need to update that list with every change.
Same goes for inline styles. Some of the styles in the generated email are inline instead of in classes. Those need to be kept but they are being removed.
Is there any way I can get our editor to work this way?
I found a solution but it's hacky.
I realized that the raw HTML was being stored on the page in a hidden textarea tag. Interestingly, all the elements that I needed (CSS classes, comments) were still there. But when submitting the form, the value of this textarea was replaced with the parsed results from the editor which gets sent to the server. All the comments and classes are gone from this text.
The solution was then to create a second field that takes the unparsed value from the WYSIWYG editor and sends that along. Easy in rails but just making this new field part of a form. Then the controller can choose which value to take. In my case, I renamed the existing message field to parsed_message. Then added a new message field which will hold the unparsed message.
The WYSIWYG editor we are using allows this by having a method that can be called at any time: window.email_editor.getValue(). Here the email_editor is the editor instantiated by the javascript on the page.
I searched around on the site before posting so I hope this isn't a duplicate, but this has been a question that has been bothering me.
Why doesn't HTML allow nested forms (without JS)? I have seen that it doesn't allow nested forms, but never why they are not allowed. To me, it doesn't make sense why they aren't allowed, especially if each form routes to two different actions. Why is this?
HTML doesn't all nested forms because they would cause more problems than they solve.
Forms in HTML are built for single HTTP requests. If you submit a parent form, should you submit the child form as fields in the parent form to the parent action? Or should the child fields be submitted to the child action as well? How do you handle the responses to both of these requests? Which response do you render? What if the parent submit fails and the child succeeds? How do you handle this in the response markup?
Any of these answers are handled in script rather than markup.
If the fields are required in the parent form, that should be part of its form as a single encapsulated way to represent the data needed for a single request. Any nested form is its own request and should be encapsulated as such.
The reasoning behind this is because the <form> tag expects an event action to be specified and having one form within another form would only cause problems because each form is expecting a different event to occur which could cause unexpected results with submit buttons because their default event to fire is whatever event has been specified in your form action.
The being said, you can have multiple <form> tags on a page, just not nested.
EDIT
You can also read the W3C documentation on the form element here: https://www.w3.org/MarkUp/html3/forms.html
One of the first thing it says is: **
Note you are not allowed to nest FORM elements!
**
I can understand why it seems like this might work...
Think about HTML code in general; you open a <tag> and close the </tag>. Most of the tags can contain multiple other tags, right? The header tag holds tags for the <title>, <meta data>, etc., and the <body> tag wraps a whole bunch of stuff together before you see the </body> tag. Some tags have different rules; like the <img> tag which stands alone. The <form> tag falls into one of those tags with "different rules".
A <form> is actually part of a script. It is presented on the HTML page to your site visitors as a means of gathering information. Once the site visitor clicks on the submit button, the <form> sends the information to it's related script to be processed. All of the <form> tags, whether they are <input> values, <checkboxes>, or <password> fields, are bundled between the opening and closing </form> tags.
Every <form></form> sends information to a seperate script. So, a script that logs the user in would need one <form></form> and a script that allows the user to change his password would be another <form></form>. If you want the script to handle both options, then you would have to code your script to process all of those bits of information.
In summary, a <form></form>cannot be nested because they function as a User Interface to gather information that will be processed by a script stored on your websites' server.
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.
I am testing web application behavior with Cucumber (using Selenium and Watir under the hood). My web app has HTML5 pages and makes use of the new "required" attribute. If I have a data entry form with a required field, and I submit that form with the field blank, I would like to verify that the web app correctly responds with an error condition.
Unfortunately, when testing using an HTML5 web browser, the error message that pops up on a failed field validation does not appear to be accessible to Cucumber through the web driver. In any case, the form is not submitted and the page remains on the data entry form.
On the other hand, when testing headless or with a non-HTML5-compliant browser, the form may submit, allowing my web app to trap the error and send the user back to the form page with an error message.
In the second case, I can easily test for the existence of the error message since it's part of the HTML delivered in the page. My problem is that I can't see how to write a single test scenario that will validate the error condition for both headless and HTML5 browser situations.
It may be that this is impossible with the current state of Selenium and Watir web drivers. But if anyone has any idea how I can verify the HTML5 "required" error popup message, that would be a big help.
EDIT 2012-06-02:
Here is a sample page with a sampling of HTML5 browser warnings.
There is a required text and select, a text box showing internal hint text, and a text box with regex input validation. The page doesn't have any CSS or javascript to confuse the issue, it's just vanilla HTML5. See the w3schools page about HTML5 field attributes for a complete breakdown. The form submits to a simple CGI script that just echoes the form input, assuming the form succeeds. A submit failure will remain on the sample form page.
I haven't worked with the HTML5 required attribute before. But from the looks of it, that required attribute just alerts the browser that that form field must be filled out (i.e. the DOM doesn't change).
It seems to me that it would be reasonable to just assert that that required attribute is present in the HTML of the appropriate form fields. That test should pass for BOTH HTML5 browsers and non-HTML5 browsers.
Trying to assert anything more than that seems to me like you'd be testing the functionality of the browser.
Other than validating that the HTML created is correct to enable the browser validation, I'm not sure how much you can do that doesn't amount to testing the browser and not your code.
Using watir or watir-webdriver you could use .type to validate that the input has the proper type (e.g. email) set, which is one thing that controls the browser validation. The other is the presence of the required attribute which is a little tricker Potentially .attribute_value("required") might work, but normally that returns the value of an attribute, so not sure how that method would respond to a boolean attribute. Other alternatives might be to look at .attribute_list and
Seems also like a good reason here for Watir to add a .required? method to input elements that would allow you to easily check if that attribute has been set. So I asked for that feature https://github.com/watir/watir-webdriver/issues/189
You should have CSS selectors in place to target the particular field and look for an error identifier. If it is visible or not. A detailed step definition needs to be there.
One solution would be to not use Cucumber to test the error behaviour but instead test that you have configured the fields.
So in Cuke terms you might have something like
Given I am filling in my form
Then I should see that my name is required
and then write something that looks for the required option on the html tag for the name field.
Anymore than that is testing the browser not your 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 :)