form reference to non-existent ID error

Posted: Mon Jan 09, 2012 10:45 am

This error is usually generated when validating xHTML markup for a forum input element. It usually states something like;

Quote:

reference to non-existent ID YourInputName
label for="YourFieldName">YourInputName</label> input type="text" name="InputName"
This error can be triggered by:
A non-existent input, select or textarea element
A missing id attribute
A typographical error in the id attribute
Try to check the spelling and case of the id you are referring to.

Typically, assuming you have not made a typo, this error is caused by a mismatch between the label name and the input element id.
You have two choices;
add an id attribute to your input element to match your label

Quote:

input id="XX" ............

or a quicker way is to simply change label for to label id

Quote:

label id="XX">..........

Site Admin Joined: Jan 06, 2006 Posts: 308

Is this post complete? I'm not following...

Posted: Mon Jan 09, 2012 11:05 am

Sorry I was actually editing the post after a ton of stuff got filtered out while you were replying.

Note to self: TO DO;
Bin this stuuuuuupid BBCode garbage and see about integrating nukeWYSIWYG and using the allowedHTML array instead.

Newbie Joined: May 12, 2009 Posts: 74 Location: TX

I spent some time looking at this type of issue while hoping to improve form accessibility within RN.. but there are some problems with many forms as they often do not use unique name attributes for form elements. For example:

Code:

<span style="font-weight: bold;">Content:</span><br />


<input type="text" name="content" size="50" />

Which would be easiest to convert to:

Code:

<label for="content">Content:</label>


<input type="text" name="content" id="content" size="50" />

But what if an element #content already exists? This could potentially break the given form. In general we need to be prefixing name attributes with a unique prefix, and including a matching ID.

Code:

<label for="prefix-content">Content:</label>


<input type="text" name="prefix-content" id="prefix-content" size="50" />

This gets a little confusing with radio and checkboxes as it's actually valid to have mis-matched name and id attributes

Code:

Age:<br />


<input class="input" type="radio" title="Choose from one of the options" name="radAge" id="radAge4_0" value="Under30"><label for="radAge4_0">&nbsp;Under 30</label><br />


<input class="input" type="radio" title="Choose from one of the options" name="radAge" id="radAge4_1" value="Over30"><label for="radAge4_1">&nbsp;Over 30</label><br />

This page sums up where we need to go pretty well:
http://www.webstandards.org/learn/tutorials/accessible-forms/intermediate/

Posted: Tue Jan 10, 2012 10:47 pm

Your second example is perfectly correct.
With regard to the third example, I'm not sure I understand the problem pertaining to already having #content already existing. I know it's late in the day for me (close to midnight here) but wouldn't it be just simply be a poorly thought/coded form if you used the same name attribute twice within the same form (unless it's a selector like radio buttons/checkboxes)?
I'm just struggling at this late hour to think of any use case scenario where you would need to actually do

Code:




<label for="content">Content:</label>


<input type="text" name="content" id="content" size="50" />


<label for="content">Content:</label>


<input type="text" name="prefix-content" id="content" size="50" />

I don't use radio buttons much (or checkboxes for that matter) so I'm definitely not up to speed on those but I *think* radio buttons are fine provided the have matching pairs (label and input id);

Code:




<label for="male">Male</label>


  <input type="radio" name="sex" id="male" />


  <br />


  <label for="female">Female</label>


  <input type="radio" name="sex" id="female" />

Since checkboxes use the same type of 'select' I would assume that would work the same for them too.
I'll definitely append to this post if I find anything different.

Great post though, keep 'em coming, it's always great to see anyone who cares about this stuff.

Newbie Joined: May 12, 2009 Posts: 74 Location: TX

In the 2.4 release RavenIce used

Code:

<div id="content">...</div>

for one of it's main content containers. So you could end up with:

Code:

<div id="content">


<label for="content">Content:</label>


<input type="text" name="content" id="content" size="50" />


</div>

Although this has been fixed, my point being if you use something that generic, you can potentially run into conflicts. (The wysiwyg editor may also produce an id of content in some situations)
wysiwyg_textarea('content', '', 'PHPNukeAdmin', '50', '10');

That was all I meant by prefixing, creating an id that is much more likely to be unique; instead of common terms such as "content", "name", "info", etc.

Code:

<div id="content">


<label for="xyz-content">Content:</label>


<input type="text" name="xyz-content" id="xyz-content" size="50" /><br />


<label for="xyz-name">Name:</label>


<input type="text" name="xyz-name" id="xyz-name" size="50" />


</div>

I think all forms should have unique id's as well. This would help from a CSS selector standpoint; as well as targeting specific forms/elements for JS enhancement/fixes.

One example fresh in my mind, while working on a mobile theme that uses ajax, was how to adjust particular forms that were not ajax compatible. I ended up using php and loading specific JS depending on the $name and $op, but it would have been much easier to use css selectors if the form(s) had some type of unique id.

$("form#xyz-somename").attr('data-ajax', 'false');

Posted: Wed Jan 11, 2012 9:04 am

Ah ok, I see what you mean now, your referring to a conflict between the forms containing element div="content" and a form element name="content" and also using the same for the label.
That definitely would not be good from a styling perspective but wouldn't it be easier to use

Code:




<div id="content">


<form name="news-content"....

This also fits in with your idea of having a unique identifier for each form (use form name="")
Or if you're writing for HTML 5

Code:




<section class="form">


<form name="article-content">...

But yes, 'content' is far too generic and for no other purposes that it isn't really that semantic (everything is 'content' but what distinguishes one type of 'content' from another? - can I see what the code is trying to achieve by looking at the styling?).

The problem with going to in-depth with tons of id's and selectors is that the final CSS is going to be huge. Luckily, since most forms are going to be processed on a single page (or two with a form handler) we can at least dynamically load the CSS required as and when it is needed.

[edited this for brevity as I droned on for ages]

Posted: Wed Jan 11, 2012 9:59 am

With regard to

Code:

wysiwyg_textarea('content', '', 'PHPNukeAdmin', '50', '10');

Hate to say it but that just plain wrong, that is something that definitely needs to be fixed in the core rather than trying to find a way to band-aid around it.