กฎการบังคับสำหรับข้อตกลงเกี่ยวกับแนวทางที่ตกลงกันไว้ไม่ว่าจะเล็กหรือใหญ่ ถ้าเกิดไม่มีอะไรไม่ถูกต้องในส่วนเพิ่มที่เติมนี้ ใน Code Guide, โปรด เปิด issue บน GitHub.
Every line of code should appear to be written by a single person, no matter the number of contributors.
</li> or </body>).<!DOCTYPE html>
<html>
<head>
<title>Page title</title>
</head>
<body>
<img src="images/company-logo.png" alt="Company">
<h1 class="hello-world">Hello, world!</h1>
</body>
</html>เพื่อเป็นมาตราฐานและให้เสถียรสำหรับการ render ใน ทุกๆ browser ที่เป็นไปได้ควรจะกำหนดในจุดเริ่มต้นบนทุกๆหน้าของ HTML
<!DOCTYPE html>
<html>
<head>
</head>
</html>From the HTML5 spec:
Authors are encouraged to specify a lang attribute on the root html element, giving the document's language. This aids speech synthesis tools to determine what pronunciations to use, translation tools to determine what rules to use, and so forth.
อ่านเพิ่มเติม เกี่ยวกับส่วน lang attribute ได้ที่นี้.
หัวข้อสำหรับรายการของโค้ดส่วนภาษา.
<html lang="en-us">
<!-- ... -->
</html>Internet Explorer สนับสนุนการใช้งานส่วนเอกสารที่รองรับได้อย่าง <meta> tag สำหรับการระบุเวอร์ชั้นของหน้า IE ที่ควรจะ render ออกมา เว้นเสียแต่ว่าต้องการในอย่างอื่น ซึ่งมันมีประโยชน์มากในการตั้งค่า สำหรับการใช้ IE เวอร์ชั่นล่าสุดที่สนับสนุน edge mode.
สำหรับข้อมูลเพิ่มเติม อ่านในส่วนของบทความของ Stack Overflow.
<meta http-equiv="X-UA-Compatible" content="IE=Edge">ในแนวทางที่เร็วและง่ายสำหรับรองรับการ render ที่ถูกต้องสำหรับเนื้อหาโดยที่อย่างชัดเจนในการเข้ารหัสตัวอักษร ควรที่จะหลีกเลี่ยงการใช้อักษรที่เป็นเฉพาะทางในส่วนของ HTML ซึ่งควรจะเข้ารหัสให้ตรงกับเอกสาร (โดยทั่วไปคือ UTF-8).
<head>
<meta charset="UTF-8">
</head>ในส่วนของ HTML5 ตามปกติแล้วไม่มีความจำเป็นในการระบุ type เมื่อนำไฟล์ CSS หรือ JavaScript เข้าอย่างเช่น text/css และ text/javascript เนื่องจากมันเป็นค่าเริ่มต้นอยู่แล้ว
<!-- External CSS -->
<link rel="stylesheet" href="code-guide.css">
<!-- In-document CSS -->
<style>
/* ... */
</style>
<!-- JavaScript -->
<script src="code-guide.js"></script>มุ่งมั่นที่จะดูแลรักษามาตราฐานและความหมายของ HTML แต่ยังคงอยู่กับใช้งานจริง ซึ่งมันควรใช้จำนวน markup ให้น้อยที่สุดเท่าที่จะเป็นไปได้เพื่อลดความซับซ้อนให้เหลือน้อยที่สุด
HTML attributes เฉพาะทางที่ควรจะใช้เพื่อง่ายต่อการอ่านโค๊ด
classid, namedata-*src, for, type, href, valuetitle, altaria-*, roleClasses เป็นส่วนประกอบที่ง่ายต่อการนำมาใช้งานซ้ำซึ่งควรอยู่ในตัวเลือกแรกในการนำมาใช้งาน และ Ids เป็นส่วนที่มีความเฉพาะเจาะจงมากขึ้นและควรจะใช้เท่าที่จำเป็นเท่านั้น (e.g., for in-page bookmarks)ควรอยู่ในตัวเลือกรองลงมา
<a class="..." id="..." data-toggle="modal" href="#">
Example link
</a>
<input class="form-control" type="text">
<img src="..." alt="...">A boolean attribute is one that needs no declared value. XHTML required you to declare a value, but HTML5 has no such requirement.
For further reading, consult the WhatWG section on boolean attributes:
The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.
If you must include the attribute's value, and you don't need to, follow this WhatWG guideline:
If the attribute is present, its value must either be the empty string or [...] the attribute's canonical name, with no leading or trailing whitespace.
สั้นๆคือ อย่าเพิ่ม value เอง
<input type="text" disabled>
<input type="checkbox" value="1" checked>
<select>
<option value="1" selected>1</option>
</select>ถ้าเป็นได้ ควรที่จะหลีกเลี่ยงการใช้ element ที่ฟุ่มเฟือยเกินไป เมื่อเขียน HTML ซึ่งบ่อยๆครั้งเรามักต้องใช้ซ้ำและ ต้อง refactoring แต่ได้ผลลัพธ์ที่น้อยมาก ยกตัวอย่างเช่น:
<!-- Not so great -->
<span class="avatar">
<img src="...">
</span>
<!-- Better -->
<img class="avatar" src="...">การเขียน markup ในไฟล์ JavaScript ทำให้หาเนื้อหายากขึ้น, ยากต่อการแก้ไข และ ประสิทธิภาพต่ำ ควรที่จะหลีกเลี่ยงกรณีนี้เท่าที่จะเป็นได้ให้มากที่สุด
: ประกาศใหม่ในทุกๆครั้งbox-shadow).rgb(), rgba(), hsl(), hsla(), or rect() values. This helps differentiate multiple color values (comma, no space) from multiple property values (comma with space)..5 ควรแทนด้วย 0.5 and -.5px ควรแทนด้วย -0.5px)#fff ถ้าตัวอักษรตัวพิมพ์เล็กมันง่ายที่สังเกตเห็นเมื่อต้องอ่านเอกสารซึ่งพวกมันมีแนวโน้มที่จะไม่ซ้ำกัน#fff ควรแทนด้วย #ffffffinput[type="text"]ซึ่งมันเป็นเพียงตัวเลือกในบางกรณีและเป็นวิธีที่ดีเพื่อให้มันสอดคล้องกันmargin: 0; ควรแทนด้วย margin: 0px;ถ้ามีคำถามในส่วนนี้ให้ดู syntax section of the Cascading Style Sheets article บน Wikipedia.
/* Bad CSS */
.selector, .selector-secondary, .selector[type=text] {
padding:15px;
margin:0px 0px 15px;
background-color:rgba(0, 0, 0, 0.5);
box-shadow:0px 1px 2px #CCC,inset 0 1px 0 #FFFFFF
}
/* Good CSS */
.selector,
.selector-secondary,
.selector[type="text"] {
padding: 15px;
margin-bottom: 15px;
background-color: rgba(0,0,0,.5);
box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff;
}Related property declarations should be grouped together following the order:
Positioning comes first because it can remove an element from the normal flow of the document and override box model related styles. The box model comes next as it dictates a component's dimensions and placement.
Everything else takes place inside the component or without impacting the previous two sections, and thus they come last.
For a complete list of properties and their order, please see Recess.
.declaration-order {
/* Positioning */
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
z-index: 100;
/* Box-model */
display: block;
float: right;
width: 100px;
height: 100px;
/* Typography */
font: normal 13px "Helvetica Neue", sans-serif;
line-height: 1.5;
color: #333;
text-align: center;
/* Visual */
background-color: #f5f5f5;
border: 1px solid #e5e5e5;
border-radius: 3px;
/* Misc */
opacity: 1;
}@importCompared to <link>s, @import is slower, adds extra page requests, and can cause other unforeseen problems. Avoid them and instead opt for an alternate approach:
<link> elementsFor more information, read this article by Steve Souders.
<!-- Use link elements -->
<link rel="stylesheet" href="core.css">
<!-- Avoid @imports -->
<style>
@import url("more.css");
</style>Place media queries as close to their relevant rule sets whenever possible. Don't bundle them all in a separate stylesheet or at the end of the document. Doing so only makes it easier for folks to miss them in the future. Here's a typical setup.
.element { ... }
.element-avatar { ... }
.element-selected { ... }
@media (min-width: 480px) {
.element { ...}
.element-avatar { ... }
.element-selected { ... }
}When using vendor prefixed properties, indent each property such that the declaration's value lines up vertically for easy multi-line editing.
In Textmate, use Text → Edit Each Line in Selection (⌃⌘A). In Sublime Text 2, use Selection → Add Previous Line (⌃⇧↑) and Selection → Add Next Line (⌃⇧↓).
/* Prefixed properties */
.selector {
-webkit-box-shadow: 0 1px 2px rgba(0,0,0,.15);
box-shadow: 0 1px 2px rgba(0,0,0,.15);
}In instances where a rule set includes only one declaration, consider removing line breaks for readability and faster editing. Any rule set with multiple declarations should be split to separate lines.
The key factor here is error detection—e.g., a CSS validator stating you have a syntax error on Line 183. With a single declaration, there's no missing it. With multiple declarations, separate lines is a must for your sanity.
/* Single declarations on one line */
.span1 { width: 60px; }
.span2 { width: 140px; }
.span3 { width: 220px; }
/* Multiple declarations, one per line */
.sprite {
display: inline-block;
width: 16px;
height: 15px;
background-image: url(../img/sprite.png);
}
.icon { background-position: 0 0; }
.icon-home { background-position: 0 -20px; }
.icon-account { background-position: 0 -40px; }Strive to limit use of shorthand declarations to instances where you must explicitly set all the available values. Common overused shorthand properties include:
paddingmarginfontbackgroundborderborder-radiusOften times we don't need to set all the values a shorthand property represents. For example, HTML headings only set top and bottom margin, so when necessary, only override those two values. Excessive use of shorthand properties often leads to sloppier code with unnecessary overrides and unintended side effects.
The Mozilla Developer Network has a great article on shorthand properties for those unfamiliar with notation and behavior.
/* Bad example */
.element {
margin: 0 0 10px;
background: red;
background: url("image.jpg");
border-radius: 3px 3px 0 0;
}
/* Good example */
.element {
margin-bottom: 10px;
background-color: red;
background-image: url("image.jpg");
border-top-left-radius: 3px;
border-top-right-radius: 3px;
}Avoid unnecessary nesting. Just because you can nest, doesn't mean you always should. Consider nesting only if you must scope styles to a parent and if there are multiple elements to be nested.
// Without nesting
.table > thead > tr > th { … }
.table > thead > tr > td { … }
// With nesting
.table > thead > tr {
> th { … }
> td { … }
}For improved readability, wrap all math operations in parentheses with a single space between values, variables, and operators.
// Bad example
.element {
margin: 10px 0 @variable*2 10px;
}
// Good example
.element {
margin: 10px 0 (@variable * 2) 10px;
}Code is written and maintained by people. Ensure your code is descriptive, well commented, and approachable by others. Great code comments convey context or purpose. Do not simply reiterate a component or class name.
Be sure to write in complete sentences for larger comments and succinct phrases for general notes.
/* Bad example */
/* Modal header */
.modal-header {
...
}
/* Good example */
/* Wrapping element for .modal-title and .modal-close */
.modal-header {
...
}.btn and .btn-danger)..btn is useful for button, but .s doesn't mean anything..js-* classes to denote behavior (as opposed to style), but keep these classes out of your CSS.It's also useful to apply many of these same rules when creating Sass and Less variable names.
/* Bad example */
.t { ... }
.red { ... }
.header { ... }
/* Good example */
.tweet { ... }
.important { ... }
.tweet-header { ... }[class^="..."]) on commonly occuring components. Browser performance is known to be impacted by these.Additional reading:
/* Bad example */
span { ... }
.page-container #stream .stream-item .tweet .tweet-header .username { ... }
.avatar { ... }
/* Good example */
.avatar { ... }
.tweet-header .username { ... }
.tweet .avatar { ... }/*
* Component section heading
*/
.element { ... }
/*
* Component section heading
*
* Sometimes you need to include optional context for the entire component. Do that up here if it's important enough.
*/
.element { ... }
/* Contextual sub-component or modifer */
.element-heading { ... }Set your editor to the following settings to avoid common code inconsistencies and dirty diffs:
Consider documenting and applying these preferences to your project's .editorconfig file. For an example, see the one in Bootstrap. Learn more about EditorConfig.