www.webdeveloper.com
Results 1 to 5 of 5

Thread: HTML form code generator

  1. #1
    Join Date
    Jun 2014
    Posts
    3

    HTML form code generator

    Hello,

    I have developed a html form code generaor at the following address http://websolutions.comli.com/formgenerator.php . The intended final use is for allowing people to make their custom forms and send them to recipients for collection of reports and then download the reports in csv,html formats.

    Kindly review the page and any valuable suggesstions will be very much appreciated.

    thanking you all.


    Mirage

  2. #2
    Join Date
    May 2014
    Posts
    834
    Well, before you make a tool like this, you might want to learn HTML... and some accessibility norms like legibile color contrast and dynamic font sizes wouldn't hurt either.

    What do I mean by "learn HTML"? I added ONE field, and it vomited up this:
    Code:
    <form name="" method="" action="" enctype="multipart/form-data">
    <table>
    	<tr>
    		<td>Name:</td>
    		<td> <input type='text' id='contactName'	name='name'     /> </td>		
    	</tr>
    </table>
    </form>
    Until you have a input that returns multipart, it's a bad idea to add that encoding type... there is NO reason to be using tables for layouts in a form, and even if there were shouldn't that be a TH for the 'label' -- of course you CALL it a label -- but where are your LABEL TAGS?!? Ever heard of the for attribute? how is should be pointing at the ID on the input it's for? Where's your FIELDSET? Much less that unless you're still coding JS for forms using the old nyetscape 4 style scripting, there is rarely if ever a legitimate reason to have a name on a form.

    What that should PROBABLY look like is:
    Code:
    <form action="#" method="post">
    	<fieldset>
    		<label for="contactName">Name:</label>
    		<input type="text" id="contactName" name="name" />
    	</fieldset>
    </form>
    ... or at least if you have any idea how HTML is supposed to work.

    Between the tables for layout, incomplete forms, inaccessible px metric fonts sending me diving for the zoom, and that to be frank it fails to automate enough of the process since you're almost typing in everything ANYWAYS...

    Needs work.
    Java is to JavaScript as Ham is to Hamburger.

  3. #3
    Join Date
    Jun 2014
    Posts
    3
    Thank you for your valuable advice i will correct the flaws and will soon submit a more decent form generator. By the way i am not that good designer so messed up with colors. Can you suggest some reference where i can get it right.

    Thank you again.

  4. #4
    Join Date
    May 2014
    Posts
    834
    Colour contrasts is an accessibility thing, so the source you'd want for that is the WCAG -- web content accessibility guidelines.
    http://www.w3.org/TR/UNDERSTANDING-W...-contrast.html

    Which is needlessly wordy -- like most W3C specifications and recommendations it's like it was written by a lawyer, not an engineer, so let me break it down simpler for you.

    What they are saying is that if you convert your RGB colour to the luminance part of emissive HSL (Hue, saturation, luminance) that ideally you should have 75% difference. I usually say that with a clean large font 50% is the absolute minimum -- as per a joint UI design study done by IBM, Apple and Microsoft at the end of the '90's -- and that narrow fonts, small fonts, font smoothing, differences in rendering engines and so forth up it to that 75% or more...

    Note that's EMISSIVE, not the reflective formula programs like Photoshop use since most paint programs like Photoshop, GIMP and Paint Shop Pro were originally designed for print, NOT screen. (NO matter how many people mis-use it for such).

    The formula in question is:

    Y = 29.9% Red + 58.7% Green + 11.4% Blue

    This stems from that at 'maximum brightness' a normal healthy human eye is least sensitive to blue, and most sensitive to green; which oddly is a genetic quirk stemming from our ancestor's time in the bush. The formula is in the WCAG there somewhere, but can also be found in the IBM VGA specification, upon which all modern displays derive their functionality. On the VGA they use this formula to turn colours into greyscale. (people often forget there were some REALLY NICE "paper white" VGA CRT's back in the day, especially the one's IBM made for the PS/2)

    Since we're dealing on modern displays with 8 bit wide values, thats 0..255, so our 50% minimum is 128 (rounded up), the ideal 75% is 192 and the "goofy fonts and sizes" ideal being 204 or more.

    Now, let's do a simple example -- ever notice how red text on blue or vice-versa is illegible? Let's use the CGA/EGA/VGA 'bright red' (rgb 255, 85, 85) and 'bright blue' (85, 85, 255) and plug them into the formula. I like to round off all values to keep it simple when doing this by hand.

    CGA Bright Red
    R = 255 * 0.299 == 76~
    G = 85 * 0.587 == 50~
    B = 85 * 0.114 == 10~
    Y = 76 + 50 + 10 == 136

    CGA Bright Blue
    R = 85 * 0.299 == 25~
    G = 85 * 0.587 == 50~
    B = 255 * 0.114 == 29~
    Y = 25 + 50 + 29 == 104

    Contrast = 136 - 104 == 32
    32 / 255 == 0.125 == 12.5%

    ... and twelve and a half percent is so far away from our 50% minimum, if you put either of those colours as text atop the other, it is near impossible for half the population to read it, and those that can will have severe eye strain.

    Note -- if working in greyscale it's far easier as all values are the same the Y ends up the same as any one of the colour components. CGA Dark Gray for example is #555555 == rgb(85,85,85) so Y == 85... and that's why light gray (#AAAAAA, Y = 170) is useless on dark gray as the difference is only 85, which is 33.3% contrast, aka 2:1, way short of our minimum desired level.

    Right now you have a LOT of PSD Jockey's with the giant set of brass to call themselves "designers" who seem to be blissfully unaware of this... I'm seeing a LOT of sub 128 luma grays on sub 128 luma grays, or black on sub 128 grays -- and no matter how 'pretty' that is if nobody can read it, what good is it?

    A nice side effect of following the math based on actual research of the human eye? It also means your page will be legible to the colour blind.

    Hmm... math, based on multi-million dollar usability research by companies who actually made the hardware and established all the specifications; that might just be crazy enough to work!
    Java is to JavaScript as Ham is to Hamburger.

  5. #5
    Join Date
    Jun 2014
    Posts
    3
    Thank you for such valuable information. I will make good use of it.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles