Asp.net MVC Multiline Form Control/ Textbox - asp.net

I want to make the input class= form control field bigger and multi-line. I managed to do something similar in my last project but have deleted it and forgotten how to do it. Pretty much a text box but when I use text area it won't allow "asp for"
<label asp-for="Incident_Detail" class="control-label"></label>
<input asp-for="Incident_Detail" class="form-control" />
<span asp-validation-for="Incident_Detail" class="text-danger"></span>

The problem is the self-closing. Just try:
<textarea asp-for="Incident_Detail" class="form-control"></textarea>
Note: You really should change this kind of property (size, width, height, etc...) from CSS. It allows you have responsive layouts, and make the whole solution/project a lot easier to maintain. Alternatively you could use rows for height and cols for width: <textarea asp-for="Incident_Detail" class="form-control" rows="4" cols="100" />
Note 2: The self-closing is currently (html 5) invalid html markup for some elements (including textarea). Since MVC Tag Helpers doesn't override what is in your cshtml file, the output end up messed up.

Related

USWDS - How to align form labels to the left of inputs?

I'm using the
U.S. Web Design System (USWDS)
in a project I'm working on, and I'm struggling with something that seems superficially like it should be quite simple: How can I align form labels so they appear to the left of their corresponding inputs, instead of above them?
Some other CSS libraries call this a horizontal form but I've also seen it referred to as "inline" fields.
According to this answer it's possible to achieve the result I want using modern CSS Grid layout, but so far I haven't figured out how to make that play nicely with the USWDS styling, which does not use CSS Grid.
Can anyone help me to either:
Create a horizontal form using some combination of USWDS components and utility classes, or if that's impractical...
Produce a horizontal form by overriding the USWDS styling with custom CSS, but without causing too much conflict or breaking with the standard?
Below is a simplified snippet of my HTML:
<link href="https://cdn.jsdelivr.net/npm/uswds#2.8.0/dist/css/uswds.min.css" rel="stylesheet" />
<form class="usa-form">
<div class="usa-form-group">
<label class="usa-label" for="somefield1">Sample label</label>
<input class="usa-input" type="number" name="somefield1" value=0 />
</div>
<div class="usa-form-group">
<label class="usa-label" for="somefield2">Another label</label>
<input class="usa-input" type="number" name="somefield2" value=0 />
</div>
</form>
You can use flex on the usa-form-group to get them positioned next to each other as shown in this Code Sandbox, with some other minor touchups to the element margins https://codesandbox.io/s/nostalgic-moon-q7i7f?file=/styles.css

<legend> tag is not read by Windows Narrator

Windows Narrator doesn't read legend tag inside fieldset. At the same time legend is read by NVDA and JAWS properly. Markup is the following:
<fieldset>
<legend>Description</legend>
<label>
<input id="option1"type="radio" value="1">
Option 1
</label>
<label>
<input id="option1" type="radio" value="2">
Option 2
</label>
</fieldset>
Is there a way to make Narrator read legend?
Screen reader support for <legend> has always been spotty, and it's very difficult if not impossible to target one piece of assistive technology (e.g. Narrator) while not affecting other applications (e.g. NVDA and JAWS).
However, you can attempt to more explicitly convey the context of the legend element by inserting visually hidden text inside the label elements. This will supplement additional information for non-sighted users that isn't visible. Techniques include positioning content off-screen or using CSS clip-path.
<fieldset>
<legend>Billing Address:</legend>
<div>
<label for="billing_name">
<span class="visuallyhidden">Billing </span>Name:
</label><br>
<input type="text" name="billing_name" id="billing_name">
</div>
<div>
<label for="billing_street">Street:</label><br>
<input type="text" name="billing_street" id="billing_street">
</div>
[…]
</fieldset>
Also note that different screen readers behave in sometimes incongruous ways. It's not impossible to get them to behave all the same, so we have to "split the difference" and attempt to make a reasonable accommodation for all, even if it's not perfect in every instance.
Depending on the configuration, some screen readers read out the legend either with every form element, once, or, rarely, not at all. To accommodate this consider the following:
Make the legend as short as possible for situations in which it is read together with the label each time.
Make the individual labels sufficiently self-explanatory for situations in which legends are not read aloud, without repeating the legend in every label.
https://www.w3.org/WAI/tutorials/forms/grouping/

Is it possible to change jquery mobile form elements , increase sizes by JS in %

