Effective front End 2: Optimizing HTML tags

Borrowed the name of effective, began to write effective series, summed up some tips on the front end.

Some people write the page will go to an extreme, almost all the pages of the label are used Div, the reason, with Div has a lot of advantages, one is the DIV has no default style, there will be no margin, background and other initialization settings, in addition may feel no div can use what. So look at his page, an expansion is a div, then expand or Div, expand four or five layers are div.

This makes no difference to the user, but as a sought after programmer, this kind of writing seems to be quite uncomfortable. Some people know that HTML5 has added a lot of tags, but also not to study its usage, anyway, with the traditional div is not very good, why to use the new thing is not good compatibility. But if everyone thinks so, the new technology will not develop. There are different or better options, of course, to try.

Add a point, not to say that using a div is not good, the use of Div or Div, but there are other better choices should choose the other.

Choose the right label

1. If it is a piece of text, then use the P tag, if it is a title, then use the H1~H5 tag bar, like this:

a bad exampleXHTML

1	<p Class="title"> Hello, I am a title </p>

Clearly know it is a title, why not use the title tag it:

recommended WordingXHTML

1	Hello i am a real title

This has the advantage of allowing you to diversify your labels and use the tag selector when writing a style, so you don't have to set a lot of class

2. If it is a form, then use Form bar, with a form with a lot of advantages, I in the "Effective front end 1: can use HTML/CSS solve the problem do not use JS" inside already mentioned two points, 1th is automatic form submission, by writing a form of action You can automatically search for jumps:

XHTML

1234	<form id="Search-form"action="/search"> <input type="Search"name="keyword"> <input type="number"name="Price"> </form>

Instead of having to get the value of each input yourself, then go to spell the parameter jump.

2nd, the automatic Monitoring return event submission, as long as the write a form, there is input, the user will be able to press ENTER to automatically submit, without having to listen to the KeyPress event processing.

In addition to these two points, writing a form also has a big advantage when you use the traditional jquery selector to get the form value:

get form data using jqueryXHTML

12345678

<div> <input id="User-name"> <input id="password"> </div><script>varuserName=$("Input#user-name"). Val(), Password=$("Input#password"). Val(); </script>

Here, in order to get two form data, check the DOM two times, assuming you have 10, you have to check 10, if 20, it will affect the performance, especially on the mobile side. But if you change the div into a form, the situation is different:

Use FormXHTML

1234	<form id="register"> <input name="User-name"> <input name="password"> </form>

When you get the form data, you can use this:

JavaScript

1234	varform=document. Forms. Nameditem("register"); //var form = document.getElementById ("register");varuserName=form["User-name"]. Value, Password=form. Password. Value;

Just use the native form property to get input to the form, without jquery, without looking at the DOM. At the same time there is a disadvantage, that is, when the name of input does not exist, Form.password is undefined, and then get the value of the hang, but so early exposure to the problem in some cases will be better

3. HTML5 input

HTM5 provides many types of input, using these input has many advantages, the browser will be based on different input to make the corresponding optimization, such as on the iphone, using different input will pop up a different keyboard:

<input type= "Email" >

<input type= "Number" >

<input type= "Tel" >

iphone bullets different types of keyboards for easy input

Even in non-HTML5 browser can be used, because the browser will not know the type as the default text, the only one with compatibility problem is IE8, IE9 will not know the input force set to text, that is, a visit page, IE will put HTML inside the <input type="email"> Forced rendering <input type="text"> , which leads you to have no way of using CSS/JS under this type control:

ie forced castration does not know the input type is textCSS

1234	/*will on ie8/ie9*/ Input[type=email]{ }

However, the type of the dynamic setting can take effect. It will be killed when the rendering is initialized. But the impact of this should not be great. The author also wrote a HTML5 input form validation plug-in, in order to unify the HTML5 form browser processing inconsistencies, see: Implementing Cross-browser HTML5 form validation

There is also a small hole, is <input type="number"> in chrome below is not allowed to enter a comma, if you want to support the input comma can not use number.

Other:

If the content is a table, then use table,table has the advantage of self-adaptation;

If it is bold with B/strong, rather than manually set up font-weight, so there is a benefit, in the future to change the font, only need to set B/strong font-family, if it is manual writing font-weight, then you have to look for;

If it is a picture, then use IMG, and write alt, help SEO and do not load the picture to display the help copy, also can use Picture/srcset to do the response-type picture;

If it's an input box, write input instead of writing a P tag yourself, and then set the Contenteditable property, because there's a problem with the cursor positioning on the iphone;

If it is a jump chain then write a tag, instead of using JavaScript to listen to the Click event, and then do the jump yourself. Because with a tag can let the search engine crawl the content of the entire site, and with a tag also has a benefit, that is, when the mobile phone is not triggered when the Touchstart, if you do jump, or click, or have to make a click to enhance the library, I am accustomed to write:

use a tag to jumpXHTML

12345678

<ul> <li> <a style="Display:block;color:inherit"> src="pic.jpg"> <p>desc</p> </a> </li> </ul>

Using HTML5 semantic tags

HTML5 has added a lot of semantic tags, a traditional HTML4 page structure:

HTML4 page StructureXHTML

123456789

<ul Class="nav"> <li></li> </ul><div Class="header"></div> <div Class="main"> <div class="section"></div> <div class="section"></div> </div><div Class="Footer"></div>

Can be modified with HTML5 's new label:

XHTML

1234567

<nav></nav> <main> <section></section> <section></section> </main> <footer></footer>

In addition to the semantic characteristics, more importantly, the organization of the page has changed fundamentally, you can only write a H1 tag in html4, and now you could write a lot of H1 tags. Because HTML5 's page outline is no longer divided according to H1, H2 and other labels, it is based on the chapter of the page. As follows:

XHTML

1234567891011

<body> Effective2 <section> Use the appropriate labels <section>using form</section> <section>using a tag </section> </section> <section> using h5 tags </section> </body>

The search engine will summarize this page as the following outline:

Effective2

1. Use the appropriate label
   1. Use form
   2. Use a label
2. Using H5 tags

Readers can experiment with this site: HTML5 outliner.

We use section to divide the chapters, in addition to the sections, there are article, Nav, aside, these four tags can be nested into each other hierarchical relationship, as above, section and nested parts, and each level can be arbitrary h1~ H5 tags, the same level according to the title label primary and secondary division.

The four tags and div differences are as follows:

1. div: Used as a normal container
2. section: As an ordinary chapter
3. article: Strong independence, such as the author of this blog, the outer layer of the article tag
4. aside: Can be used as a container for the content of the page theme, like Sidebar, comments, like the comments at the bottom of this blog aside

The use of the HTML5 label can be described in this article: HTML5 Semantic label Usage specification

This blog has nothing to say about an incident, to stand on the shoulders of the browser to develop, because the front end is the root browser to deal with. This and the first "effective front end 1: can use HTML/CSS solve the problem do not use JS" principle is interlinked.

Effective front End 2: Optimizing HTML tags