<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: More than Meets the Eye: Form Validator</title>
	<atom:link href="http://mootools.net/blog/2010/04/30/more-than-meets-the-eye-form-validator/feed/" rel="self" type="application/rss+xml" />
	<link>http://mootools.net/blog/2010/04/30/more-than-meets-the-eye-form-validator/</link>
	<description>The Blog</description>
	<lastBuildDate>Mon, 20 May 2013 09:32:37 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Matthew Fedder</title>
		<link>http://mootools.net/blog/2010/04/30/more-than-meets-the-eye-form-validator/comment-page-1/#comment-1072</link>
		<dc:creator>Matthew Fedder</dc:creator>
		<pubDate>Fri, 07 May 2010 18:27:41 +0000</pubDate>
		<guid isPermaLink="false">http://mootools.net/blog/?p=880#comment-1072</guid>
		<description>&lt;p&gt;Looking at the examples, it seems like these validators only provide results that are useful for sighted users. Nothing demolishes your site&#039;s usability to unsighted users faster than having forms that do not submit.&lt;/p&gt;

&lt;p&gt;It sounds like it should be reasonable enough to implement two things that would aid accessibility:&lt;/p&gt;

&lt;p&gt;a) When clicking submit and validate fails, give focus to either a list of the validation errors, or the first validation error
b) Ensure that all validation errors are placed in the  for a field&lt;/p&gt;

&lt;p&gt;If I get a chance to implement this for one of my sites, I&#039;ll post the results.... somewhere or another.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Looking at the examples, it seems like these validators only provide results that are useful for sighted users. Nothing demolishes your site&#8217;s usability to unsighted users faster than having forms that do not submit.</p>

<p>It sounds like it should be reasonable enough to implement two things that would aid accessibility:</p>

<p>a) When clicking submit and validate fails, give focus to either a list of the validation errors, or the first validation error
b) Ensure that all validation errors are placed in the  for a field</p>

<p>If I get a chance to implement this for one of my sites, I&#8217;ll post the results&#8230;. somewhere or another.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: aaron</title>
		<link>http://mootools.net/blog/2010/04/30/more-than-meets-the-eye-form-validator/comment-page-1/#comment-1050</link>
		<dc:creator>aaron</dc:creator>
		<pubDate>Mon, 03 May 2010 02:12:25 +0000</pubDate>
		<guid isPermaLink="false">http://mootools.net/blog/?p=880#comment-1050</guid>
		<description>&lt;p&gt;Hey Matt,&lt;/p&gt;

