I'm still a beginner and am still learning how to read and understand HTML. Within a login form in a website:
<form action="https://examplesite.jp/user.php" name="loginform" method="post">
<ul class="form">
<li class="title">E-MAIL ADDRESS</li>
<li class="text"><input type="text" name="uname"
id="legacy_xoopsform_block_uname" size="18" maxlength="60" value=""/>
</li>
<li class="title">PASSWORD</li>
<li class="pass">
<input type="password" name="pass" id="legacy_xoopsform_block_pass"
size="18" maxlength="12"/>
Part I do not understand is this part from above:
<input type="password" name="pass" id="legacy_xoopsform_block_pass"
size="18" maxlength="12"/>
I understand up to <input type="password" name="pass" /> part, but not after that especially how it's using id="legacy_xoopsform_block_pass".
How I am comprehending this code is that the type of input that will be sent to https:/examplesite.jp/user.php (using online form) is "password", and that is named "pass" but what's "id"? Especially email's acted as ID?
I read Difference between id and name attributes in HTML but don't really understand...
The ID attribute isn't used for any server side function, it is merely for styling (ill-advised) or more commonly used for hooking JavaScript functionality too.
So for example, you could use it to style the element in your CSS:
#legacy_xoopsform_block_uname {
background-color: black;
}
Or you could use it to do stuff in JavaScript:
$('#legacy_xoopsform_block_uname').on('click', function(){
alert('the input field has just been clicked);
});
Those are the only two situations you would use the ID, however I don't suggest the first option, I would use a class for that.
Essentially if you're not doing one of the above two things, you don't need and can safely get rid of it.
Welcome to SO. Please use google search, its your best friend!
In the CSS, a class selector is a name preceded by a full stop (“.”) and an ID selector is a name preceded by a hash character (“#”). The difference between an ID and a class is that an ID can be used to identify one element, whereas a class can be used to identify more than one.
Source
The name attribute value is a name of a query parameter. This is a name of data field, that will sent to server with your form. id is an unique identidicator of HTML element. There is no several elements with same id in valid HTML. Thus, id attribute is used for HTML element identification, but the name attribute is used for data field identification in HTTP request.
Related
I am attempting to fill in the persons name field on a page using puppeteer but cannot find the ID
<input placeholder="Enter Persons Name" type="text" data-marker="root/appPage/create/form/nameInput" class="sc-bdnxRM sc-dlMDgC sc-csTbgd jaediC hjOJya" value="Hello world">
How do I change "Hello World" without knowing the input's ID?
Thanks
You can test if another attribute of input is consistent in this site and try to use it (like a group of classes, the "data-marker" attribute, and others)
Otherwise, if you don't trust in these attributes, you can see around that input's parent elements, and use a selector like "#fatherElementId > input", for example.
Please help me to explain about the div element of HTML be able to have attribute name or not?
for example :
I put attribute name inside it, Than I got warning.
Is it uneccessary to add attribute name?
Thank in advance
The name attribute is used with input elements to set the key of the submitted value. If you need to 'name' a div in order to address it from javascript or otherwise uniquely identify it on a page, you can use the id attribute. That said, most modern browsers will handle a name attribute on a div with no issues but it does not conform to HTML standards.
name is an attribute that is used for INPUT type elements. In a DOM a name is unique and you can use to access the element from JS or the backend scripting language.
For example. Lets say you have this form:
<form action ='process.php' method='POST'>
Username: <input type="text" name="un" /> <br/>
Password: <input type="password" name="pwd"/> <br/>
<input type="submit" name="submit" />
</form>
Now, lets say I put as username: Abe and as password: test
In the process.php file I can do:
echo $_POST['un'];
echo $_POST['pwd'];
And I will echo out the values for both fields.
And this brings an important point.
IDs and Names are not the SAME in HTML, IDs are used to quickly identify and add style to elements in the DOM whereas names are used by the backend script to process the form (PHP, .Net, etc).
<!-- 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.
I have a valid reason for wanting to do this, but it's a long story so I'll forgot trying to explain why and just ask if it's OK to do.
I have a page where I need to have multiple forms with the same name, but I only want the form whose submit button is click to be submitted. For example, the following might be on my page:
<form name="input" action="" method="get">
Username: <input type="text" name="user" />
<input type="submit" value="Submit" />
</form>
text
<form name="input" action="" method="get">
Username: <input type="text" name="user" />
<input type="submit" value="Submit" />
</form>
text
<form name="input" action="" method="get">
Username: <input type="text" name="user" />
<input type="submit" value="Submit" />
</form>
Is this acceptable?
Regarding the HTML 4.01 specication, you can use form elements with the same name attribute, as there is no uniqueness requirement on them. Doing so defeats the purpose of such attributes, though. They are meant for making it easier to refer to forms in client-side scripting: if you have <form name=foo>, then document.foo refers to that form.
It is undefined what happens when same name attribute is used, but what browsers seem to do is to return an array. In your example, document.foo would be a 3-element array, with document.foo[0] being the first form. But this is not useful, since (assuming there are no other forms in the document) you could use document.forms[0], with a well-defined meaning.
The name attribute itself is outdated for form elements (but not for form fields, where it keeps being essential). The HTML 4.01 spec clause on form says:
“name = cdata [CI]
This attribute names the element so that it may be referred to from style sheets or scripts. Note. This attribute has been included for backwards compatibility. Applications should use the id attribute to identify elements.”
In the HTML5 drafts, even the formal rules disallow the use of the same name attribute. The HTML5 clause on the name attribute on form says that its value “must be unique amongst the form elements in the forms collection that it is in, if any”. This is a confusing formulation, but it is safest to assume that it must be unique within the form elements of a document.
Yes it is allowed, only id's must be unique. I wouldn't recommend it however, why even put yourself in a position to be confused down the road.
The name attribute only defines what each form field element will be represented as when sent to the server.
It is also ok in HTML5. Only the name must be unique inside the form itself.
See the docs: "The value must not be the empty string, and the value must be unique amongst the form elements in the forms collection that it is in, if any."
When the user clicks a submit button, only that form will be taken in action. Still, it should be better to name them so that you are not confused :)
<p>
<input type="text" id="search" name="keywords" />
<input type="submit" value="Search" name="Submit" />
</p>
For the above code I was getting validation errors, but once I removed the id="search" the validation was good and error-free. I thought you needed an id, but I'm wondering if it is supposed to be there?
Do you have any other elements with that id in the document? That would be the only reason for validation to fail. IDs are meant to be unique in the document, if you have it elsewhere it would be invalid.
IDs are good when you plan on doing some sort of client-side work on the element, as an element that has an ID can easily and quickly be retrieved by Javascript. It is also good when you are using <label> elements, as you can then use the for attribute (which takes an ID) to point to the field.
Other than that, it doesn't really matter.
You do not need the ID attribute. The name attribute is the one that gets passed.
Daniel is correct. A label's for attribute is associated with an input's name attribute. In this way, if you select a label with for="first_name", it will select the input with name="first_name".