A bit over one year ago, I was contacted by a friend with a problem on his business website. The problem was that far too many of the emails he received were junk mail – originating from the forms on his website. One form was a general Contact Us page, the other form was similar but included a file upload. He and his staff were dealing with hundreds of emails daily that were pure junk.
Of course, I solved the problem ... in a rather unusual way. I removed the email transport software and connected the website forms directly to the client's own email software. I did that using Javascript ... still use the form, but when the user clicks on submit, a script formats the data into a mailto: href statement and launches the user's own email software to send the email.
The interesting thing is that there are no complaints from any of his clients or website users. The volume of valid emails is up. No backlash, negative or otherwise.
This is a valid way to beat website form hijackers ...
I decided to make this a feature in a new footer I was designing. That would give me four distinct columns. One column for an "About Us" section, one column for "Quick Links" to major sections of the website, one column for "Legals / Terms" (still not sure what to call that section, and the fourth column for the "Message" section. Out of twelve columns total width: four for About Us, two for Quick Links, two for Legals/Terms, and four for the Message section. It got interesting when I decided that the Quick Links section could be hidden on a mobile phone size device.
My responsive grid couldn't handle properly hidding one column. I finally figured it out ... and there was great satisfaction knowing it was my own code. It did, however, get me to reconsider the break points to get an over-all smoother transition effect when resizing from a larger screen.
My breakpoints are now compatible with Bootstrap. Bootstrap actually has the most complete responsive grid system. In the distribution package, the Bootstrap grid comes in at 69Kb. My grid system, with the new breakpoints, is at 13Kb – both measured in raw. My responsive grid system is clearly not compatible with Bootstrap (or any other CSS framework). Mine is still smaller despite using more user-friendly class names – a simpler syntax that makes more sense to me. With a clearer syntax, I find it easier to follow the flow of logic the CSS would take when displayed at various sizes.
CSS is procedural (meaning progressive) in processing. That's actually why a responsive grid works so well. You specify your class names in the same order your wrote them in and it just flows nicely.
For example, any CSS framework that claims to be mobile-first has the CSS code structure starting with mobile. Then it specifies the breakpoints in successively larger sizes, ending with the largest screen size as the final breakpoint. (using the keyword min-width). That way, the screen resizes appropriately following the smallest to largest flow.
To anyone reading this that may be learning CSS or want to know more about how it works: study the code structure of Bootstrap – but, while studying the CSS code, have a close look at complex layouts that use Bootstrap, especially layouts with multiple class names to resize grids. It's fascinating when you follow the procedural flow.
By the way, that's how I finally resolved my column hiding issue: follow the procedural flow. This was one of the first times that I wanted to hide a column ... I did put in the class name to hide at the smallest size. What I forgot is the procedural part. That meant that on launch (regardless of size), the column was hidden ... I did not have a class specified to "show" it at sizes larger than the smallest size. Added that and it worked perfectly.