&lt;p&gt;This very thing has been on my to-do list for the last few weeks. The data attribute thing specifically. Look for this change in future releases of the plugin (we&#039;ll maintain backwards compatibility of course). If you wanted to, you get help out; just fork on github, implement the new features, and send a pull request. If not, that&#039;s cool. We&#039;ll get to it soon enough.&lt;/p&gt;

&lt;p&gt;Aaron&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hey Matt,</p>

<p>This very thing has been on my to-do list for the last few weeks. The data attribute thing specifically. Look for this change in future releases of the plugin (we&#8217;ll maintain backwards compatibility of course). If you wanted to, you get help out; just fork on github, implement the new features, and send a pull request. If not, that&#8217;s cool. We&#8217;ll get to it soon enough.</p>

<p>Aaron</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Puchlerz</title>
		<link>http://mootools.net/blog/2010/04/30/more-than-meets-the-eye-form-validator/comment-page-1/#comment-1046</link>
		<dc:creator>Matt Puchlerz</dc:creator>
		<pubDate>Sun, 02 May 2010 17:05:15 +0000</pubDate>
		<guid isPermaLink="false">http://mootools.net/blog/?p=880#comment-1046</guid>
		<description>&lt;p&gt;I really like the API for adding new validations. That said, the manner in which you can specify validator arguments within a class name feels really hackish, for several reasons:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;The class name itself&#8212;while workable for our purposes here&#8212;becomes completely invalid.&lt;/li&gt;
&lt;li&gt;You lose the ability to style inputs based on their validation.&lt;/li&gt;
&lt;li&gt;Trying to retrofit loose JSON syntax within the value of an attribute with a known purpose is a code smell.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Instead, what if you were to utilize non-descript &lt;code&gt;data&lt;/code&gt; attributes, valid in HTML5? Perhaps you could leave the validator key as a class, and pass any arguments via a &lt;code&gt;data&lt;/code&gt; attribute of the same name:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;&lt;code&gt;&lt;form id=&quot;myform&quot;&gt;
    &lt;input type=&quot;text&quot; class=&quot;doesNotContain&quot; data-doesNotContain=&quot;qz&quot;&gt;
    &lt;input type=&quot;submit&quot;&gt;
&lt;/form&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;Then again, if you are concerned about current XHTML validity, the &lt;code&gt;data&lt;/code&gt; attributes may not be the way to go. In that case you might be able to get away with splitting up the class name with valid syntax:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;&lt;code&gt;&lt;form id=&quot;myform&quot;&gt;
    &lt;input type=&quot;text&quot; class=&quot;doesNotContain-qz&quot; /&gt;
    &lt;input type=&quot;submit&quot; /&gt;
&lt;/form&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;Yet at this point you would be limiting arguments to a string. I&#8217;m sure it was this consequence which led you to the loose JSON format to begin with.&lt;/p&gt;

&lt;p&gt;Either way, my preference would be for the &lt;code&gt;data&lt;/code&gt; attributes. They separate out the concerns, won&#8217;t run the risk of invalidating your class names, and are valid in the markup language that you&#8217;ll probably using soon, if not already.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I really like the API for adding new validations. That said, the manner in which you can specify validator arguments within a class name feels really hackish, for several reasons:</p>

<ul>
<li>The class name itself&mdash;while workable for our purposes here&mdash;becomes completely invalid.</li>
<li>You lose the ability to style inputs based on their validation.</li>
<li>Trying to retrofit loose JSON syntax within the value of an attribute with a known purpose is a code smell.</li>
</ul>

<p>Instead, what if you were to utilize non-descript <code>data</code> attributes, valid in HTML5? Perhaps you could leave the validator key as a class, and pass any arguments via a <code>data</code> attribute of the same name:</p>

<p><pre><code>&lt;form id=&quot;myform&quot;&gt;
    &lt;input type=&quot;text&quot; class=&quot;doesNotContain&quot; data-doesNotContain=&quot;qz&quot;&gt;
    &lt;input type=&quot;submit&quot;&gt;
&lt;/form&gt;</code></pre></p>

<p>Then again, if you are concerned about current XHTML validity, the <code>data</code> attributes may not be the way to go. In that case you might be able to get away with splitting up the class name with valid syntax:</p>

<p><pre><code>&lt;form id=&quot;myform&quot;&gt;
    &lt;input type=&quot;text&quot; class=&quot;doesNotContain-qz&quot; /&gt;
    &lt;input type=&quot;submit&quot; /&gt;
&lt;/form&gt;</code></pre></p>

<p>Yet at this point you would be limiting arguments to a string. I&rsquo;m sure it was this consequence which led you to the loose JSON format to begin with.</p>

<p>Either way, my preference would be for the <code>data</code> attributes. They separate out the concerns, won&rsquo;t run the risk of invalidating your class names, and are valid in the markup language that you&rsquo;ll probably using soon, if not already.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Lloyd</title>
		<link>http://mootools.net/blog/2010/04/30/more-than-meets-the-eye-form-validator/comment-page-1/#comment-1042</link>
		<dc:creator>Lloyd</dc:creator>
		<pubDate>Fri, 30 Apr 2010 23:07:39 +0000</pubDate>
		<guid isPermaLink="false">http://mootools.net/blog/?p=880#comment-1042</guid>
		<description>&lt;p&gt;Thanks again Aaron! Really appreciate the article with examples (Form.Validator, Form.Validator.Inline and Tips). I look forward to the next post.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Thanks again Aaron! Really appreciate the article with examples (Form.Validator, Form.Validator.Inline and Tips). I look forward to the next post.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse Donat</title>
		<link>http://mootools.net/blog/2010/04/30/more-than-meets-the-eye-form-validator/comment-page-1/#comment-1041</link>
		<dc:creator>Jesse Donat</dc:creator>
		<pubDate>Fri, 30 Apr 2010 20:34:46 +0000</pubDate>
		<guid isPermaLink="false">http://mootools.net/blog/?p=880#comment-1041</guid>
		<description>&lt;p&gt;Super useful.  I&#039;ve never given the validator a chance, but now I feel a strong urge to modify my PHP validator in a way that they could share creation with MooTools validation.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Super useful.  I&#8217;ve never given the validator a chance, but now I feel a strong urge to modify my PHP validator in a way that they could share creation with MooTools validation.</p>]]></content:encoded>
	</item>
</channel>
</rss>