I want to resize jquery mobile form elements that I am using Phonegap in mobile App. Now I want to resize and give more height to form elements based on some number or percentage which will depend upon screen size. I know jquery Mobile handle width by itself but I want to give height via JS so that all form elements' height increase by that specific ratio/percentage.
I know that JQuery Mobile CSS can be changed but I want to change height using JS on runtime not setting CSS once. So what is best way to do this?
I actually want to get screen size and give size to all elements according to some percentage. While if I see at jQuery Mobile CSS then there are a lot of thing that I need to set, and still not sure if it will be set. So is there some way to do that without modifying or rewrite whole CSS? Or I just need to write custom CSS and form elements ?
Any suggestion and effort will be appreciated.
Here is a fiddle demonstrating this with input elements: http://jsfiddle.net/ezanker/akgEa/
In this example I have 3 inputs of type text and a button which doubles their height each time you click it. The button iterates through each input, gets its current height and then sets the height to 2 times current.
<div data-role="fieldcontain">
<label for="textinput-fc1">Text Input:</label>
<input type="text" name="textinput-fc1" id="textinput-fc1" placeholder="Text input" value="" />
</div>
<div data-role="fieldcontain">
<label for="textinput-fc2">Text Input:</label>
<input type="text" name="textinput-fc2" id="textinput-fc2" placeholder="Text input" value="" />
</div>
<div data-role="fieldcontain">
<label for="textinput-fc3">Text Input:</label>
<input type="text" name="textinput-fc3" id="textinput-fc3" placeholder="Text input" value="" />
</div>
<input id="btnSet" type="button" value="Set Heights" data-theme="a" />
$('#btnSet').on("click", function(e){
$("[type='text']").each(function( index ) {
var curH = $(this).height();
$(this).height(curH * 2);
});
});
NOTE: depending what type of form elements you are using, setting height will not work for all of them. I suggest you look in the inspector at the generated code for your form and see what is the best way o set the height for each element type.

How to center input radio

I'm using jquery mobile for my project. It automatically converts all radio buttons in its inputs with its styles. The major problem is that in different situations i have different number of buttons (it depends on user) with its different width and i need it every time center.
<div data-role="fieldcontain" id="inline" >
<fieldset data-role="controlgroup" data-type="horizontal" data-mini="true">
{section name=i loop=$data['input'] start=0}
<input name="position" id="radio{$smarty.section.i.index}" value="{$data['input'][i]}" type="radio" />
<label for="radio{$smarty.section.i.index}">
{$data['input'][i]}
</label>
{/section}
</fieldset>
</div>
As you see each button has his size (for example Up and Zoom In are different). As i said before - i don't know what buttons will be for each users - it depends on their own settings, so i need somehow automatize process of centering it - is some ideas?
You could try it with <a> instead of <input> as done in the documentation, if at all possible in your situation.

Is it acceptable to use tables for forms? Or is it still more correct to use divs?

