I wanted to tell you about this excellent article by Tantek Celik for several days, but between the organizational and graphic overhaul of this site – the second not yet fully satisfying me – and a particularly busy weekend in the provinces, I had to give up somewhat writing.
Numerous articles expose the thousand and one good reasons to switch its sites in XHTML, whether it is by relying on the spirit – respect for standards, accessibility – or on the letter – through the validation tools set up by different organizations. Most of them are excellent, but if the answer to “why?” appears frequently, the answer to “how?” is becoming much rarer. Tantek proposes to bring it by addressing the eight main points to validate to produce a quality XHTML. After a stressful day of coding, you might want to unwind and play 카지노 사이트 online and make a bit of money.
To avoid misunderstandings, I would like to repeat here that the original article is not mine , and I highly recommend that you read it in its entirety if you understand English. I am content to take the basis of the eight points of Tantek in order to complete them with my opinion and my reflections.
1– Validate the syntax of your pages.
Syntax validation concerns both XHTML and CSS . Remember that 95% of the bugs and errors you will encounter during integration, whether they concern JavaScript based on DOM or style, resolve themselves with valid syntax. Keep in mind, however, that validation tools are indeed tools and not an end in themselves. As such, I particularly share the opinion of Dan Cederholmwhen he says that for a site intended to produce particularly important content injected by a large number of people – typically a wiki, CMS, or blog – validation errors are common, even more so if users aren’t up to speed. made standards. The validation must be done at the time of integration, and if possible after, but on sites of several thousand pages and with complex content, this is not always possible. On the other hand, on small sites, not validating is unforgivable.
Here are, if we except typos, the ten errors that I encounter most often in invalid sites:
- The lack of
<doctype>. The presence of a<doctype>header for any (X) HTML page is mandatory, and depending on the markup language used: HTML 4.01, XHTML 1.0 transitional or strict, XHTML 1.1 or XML. The<doctype>appropriate one is indicated on the W3C site in the pages dedicated to the chosen language, or in the headers of any valid page. Use the source, Luke! – a jedi who died from coding too much. - Beacons fallen into disuse or owners.
Some HTML tags have fallen into disuse, how<font>since HTML 4.01, or are specific to certain browsers, such as<embed>. They should therefore not be used. As such, I recommend you urgent reading of this excellent article on how to insert media content into webpage without using<embed>. - Proprietary or obsolete attributes.
Just like tags, some attributes may fall into disuse, this is the case withtarget, or simply have never been supported by W3C, such asautocomplete - Empty tags not closed.
Empty XHTML elements must end with a “/”, in particular<link>,<img>and<br>which become<link />,<img />and<br />in XHTML. - Block type elements nested in inline type elements .
Elements of type block like<p>and<div>must not be inserted into elements of inline type like<span>or<a>. - The closing tags placed wrongly and through.
Remember that you only close a tag on the sine qua non condition of having closed all the nested tags. - Unclosed tags.
The most frequent case is<div>not closed, like the one I just corrected by checking the correct syntax validation of this site. - Scripts and styles without a specified type.
In order to interpret a script, the browser needs to know its type. The two most common types are CSS styles and javascript for which we will indicate<style type="text/css">and<script type="text/javascript">, without forgetting to close the script base at the end. - Using camelCase in XHTML documents
One of the main principles of XHTML is to be completely lowercase. Using onclick for onclick or onsubmit for onSubmit is prohibited, even if the browser interprets a priori correctly. - Forms without the attribute
action
Whatever the value, the action attribute – the landing page during validation – must be mentioned, even if it is the current page.
2– Prohibit layouts using tables and gifs of 1 pixel side as a separator.
Is there really a need to dwell on it?
3– Delete the keywords <meta>
Keywords <meta>represent both a waste of time and space, and a deadly insult to the principles of visibility and accessibility contained in the Semantic Web, not to mention that search engines do not take them into account. Prefer their tags that are much more precise and meet all the requirements mentioned above.
4– Pay attention to the nomenclature of your classes and your identifiers.
Use the context instead of adding new classes, you will gain space and readability. For example, in an unordered list <ul class="menu">, you don’t have to declare a whole bunch of <li class="menuitem">when a single ul.nav liin your stylesheet is more than enough. Remember: HTML’s nested structure and cascading property inheritance principle in CSS saves both time, space, and aspirin when attempting to proofread stodgy tag soups. Use lowercase class and id names. Prefer id = ”sitenav” to id = ”siteNav”, you will gain readability and avoid hours of debugging for a simple typo in a class name. When possible, use class names from the different microformats if the opportunity arises.
5– Avoid large white spaces in your code.
Not only has it never made the code more readable, but in addition it is absolutely useless.
6– Use rel and hreflang in your translations.
When you link to a version of your site in a language other than its primary language, use the attribute rel="alternate"to indicate an alternate language, and hreflang="en"to indicate the destination language. The browsers respecting the standards even give the possibility of making appear the alternative language next to the link with a little CSS:
a [hreflang]: after {
content: "\ 0000a0 [" attr (hreflang) "]";
color: # 20705e;
text-decoration: none;
}
There is a fundamental difference between lang=or xml:lang=and hreflang=: lang=indicates the language of the current document, while hreflang=indicates the language of the linked document. There is a difference similar to that between rel=andrev= .
7- Delete the commented tags.
Commented tags do not have a priori anything to do in a web page in production. They waste time on display and unnecessarily increase the size of the pages. If you are using a templating system, comment out any tags you don’t want to appear using the language’s comment system, and avoid SGML <! -… -> comments as much as possible.
8- Use the hCard microformat .
It is very easy to insert the hCard microformat to mark your information directly. The tools and scripts supporting hCard are more and more numerous, and allow the insertion of your business card in vcard format with a single click. It would be a shame not to do without it?