Unintended consequences of some CSS techniques


a form field with a negative margin margin-left: -99999999px breaks form input on iPhones and iPads

Discovering the Incompatibility Issue:

As an experienced web developer, I was handed the responsibility of maintaining an old WordPress plugin that incorporated a honeypot field as part of its anti-spam measures. The hidden honeypot field was designed to trap spam bots while staying inconspicuous to genuine users, and it had served its purpose effectively over the years. How effective I’m not100% sure.

The Hunt for a Larger Margin:

However, I soon encountered an unexpected layout quirk that necessitated a larger negative margin for this honeypot field. To accommodate the design requirements, I adjusted the negative margin, opting for an ample value like -99999999px, believing it would not hinder the honeypot’s functionality but simply keep it further out of sight.

The Curious Breakdown on iOS Devices:

Little did I anticipate that this seemingly benign change would have unforeseen repercussions. During testing, I noticed that form input capabilities on iOS devices, particularly iPhones and iPads, were severely affected. My tester noticed something was not right.

Searching for Explanations:

Baffled by this unexpected outcome, I embarked on a mission to understand the root cause of the problem. The issues was exasperated due to the fact that testing had advanced through several iterations of enhancement development modernizing the input layouts, without much testing on iOS.

Process of elimination:

In my mind this could only be either javascript or CSS and as there were four files, one each for legacy and one each for modern, I started commenting out the enqueues and testing via Browserstack. Fairly shortly it was clear the issues was in the legacy CSS. The ext step was made easy as I use git and commit frequently, and using PHPStorm’s Git Log and looking at comparisons was easy to find the few changes. The margin-left: -9999999px stood out and was worth testing a quit test reverting back to -999px on Browserstack and then a real iPhone confirmed the issue

Striking a Balance:

As I searched for solutions, I was mindful of the delicate balance between security and usability. While honeypot fields were effective in combating spam, it was crucial not to jeopardize the user experience, especially on a platform as widely used as iOS. I realized that the perfect solution lay in finding alternative techniques to hide the honeypot field while preserving form input capabilities on all devices. Hmm, obvious, use display: none;

Unraveling the Legacy Mystery:

I noted that the code for the honeypot and the negative margin adjustments were part of a legacy WordPress plugin that was built a decade ago. Uncertain of the value of this particular Honeypot, I investigated further, and the legacy code required the ‘bot’ to actually return a value in the field, whist this may happen it is no where near effective as requiring a secret key, and as the plugin is already protected by my WordPress anti spam plugin it seems that I might as well just remove this old, outdated technique and simplify the legacy code.


As an experienced web developer, this perplexing encounter with the incompatibility issue between the honeypot field and the large negative margin on iOS devices served as a valuable reminder of the challenges that come with maintaining legacy code and the difficulties of testing with diverse and non standardised web technologies.






Leave a Reply

Your email address will not be published. Required fields are marked *