I'm wondering whether it's acceptable to use tables for forms.
Strictly speaking, name/value pairs are tabular data, aren't they? And a form is just a user customisable set of name/value pairs. So is it right to use tables in this case? Or should I use divs styled with CSS?
Try fieldsets
I prefer to break up the fields into logical <fieldset>s with one <legend> each, because:
The code is less cluttered
The default formatting is user-friendly (I especially like how the legend displays)
It's easy to style with CSS
Here's a code example. Note that the labels' for attribute lets you click that label to move focus to the input specified (it matches the id attribute).
<form>
<fieldset>
<legend>Wombat Statistics</legend>
<ol>
<li>
<label for="punchstrength">Punch Strength</label>
<input id="punchstrength" name="punchstrength" />
</li>
<li>
<label for="beverage">Favorite Beverage</label>
<input id="beverage" name="beverage" />
</li>
</ol>
</fieldset>
<fieldset>
<legend>Questions That Are Too Personal</legend>
<ol>
<li>
<label for="creditcard">What is your credit card number?</label>
<input id="creditcard" name="creditcard" />
</li>
<li>
<label for="gullibility">Did you actually fill that in?</label>
<input id="gullibility" name="gullibility" />
</li>
</ol>
</fieldset>
</form>
For a basic layout, you can use something like:
label, input, textarea, select {
display: inline-block; vertical-align: top; width: 30%;
}
See this article for a more in-depth tutorial.
Both are correct.
I preffer using some div/li, as that allows me to make some different layouts, but tables for forms are not frowned upon.
Actually, by default, Django gives you table formated forms.
A form isn't tabular data.
It's so easy to lay out form elements with CSS, I don't see any value worth obfuscating the markup with tables. Personally, I find that laying out forms with CSS is easier than using tables at this point. For example:
HTML:
<fieldset>
<label for="FirstName">First Name</label>
<input type="text" id="FirstName" />
<label for="LastName">Last Name</label>
<input type="text" id="LastName" />
<label for="Age">Age:</label>
<select id="Age">
<option>18-24</option>
<option>25-50</option>
<option>51-old</option>
</select>
</fieldset>
CSS:
fieldset {
overflow: hidden;
width: 400px;
}
label {
clear: both;
float: right;
padding-right: 10px;
width: 100px;
}
input, select {
float: left;
}
Using simple variations on that theme, you can make great-looking, accessible forms that are actually easier to work with than tables anyway. I've used that basic approach and ramped it up to some fairly complex, multi-column data entry forms too, no sweat.
You can use tables. Simple as that.
Yes
Yes, you may use tables. Div's are supposed to replace tables for page-level layout, but not for, well, tables. Go ahead and use them within pages whenever they solve your problem.
After being the biggest anti table person you can imagine I've started to realize in the end it doesn't matter. Use what's quickest. Of course if you are nesting tables then you have a problem but generally I can't think of a easier way to layout forms. At the end of the day does the client or the visitor give two hoots about whether you used a table or a list?
Some people will say yes, some no.
Here's a way for you to decide: If it truly contains tabular data, then it should, at least according to WCAG, have a summary attribute. The summary attribute should describe the purpose and structure of the table for the benefit of screen reader users. Can you write such an attribute? If so, then you should do so, and include it on your table. If you can't, then it probably isn't a really a table and you should look for another way of laying out your form.
Eric, I would agree with you that form data is tabular data and semantically can live inside a table.
This is the method I use for simple data entry screens.
I wouldn't generally use divs, but possibly an ordered list
<ol>...</ol>
as the form is an ordered list of items also.
I find this method a lot hard to style however.
You'll probably get 50/50 split in answers....
If you're looking for "css purity", you should use something like this:
<form action="http://localhost/Zoleris/" method="post" accept-charset="utf-8">
<ul class="form">
<li>
<label for="username">Username</label>
<input type="text" id="username" name="username">
</li>
<li>
<label for="password">Password</label>
<input type="password" id="password" name="password">
</li>
<li>
<input type="checkbox" id="remember_me" name="remember_me" >
<label class="checkbox" for="remember_me">Remember my username</label>
</li>
<li>
Forgot your password?
</li>
<li>
<button type="submit" id="btnLogin" name="btnLogin" class="button positive" style="float:right"><img src="tick.png">Login</button>
<button type="submit" id="btnRegister" name="btnRegister" style="float: left"><img src="cross.png">I need an account!</button>
</li>
</ul>
</form>
you can use whatever you want,
it just that it is a new standard for making the layout of the html forms, and it's kinda like a rule not use table tags for design, but it's still ok to use tables for displaying a table of data (grid)
It's important to use labels with the 'for' attribute for screen readers (for usability).
That is why I use fieldsets
I never understood why you would use an ordered or unordered list for forms when a definition list seems more semantically appropriate:
<fieldset>
<dl>
<dt><label for="definition">Definition:</label></dt>
<dd><input type="text" name="definition" /></dd>
</dl>
</fieldset>
They can be a wee bit trickier to wrangle format-wise, but it always made a lot more sense to me than lists or tables for the vast majority of forms.
Having said that, tables don't seem inappropriate to me for editable tabular data.
Forms can be or feel tabular, but tables imply a "presentation" along with the semantics. Marking up a form in a table tends to lock the design into a 2-across, field/input layout (assuming you don't want to spend time overriding the table's CSS). Furthmore, you may have to override the styles if you are trying to account for small screens such as mobile phones.
Furthermore, a screen reader will over-announce this form with, "Row 1, column 1, label, 'Name', column 2, input, 'Name'..." instead of simply, "Input, 'Name'..."
My recommendation is to use DIVs, FIELDSETs, or ULs/LIs. This leaves the presentation in the hands of CSS, exactly where it belongs.

Resources