HTML – walk-through – Part 2

Replace the native checkbox with an image of our own

https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Advanced_styling_for_HTML_forms

Full example: https://jsfiddle.net/7szyry4b/

First, we need to prepare an image with all the states required by a check box. Those states are: unchecked, checked, disabled unchecked, and disabled checked. This image will be used as a CSS sprite:

Check box CSS Sprite

Do not use display:none to hide the check box because as we’ll see below, we need the check box to be available to the user. With display:none, the check box is no longer accessible to the user which means that it’s impossible to check or uncheck it.

We are hiding real check box widgets from client. Simple technique is that pushing them out of view port.

Most important part is that we are using label:before selector and background property set custom background image for our checkbox widgets.

Since labels are for checkboxes (attached to them), if client clicks on labels, browsers will act like checkboxes are clicked, so css properties like checked, focus will become active. In this case we can benefit of these events (in this case checkbox state/status) and set appropriate css classes for those states.

Although CSS is expressive enough for check boxes and radio button, it is far from true for more advanced widgets. Even though a few things are possible with the <select> element, the file widget cannot be styled at all; the same goes for the date picker, etc. If you want to gain full control over form widgets, you have no choice but to rely on JavaScript.

there are some very useful libraries out there that can help you:

  • Uni-form is a framework that standardizes form markup and styles it with CSS. It also offers a few additional features when used in concert with jQuery, but that’s optional.
  • Formalize is an extension to common JavaScript frameworks (such as jQuery, Dojo, YUI, etc.) that helps to normalize and customize your forms.

The following libraries aren’t just about forms, but they have very interesting features for dealing with HTML forms:

  • jQuery UI offers some very interesting advanced and customizable widgets, such as date pickers (with special attention given to accessibility).
  • Twitter Bootstrap can be really helpful if you want to normalize your forms.

There are no clean, universal solutions but modern browsers offer new possibilities. For now, the best solution is to learn more about the way the different browsers support CSS as applied to HTML form widgets.

Many older pages use the following notation to indicate that the data should be sent to the same page that contains the form; this was required because until HTML5, the action attribute was required. This is no longer needed.

The GET method

Hey server, I want to get this resource.

The POST method

Hey server, take a look at this data and send me back an appropriate result.

Because HTTP is a text protocol, there are special requirements to handle binary data.

sending files
The enctype attribute

This attribute lets you specify the value of the Content-Type HTTP header. This header is very important because it tells the server what kind of data is being sent. By default, its value is application/x-www-form-urlencoded. In human terms, this means: “This is form data that has been encoded into URL form.”

  • Set the value of enctype to multipart/form-data because the data will be split into multiple parts, one for each file plus one for the text of the form body that may be sent with them.

Some browsers support the multiple attribute on the <input> element in order to send more than one file with only one input element. How the server handles those files really depends on the technology used on the server.

Authors can include data for inline client-side scripts or server-side site-wide scripts to process using the data-*=”” attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.

HTML – walk-through – Part 1

For more info please visit: https://developer.mozilla.org/en-US/docs/Web/HTML

HTML, which stands for HyperText Markup Language, is the most basic building block of a webpage and used for creating and visually representing a webpage. It determines the content of a webpage, but not its functionality. HTML is the language that describes the structure and the semantic content of a web document. HyperText Markup Language (HTML) is the core language of nearly all Web content.

The <form> element

The <input> tag is an auto-closing element, which means that if you want to formally close the element, you have to add a “/” at the end of the element itself and not a closing tag. On the contrary, <textarea> is not an auto-closing element, so you have to close it with the proper ending tag. This has an impact on a specific feature of HTML forms: the way you define the default value.

A button can be of three types: submit, reset, or button.

  • A click on a submit button sends the form’s data to the web page defined by the action attribute of the <form> element.
  • A click on a reset button resets all the form widgets to their default value immediately. From a UX point of view, this is considered bad practice.
  • A click on a button button does… nothing! That sounds silly, but it’s amazingly useful to build custom buttons with JavaScript.

centering a form and outlining it:

One of the hardest things to do with HTML forms is to style HTML widgets themselves. Text fields are easy to style, but some other widgets are not.

textarea aligning with labels. vertical-align: top is being used in order to do that. resize key is set for to allow end users to resize text area.

We need to give a name to our data in our forms. Those names are important on both sides; on the browser side, it tells the browser which name to give each piece of data, and on the server side, it lets the server handle each piece of data by name.

