See www.zabbix.com for the official Zabbix site.

HTML and CSS coding guidelines

From Zabbix.org
Jump to: navigation, search

HTML coding guidelines

Naming conventions

  • Class names, IDs and data attributes should be written with a dash, e.g. .item-form or data-item-id.
  • Class names should be chosen based on their semantic values, not on their appearance or a particular location on the layout, e.g. .error instead of .red, or .main-menu. instead of .top-menu.

Tag usage

  • HTML tags should used based on their semantic values, not on their visual appearance, e.g. strong may be used to highlight something important, but not just to make the text bold. Tags, that have no semantic value, such as font or br, should not be used at all.
  • The visual appearance of the elements should not be defined using HTML tags, such as font or br, but CSS.

CSS coding guidelines

Syntax

  • Hexadecimal color codes must we written in lower case.

Selectors

  • CSS selectors for structured groups of elements should start with the root element.
<div class="widget">
	<div class="header"></div>
	<div class="body"></div>
</div>
/* correct */
.widget { ... }
.widget .header { ... }
.widget .body a { ... }

/* wrong */
.widget { ... }
.header { ... }
.body a { ... }

/* also wrong */
.widget { ... }
.widget-header { ... }
.widget-body a { ... }
  • Selectors for common inline elements can be written without specifying their location.
.button { ... }
a:visited { ... }
  • Styles, that are specific for some page, should be defined starting from the unique page root element.
/* some special styles for a widget on the trigger monitoring page */
.w.list.trigger-mon .widget .body { ... }

/* different .button styles for forms */
.w.edit .button { ... }
  • Avoid using unnecessary HTML elements in selectors to be less bound to a specific DOM structure.
/* correct */
.w.list .item .status strong { ... }

/* wrong */
.w.list tr.item td.status strong { ... }

Style definition

  • Styles should always be defined in the corresponding CSS files, never in the style attribute.
  • Common styles should be put in default.css, theme specific styles - in the corresponding theme's CSS file (the only exception is if we need to set some specific user-defined value, e.g. a path to particular background image, that is stored in the database).
  • Styles should be defined starting from more common to more specific.
/* some common input and button styles */
input { ... }
.button { ... }

/* input and button styles inside of object configuration forms */
.w.edit input { ... }
.w.edit .button { ... }

/* specific styles for the item configuration form */
.w.edit.item-edit input { ... }
.w.edit.item-edit .button { ... }

Class naming

  • Words must be separated by "-" character. Example: "host-header-right".
  • Icon classes should start with "icon-". Example "icon-maintenance".