how is puting tow class different in one input?
classes is: auto and date.
did is this true?
<input type="text" name="date_go" class="auto" class="date">
Don't do that. A HTML element should contain unique attributes only.
In my experience, browsers tend to just use the first or last one defined in the markup (what does your browser do?)...
Google Chrome has decided to use the first attribute defined in the markup when building the DOM.
Instead, do this...
<input type="text" name="date_go" class="auto date">
...or in other words, if you want multiple classes, join them together with a space in the class attribute.
jsFiddle.
Related
I saw the code below, in one of my studying codes:
<form>
<label for="firstName">First Name:(click here cause cursor go inside the input box)</label>
<input id="firstName" type="text">
</form>
I find that the pair of for and id attributes connect the label and input element in the way that the cursor goes inside the input box automatically by clicking on label.
Which other pair of HTML elements can be connected to each other by the for and id attributes set? If it works for many other HTML elements, is there any list or source of the default action occurred by connecting one of them in each pair element?
According to w3school, we can use for with <label> and <output> element. Here is the link.
Adding a for is important, even if they are adjacent. I seem to recall hearing that some screen readers for the visually impaired have problems otherwise. So if you want to be friendly to those who are perhaps using alternate browsers/screen readers, use this method.
<!-- Some place on the webpage -->
<input type="text" id="firstName">
<!-- Some other place on the same webpage, or maybe content ajaxed in later -->
<input type="text" id="firstName">
Let's say I have a server-side script that generates an HTML page with some input fields each with its own ID. One server-side class may be responsible for adding input fields to one part of the webpage while another class handles another part of the webpage. Or you might have different programmers working on different parts of the page. I want to avoid collision with the HTML input field IDs. An example of this could be a parent form that has a jQuery dialog popup with input field IDs the same as the parent. Currently, I am prefixing the IDs with the name of the server-side class that generates them (and an underscore to make it clear which part is the prefix). To get a fully unique ID this way, I might have to start including the full namespace of the server-side class, and this might make my IDs very long.
Is there a better approach than prefixing the inputs or what is the best practice for this? I normally use camelCase for all my variables, with only this exception. Is this a good exception for breaking that rule?
What are most of you doing? Are you altering the way you select these input fields instead of by ID? Wrapping the input fields in form tags or div tags and adding functionality to the server-side to create these? (I'd like to have the freedom of not restricting what I wrap these inputs in to select them. My server-side code should just generate client-side code that grabs the values only knowing those inputs are going onto the page, and not knowing about any other tags on the page. Much easier to manage.) Are you adding css classes to each group of fields?
This answer is a little more directed towards users coming in from search engines. In my opinion, if you are using the id attribute in a dynamically generated form, they should probably be some kind of generated id/hash, unless it truly is a unique field. That aside, this is probably the best way to namespace HTML forms, especially when it is subject to collision:
<input name="pet_store[name]" value="" />
<input name="dogs[0][name]" value="" />
<input name="dogs[1][name]" value="" />
<input name="dogs[2][name]" value="" />
<input name="cats[0][name]" value="" />
<input name="cats[1][name]" value="" />
<input name="cats[2][name]" value="" />
If submitted all at once, the inputs will automatically be organized into arrays (at least in PHP, for nodejs you might have success with https://www.npmjs.com/package/qs).
In jQuery, you can select all dog name fields like this:
$('input[name$="[name]"][name^=dogs]')
I would use classes in this case. If you can't control what the uniqueness of ID's then they become pretty meaningless.
Instead of generating a super-long class name from the code that generates the html, you could add many shorter css classes to inputs that need them. It's not unusual to have lots of different classes in your document and they can all be used together with jQuery selectors. Also remember that if your inputs are in different forms then the form id (or class) could also be considered to work a bit like a 'namespace' too.
For reference, point 7.5.2 of the W3C Global Structure of an HTML document states that the id must be unique.
The idea of ids is that they are a unique reference to an element and as such it is not legal (valid HTML) to have multiple elements referring to the same id. If you want to avoid collisions and still identify the element you could use a combination of classes.
For example if you have 2 forms asking for a name (as in your previous comment) you could use:
<input type="text" class="ajax firstName" />
For the form generated by ajax, and
<input type="text" class="initial-form firstName" />
For the initial form on the webpage.
Equally you could use the data- attribute to hold a namespace. E.g:
<input type="text" data-namespace="ajax" class="firstName" />
(This can be accessed through Javascript with element.dataset["namespace"])
Use data-xxx attributes if you must, but I can't really think of a practical case of independent server-side scripts generating hundreds of DOM elements with unique IDs up to the point where name collision would become an issue.
Ok I have a Html element like this
<input type="button" id="harhar"/><label for="harhar">Im only for Id</label>
Is it possible that i can refer a label to a element not using id but a class? like this one
<input type="button" class="harhar"/><label for="harhar">Refer me as a class</label>
is this possible?
NOTE: this is for the sake of creating dynamic Jquery UI buttons in the server-side, that is why I want this to refer a class
No, it is not possible to match a class and a for together. However, there are things that you can do to ensure that your id's and for's are uniquely different from other for and id attributes.
When you generate your elements on the server-side, use a for loop or some other looping construct to enumerate your id/for attributes.
<input type="button" id="harhar_1"/><label for="harhar_1">Im only for Id</label>
<input type="button" id="harhar_2"/><label for="harhar_2">Im only for Id</label>
<input type="button" id="harhar_3"/><label for="harhar_3">Im only for Id</label>
If you can generate your HTML as such, then you'll be able to match up your labels and values while still using unique ids.
Additionally, there is nothing preventing you from still applying a common classname to all of your elements so that you can still easily refer to them with CSS or selectors:
<input class="harhar" type="button" id="harhar_1"/><label for="harhar_1">Im only for Id</label>
<input class="harhar" type="button" id="harhar_2"/><label for="harhar_2">Im only for Id</label>
<input class="harhar" type="button" id="harhar_3"/><label for="harhar_3">Im only for Id</label>
This provides you with the hooks that you need to write succinct CSS rules or manipulate the DOM quickly and easily.
No, a label always refers to an ID, because only ID is required to be unique in the document, which is exactly what a label needs.
You will have to fall back to creating buttons with predictable, if dynamic, IDs.
according to the html specification you must use the element id in the for attribute.
However, the specification also states that
When [for attribute is] absent, the label being defined is associated with the element's contents.
So, you might be able to associate the label the the input by re-arranging your html code.
As per the specs label for must match an ID.
A workaround is making the label wrap the element it targets. It doesn't work best with screen readers etc though (you can use the same text as title attribute of the input element).
<label><input type="button" title="I am the same label" />
I know change how this's styled...</label>
We all know that it is wrong to use a Table as a layout aid.
I often use tables to structure forms.
Is this semantically correct?
I am wondering about this as it is logical for a form to be in a table layout (at least the forms that I create), as all the fields have labels that correspond to the expected input into the fields.
The data obtained is then definitely semantically correct displayed in a table.
But is it the same for the form?
I have a feeling that it is a matter of opinion, but I am interested to hear people's reasoning behind their opinions.
============
EDIT : Thanks #Will Martin.
Actually, I checked, it would seem that using table to structure form IS semantically correct as it is displayed on w3c standards document. See here : http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1
============
I've read an article (unfortunately in french) yesterday that was basically saying that you shouldn't use table to structure forms. (http://www.alsacreations.com/article/lire/1209-display-inline-block.html)
It doesn't say why not but it says that you should use the display:inline-block. Be carefull though, display:inline-block is a great parameter but it has drawbacks when browsing IE7-6 (not surprisingly).
Read this article (in english) that explains 'inline-block' => http://robertnyman.com/2010/02/24/css-display-inline-block-why-it-rocks-and-why-it-sucks/
The web standards project has made a full tutorial on the why and how to avoid tables in html forms. It's a very easy read and answers all your questions:
http://www.webstandards.org/learn/tutorials/accessible-forms/
It's not just a matter of opinions - there are both semantic and practical problems with using tables with forms.
Generally speaking, simple forms that consists mostly of label - input pairs, such as login forms seen on websites today should not need any additional markup, since label and interactive form elements would be all you need in terms of semantics. Any additional markup would be added baggage, adding unnecessary weight to your page - CSS should be flexible to do almost anything you want, and fieldsets can be used for additional separation of the different sections of the form.
But even when you have a form that's obviously a table, you should still consider other methods first - there are accessibility issues with with mixing tables and forms, as indicated in this article on 24 Ways. The same article also shows how you might instead adapt fieldsets to do the same job, and definitely makes for an interesting read.
This sounds more in the vein of "debate" than Q & A. However, I've always felt that any form layout that demands a table structure (with the sole exception of data grids/spreadsheets, which are by definition tables) is a poorly thought-out user experience. Collections of checkboxes, labeled inputs, etc. can all be arranged more flexibly (and semantically) without using tables.
It depends on the form, I think. Some forms may make sense as a table -- for example, one where you have a series of key-value pairs:
<table>
<tr>
<th scope="row"><label for="first-name">First Name:</label></th>
<td><input type="text" name="first_name" id="first-name" /></td>
</tr>
<tr>
<th scope="row"><label for="last-name">Last Name:</label></th>
<td><input type="text" name="last_name" id="last-name" /></td>
</tr>
<tr>
<th scope="row"><label for="color">Favorite Color:</label></th>
<td><input type="text" name="color" id="color" /></td>
</tr>
</table>
The combination of LABEL elements using FOR attributes that correspond to the ID of the associated INPUT means that screen readers will be able to read the form sensibly. I've added TH elements to indicate the semantic relationship within the table between the LABEL cells and the INPUT cells.
However, doing it that way would not be my first choice. The presence of the table markup will make it more laborious to listen to using a screen reader, due to the announcement of each table row/cell. Some of the semantic information from the table (the association of TH header with TDs in the row) actually duplicates the semantic link between the LABEL and the INPUT, so that with a screen reader you may wind up listening twice to the same information about how these things are related.
Instead, I would do something like this:
<style type="text/css">
label { display: block; text-align: right; }
label input { width: 100px; }
</style>
<label for="first-name">First Name: <input type="text" name="first_name" id="first-name" /></label>
<label for="last-name">Last Name: <input type="text" name="last_name" id="last-name" /></label>
<label for="color">Favorite Color: <input type="text" name="color" id="color" /></label>
That would give you much the same effect with less HTML. It has the labels associated with their inputs both explicitly (using FOR/ID) and implicitly (because the INPUTs are child elements of the LABELs). It does mean that you have to be able to anticipate how wide your inputs have to be, and there's a ragged left edge due to all the text being right-aligned.
There's also the problem of adding in checkboxes and radio buttons. In their case, it makes sense to have the input first and the label after it; but that doesn't look very good with the example I've given.
So, basically? Formatting forms is a pain in the butt. Although they often consist of name-value pairs that would make logical sense as a table, there are potential accessibility issues with that approach. I would strongly prefer to avoid tables-based solutions for a problem like this, unless you have a compelling reason for using tables.
Where to put around other html element or not?
Option1- put around input element :
<label>Url:
<input type="text" size="350"/>
</label>
Option2:
<label>Url:</label>
<input type="text" size="350"/>
Thanks
The latter. This way you can set style, width etc. without affecting <input>. It's also better semantically: The label is a label, and input is an input.
Firstly, in the first example the <label> is automatically linked to the <input>, while in the second example they are not (you must set the for and id attributes to emulate the former's behaviour).
Other than that, it's a matter of situation and preference. Personally I usually go for the former as there's less markup needed.
The second is definitely better, it allows you to style separately.
You can also use the "for" attribute to bind it to an input field:
http://www.w3schools.com/tags/att_label_for.asp