It’s strictly forbidden to nest a form inside another form. Doing so can behave in an unpredictable way that will depend on which browser the user is using.
When the value of the method attribute is post, enctype attribute is the MIME type of content that is used to submit the form to the server. Possible values are:
  • application/x-www-form-urlencoded
  • multipart/form-data: Use this value if you are using an <input> element with the type attribute set to file.
  • text/plain

target attribute: A name or keyword indicating where to display the response that has been received after submitting the form; this can be an <iframe>, tab, or window, for example. The following keywords are available as possible values for this attribute:

_self: Load the response into the same browsing context (<iframe>, tab, window, etc.) as the current one.
_blank: Load the response into a new browsing context.
_parent: Load the response into the parent browsing context of the current one. If there is no parent, this option behaves the same way as _self.
_top: Load the response into the top-level browsing context (that is, the browsing context that is an ancestor of the current one, and has no parent). If there is no parent, this option behaves the same way as _self.

The <fieldset> element is a convenient way to create groups of widgets that share the same purpose. A <fieldset> element can be labeled with a <legend> element. The <legend> element formally describes the purpose of the <fieldset> element.

The <label> element is the formal way to define a label for an HTML form widget. This is the most important element if you want to build accessible forms.

A <label> element is bound to its widget with the for attribute. The for attribute references the id attribute of the corresponding widget. A widget can be nested inside its <label> element but even in that case, it is considered best practice to set the for attribute because some assistive technologies do not understand implicit relationships between labels and widgets.

In addition to the <fieldset> element, it’s also common practice to use HTML titles and sectioning (<section>) to structure a complex form.

An input value can have following types: text, email, password, search, tel, url, checkbox, color, file, hidden, number, radio, range, button, image, reset, submit.

the <textarea> element is a regular element that can contain text content children. This has two impacts:

– If you want to define a default value for an <input> element, you have to use the value attribute, but for a <textarea> element, you put the default text between the starting tag and the closing tag of the <textarea>.
– Because of its nature, the <textarea> element only accepts text content; this means that any HTML content put inside a <textarea> element is rendered as if it was plain text content.

<datalist> example:

The <meter> and <progress> elements

Those two elements are a way to graphically represent a given numeric value. The difference between the two elements is mainly semantic.

 

Technically speaking, there is almost no difference between a button defined with the <button> element or the <input> element. The only noticeable difference is the label of the button itself. Within an <input> element, the label can only be character data, whereas in a <button> element, the label can be HTML, so it can be styled accordingly.

It’s worth noting that HTML form text fields are simple plain text input controls. This means that you cannot use them to perform rich editing (bold, italic, etc.). All rich text editors out there are custom widgets.

<input type=”text” pattern=”^cherry|banana$”> example:

<input type=”email” multiple> example:

<input type=”search” autosave> example:

Text Field vs Search Field

The main difference between a text field and a search field is one of look-and-feel (often, search fields are rendered with rounded corners). However, there is also one added feature to search fields: their values can be automatically saved to be auto completed across multiple pages on the same site.

<input type=”url”>

<input type=”numbermin=”1″ max=”10″ step=”2″>

different input types example: range, date, datetime, datetime-local, month, time, week, min-max.

Warning: The date and time widgets are very new, and even browsers that claim to support them often have significant user interface problems that make them difficult to use. Test your content thoroughly with different browsers before you deploy it!

Color picker

<input type=”color“> example:

<input type=”file” accept=”image/*” multiple> example:

CSS font and text features can be used easily with any widget (and yes, you can use @font-face with form widgets). However, browsers’ behaviors are often inconsistent. By default, some widgets do not inherit font-family and font-size from their parents. And many browsers use the system default appearance instead. To make your forms’ appearance consistent with the rest of your content, you can add the following rules to your style sheet:

If you want to keep the native look and feel of the widgets, you’ll face a little difficulty if you want to give them a consistent size. This is because each widget has their own rules for border, padding and margin. So if you want to give the same size to several different widgets, you have to use the box-sizing property:

This is a screenshot of the main form widgets on Chrome on Windows 7, with and without the use of box-sizing.

Style and Html Page Example: https://github.com/reyou/style-an-HTML-form

Free Fonts: https://www.fontsquirrel.com/

some highlights from this implementation:

@font-face implementation:

custom font “handwriting” implementation:

css3 rotate function and button:after content implementation :