Support » Plugin: Contact Form 7 Honeypot » W3C Validation in 1.11+ – Explanation and Work-arounds

  • Plugin Author Ryan

    (@daobydesign)


    Version 1.11 of the CF7 Honeypot plugin introduces a W3C validation error, due to the fact that the plugin employs a non-compliant way of disabling a browser’s autocomplete functionality.

    First, it is important to realize that outside of triggering a W3C validation error, this new feature does not negatively impact a site in anyway, and instead is designed to increase functionality of the site by improving the functionality of this plugin.

    The issue is how browsers handle the HTML5 autocomplete attribute. Debatably, the way it should work is that autocomplete for a form field should be able to be set to “on” or “off”, and browsers should respect that setting. However, not all browsers do, and thus some browsers may try to autocomplete a honeypot field (which needs to stay empty, remember), causing legitimate users’ form submissions to fail occasionally.

    The solution to this is to give the browser an autocomplete value it doesn’t know — i.e. not “on” or “off” — which stops the browser from autocompleting the field. This works well, but breaks W3C compliance, because the value is, by design, not valid.

    There are plenty of reasons to break from W3C validation compliance, and we feel this update is one of them. In fact, Mozilla Developer Network, a well-respected resource and community for web developers, agrees on this specific issue (a recommended read for anyone wishing to understand our choice in this matter).

    Solutions for Hardcore W3C Validators

    I know some of you are staunch W3C validation lovers, and so I’ve rolled out an update in version 1.12 of this plugin that addresses this. There is now an option when generating the honeypot shortcode in the CF7 form builder to force W3C valid values for autocomplete (specifically, the “off” value).

    Each website’s requirements are different, and I respect that for some W3C compliance is more important than fringe false-positive honeypot catches. Hopefully this new option provides a nice middle-ground for those whose need for W3C compliance is greater than the potential for valid form submissions being rejected due to browser autocomplete.

  • You must be logged in to reply to this topic.