Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h2>IDs must be unique</h2> <p>...within page DOM element tree so each control is <strong>individually accessible</strong> by its <code>id</code> on the client side (within browser page) by</p> <ul> <li>Javascript scripts loaded in the page</li> <li>CSS styles defined on the page</li> </ul> <blockquote> <p>Having non-unique IDs on your page will still render your page, but it certainly won't be valid. Browsers are quite forgiving when parsing invalid HTML. but don't do that just because <em>it seems</em> that it works.</p> </blockquote> <h2>Names are quite often unique but can be shared</h2> <p>...within page DOM between several controls of the same type (think of radio buttons) so when data gets POSTed to server only a particular value gets sent. So when you have several radio buttons on your page, only the selected one's <code>value</code> gets posted back to server even though there are several related radio button controls with the same <code>name</code>.</p> <blockquote> <p><strong>Addendum to sending data to server</strong>: When data gets sent to server (usually by means of HTTP POST request) all data gets sent as <em>name-value pairs</em> where <strong>name</strong> is the <code>name</code> of the input HTML control and <strong>value</strong> is its <code>value</code> as entered/selected by the user. This is always true for non-Ajax requests. In Ajax requests name-value pairs <em>can</em> be independent of HTML input controls on the page, because developers can send whatever they want to the server. Quite often values are also read from input controls, but I'm just trying to say that this is not necessarily the case.</p> </blockquote> <h2>When names can be duplicated</h2> <p>It may sometimes be beneficial that names are shared between controls of any form input type. But when? You didn't state what your server platform may be, but if you used something like Asp.net MVC you get the benefit of automatic data validation (client and server) and also binding sent data to strong types. That means that those names have to match type property names.</p> <p>Now suppose you have this scenario:</p> <ul> <li>you have a view with a list of items of the same type</li> <li>user usually works with one item at a time, so they will only enter data with one item alone and send it to server</li> </ul> <p>So your view's model (since it displays a list) is of type <code>IEnumerable&lt;SomeType&gt;</code> but your server side only accepts one single item of type <code>SomeType</code>.</p> <h3>How about name sharing then?</h3> <p>Each item is wrapped within its own <code>FORM</code> element and input elements within it have the same names so when data gets to the server (from any element) it gets correctly bound to the string type expected by the controller action.</p> <p>This particular scenario can be seen on my <a href="http://ustvarjalnezgodbice.apphb.com/si/home/stories" rel="noreferrer">Creative stories</a> mini-site. You won't understand the language, but you can check out those multiple forms and shared names. Never mind that <code>ID</code>s are also duplicated (which is a rule violation) but that could be solved. It just doesn't matter in this case.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload