I inherited an application where display:none was used to control conditional display of input elements based the values of other input elements.
The way this was handled is by running some pretty ugly code to evaluate field values and reset the display property in the during page load. Every time.
Isn't there a better way?
Using display: none in conjunction with JavaScript and CSS is the easiest way of simply showing or hiding DOM elements on the fly. That said, you could manipulate the DOM itself by adding or removing elements rather than simply showing / hiding them (with jQuery, for example).
Maybe your should just redesign the form that uses all the display: none fields or rewrite/refactor the script that does this checking? If the form is too large split it into several pieces - this will help the user too. I personally don't like if the form changes often whenever I am trying to fill in everything.
If you are not showing and hiding elements dynamically as the user interacts with the form, then there's no need to use CSS/Javascript. Just use your server-side language (PHP/JSP/whatever) to not output the hidden fields. You'll use less bandwidth, and the form will work even with Javascript disabled.
Is the idea to reshape the form on every POST or reorder fields before submitting. If the first then the fields shown should be removed on the server-side before page get to the user. If you are talking about changing on the client side before a post (e.g. removing fields which are not relevant based on the input in some fields as the user types), you can use javascript to remove fields from the DOM.
The two things your solution needs are:
The forms must be functional without javascript (even if they feel less slick)
Don't submit fields the user cannot see unless they are input tags with type="hidden". You will only confuse yourself on the backend if you don't know whether a user left a field blank or could not see it because it dynamically had its styling changed by a client-side script.
there is an partial alternate to display:none i.e
use this style in css
opacity:0;
but problem with this is it doesn't appears on canvas but it is still there.
using display:none; completely delete element and creates when u apply attribute display:block;
Related
I have a question about correct nesting and syntax with using form element in HTML. I understand basics but is it okay to put there divs, paragraphs, spans, etc.? Because using nice CSS need sometimes more elements and because I am front-end learner I am not sure if these elements inside form influence some data and inputs. If you have some examples of using very advanced HTML in forms I would really appreciated some already used HTML real examples. Also if you can explain how it works with data collecting from forms, it could also help me understand this nesting.
Btw: is it important to have button inside the form or it can be outside this element?
Thans for any answer.
First place to go when you want to know anything about HTML/CSS and JavaScript in the browser is MDN. In your case: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Form
As you can see there, forms can indeed include any types of elements (a <form> behaves like a <div> for all visual design purposes), except for nested <form> elements
Data collection for a form is typically (as in plain HTML/HTTP) made by sending a request to the URL given in its action property. How this request is exactly formed can be controlled through the use of attributes method and enctype.
Basically, the request body (for POST) or query string (for GET), will contain all data inside the form as key/value pairs, where the keys are the name attribute of the input fields, while the value is their value attribute.
This can vary a little depending on field type. For instance a <textarea> will send its text contents as a value instead.
The sending of this request (and browser navigation) is triggered when the user clicks a submit button on the form (either <input type="submit"> or <button>). This is called submitting the form.
is it okay to put there divs, paragraphs spans etc.
Yes, that's perfectly fine.
is it important to have button inside the form or it can be outside this element?
You can have a button outside of a form - depends on what functionality you are trying to achieve.
If you have some expamle of using very advanced html in forms
Your question is quite basic so I don't know how much of an advanced example you are looking for, but you can find examples of css classes being used with forms on this Bootstrap 5 tutorial (Bootstrap is a CSS library/framework): https://getbootstrap.com/docs/5.0/forms/layout/
My question stems from the context of a web application, rather than a web page. In that context it often does not make any sense to submitt data. You want to modify state in your application using controls.
To me, it then does not make any sense to use a form. However I still need controls/widgets to modify. Meaning I need tags such as input, which I understand is a "form control", indicating that they should always be contained inside a form. Furthermore I want to organize my controls in fieldset tags.
So I was left wondering if I now have to wrap all of my controls in form-tags, even though this to me seems symantically incorrect (since I'm not going to submit).
After a few quick searches I found the two following two breif forum discussions on topic:
http://www.webmasterworld.com/forum21/8837.htm
http://doctype.com/can-fieldset-outside-form
To sum them up, using form controls outside of a form will validate on w3c. However rendering might not work in really old browsers (like Netscape 4, which I really don't care about.)
In the first link there seems to be support for using form controls outside of forms as the symantically correct thing to do in my sort of scenario. However in the other it seems that using fieldsets should strictly be done within a form when caring about being symantically correct.
Does this mean I should feel free to use controls outside of forms, but I must wrap them in divs rather than fieldsets, or should I read this some other way?
The w3c states:
17.2.1 Control types
The elements used to create controls generally appear inside a FORM element, but may also appear outside of a FORM element declaration when they are used to build user interfaces. This is discussed in the section on intrinsic events. Note that controls outside a form cannot be successful controls.
17.10 Adding structure to forms: the FIELDSET and LEGEND elements
The FIELDSET element allows authors to group thematically related controls and labels.
17.10 doesn't make any mention of the form element, to me this means that there is no limitation on where it can be used except that it should surround controls and labels. 17.10.2 Seems to allow me to use those outside of a form. Hence I can also use the fieldset outside of a form, as long as it wraps controls and labels.
I have come across use cases where I have required to have form controls without the need for actually submitting the form.
Sometimes, enclosing within the tag only makes the things worse, because I might be interested in calling a JS function whereas the form simply submits and reloads the page. I have encountered this using PhoneGap application on a WindowsPhone.
As for me, I wouldn't be too bothered about W3C validation, given it makes life much more simpler.
On many websites, when typing in a username for example, a dropdown occurs where previous input shows up so the user can easily select something instead of typing. I know you can turn this off in browsers by having the form or input have an attribute of autocomplete="off". The problem is when I want it on, and the input has padding. The dropdown looks horribly off because it has no padding for each item.
Is there any way to style this with only css? I'm aware that you could potentially use a javascript/jQuery workaround to store previous entries in a cookie or something and make your own dropdown. But I don't want to rely on javascript for this.
Nope. Autocomplete is not a part of any standard, and is not part of the DOM. The only way to style is, as you've suggested yourself, by recreating that functionality using JavaScript.
Unfortunately there is no way to style the drop down box itself with CSS, because in this case (when not using javascript/jQuery/mootools/etc.) it is operating system dependent - i.e Windows/Linux/Mas OS visualize it according the visual user settings (i.e scheme).
I have a little problem with an upload-form within an other form (call it data-form).
I know it is not possible to put a form into an other.
So I would need to put it after my data-form.
But I need the upload-form controls in the middle of my data-form because of optical and structural reasons.
The file-upload should also perform other actions and not the same than the data-form.
So any idea how can I make the upload-form after my data-form but visible in it or any other ideas to handle this?
I am using javascirpt and php also.
thanks and best wishes for 2011!
br,chris
I know it is not possible to put a form into an other.
Nesting HTML forms is not valid HTML and results into undefined behavior which could vary between browsers. Here's a similar post.
You could leave some space in your design and then nest the form (visually) in the other one with CSS and absolute positioning..
Apart from position: absolute that might work depending on your layout, I had the idea of using a Flash based uploader like SWFUpload. That process works separately from the surrounding form. However, it creates a dependency on Flash and does not degrade gracefully (i.e. if Flash is not present, it does not work at all).
In many prototype scripting cases, it's easier to just stick every form item (such as an input or textarea) in its own form tag. Is there anything wrong that could happen from having lots (like 1000) form tags in a page?
What do you mean by ‘prototype scripting cases’? How are the forms being submitted?
If each form is its own action, eg. you have lots of separate product listings with different REST action URLs, then, yes, a separate form per line is appropriate.
If you're just using controls on their own for scripting, and have no intention of submitting them through the normal HTML form process, you don't need any <form> elements at all, just include them bare.
(Except in the specific case of radio buttons, which require a <form> for grouping.)
Should not be a problem but why do that when you can just use one form. It will work even with 1000 forms but it would be stupid with over 50 anyway.
There is nothing particularly wrong with it, but It would be a better idea to have them all in the same or fewer.
I would say, first off, have 1000 inputs on a single screen poses a different problem that should be addressed first. That many controls will be completely unusable.
That being said, having each element in its own form will cause more overhead in processing your page. You'll have to decide whether the impact of this is too large in your scenario.
You will lose the info from other input elements when submitting any of these 1-input forms, since a form submission ONLY submits the values for input elements of that one form.
If you're OK with that in your prototype, not a big problem
The only thing wrong with this is the semantic process of what a form is. A form should only submit what the fields inside of it have. So, anything related to that "form" should have the proper fields with in it.
Technically, when using a form it'll take you to a new page, so, any of your values in any other form on that page will be lost. The only way around this is using javascript to ajaxily submit the data.
There is no issue with using the HTML markup in the way you are wondering. The only thing you will want to worry about is the more control structues you add to your HTML the more text the web server needs to serve up. This will lengthen the amount of time it takes to get your code from the server to the users browser.