ext-7.7.0无水印版

#Ext JS Modern Toolkit Theming Guidelines ## Dynamic Variables All variables should be defined using the `dynamic()` function. This ensures that the last variable declaration wins, and is valid throughout the entire scope, allowing variables to derive from one another without concern for ordering. ## File Naming All Component variable and UI mixin declarations (all non-rule-generating code) should be placed in the theme's `sass/var/` directory in a file matching the Component's class path. Since all var files are included in the build regardless of whether or not the corresponding class is actually required by the app, this allows variables to freely derive from any other variable. Including mixins in the `sass/var/` directory ensures that a derived theme can override those mixins before they are called by any code in the `sass/src/` directory. All rule-generating code, including calls to UI mixins, and rules not contained inside the body of a mixin should be placed in the theme's `sass/src/` directory in a file matching the Component's class path. At build time, src files are only included if the corresponding Component is required by the app, thus ensuring that only the rules that the app actually needs are included in the CSS output. ## Base Styles vs. Configurable Styles Layout-specific styles, and styles related to core functionality of a Component should always be placed in `theme-base/sass/src/` in a file matching the Component's class path. The properties set in these rules should NOT be configurable using variables, as changing them would likely break the functionality or layout of the Component. Some examples of CSS properties that should generally not be configurable are: - `display` - `visibility` - `position` - `overflow` - `z-index` Configurable styles not related to the core functionality or layout of a component should always be controlled using variables. These variables should be defined in a scss file matching the component's class path in the `theme-neptune/sass/var` directory, and the rules that use these variables should be contained in a UI mixin in the same file. Examples of commonly configurable styles are: - `background-color` - `color` - `padding` - `border-radius` - `font-size` The neptune theme is the base for all other themes and should contain the universe of possible theming capabilities supported by the framework although it may not utilize them all itself. Themes derived from `theme-neptune` should avoid defining new UI mixins and creating their own CSS rules, but should instead simply set the values of variables defined in `theme-neptune`. When a new feature is needed by a derived theme it should be added to `theme-neptune` with variables to tune its behavior rather than adding the new feature only to the derived theme. ##Variable Naming Conventions Component variables should always begin with an xtype, and end with the CSS property name being styled, for example: $button-font-family: dynamic(helvetica); $button-color: dynamic(#fff); $button-background-color: dynamic(red); If the component has various states such as hovered, focused, and pressed, the name of the state should come immediately after the xtype, but before the CSS property name: $button-hovered-background-color: dynamic(blue); If the component has variables that control the styling of sub-elements, the name of the sub-element being styled should be included after the xtype, and state if present. For example, when styling the button's "badge" element: $button-badge-color: dynamic(#fff); $button-hovered-badge-color: dynamic(green); If however, the "state" refers to a sub-element's state, it should come after that element's name. For example, if a tab has a close icon that has a separate hover state from the tab: $tab-close-icon-hovered-background-color: dynamic(red); Components should have separate variables for border-width, border-color, and border-style, and all three properties should accept either a single value or a list of values so that 4 sides can be specified separately if needed: // BAD $button-border: dynamic(1px solid green); // GOOD $button-border-color: dynamic(red yellow green blue); $button-border-width: dynamic(1px 3px); $button-border-style: dynamic(solid); Variables should use the following names to indicate component state: - "pressed" when the component is being pressed by the user or is in a pressed state - "pressing" if the component has a "pressing" state that is separate from "pressed" - "hovered" when the mouse pointer is over the element - "focused" when the element has focus - "disabled" when the component is disabled. Since "focused" can sometimes be combined with other states components may need to provide variables that indicate a combination of states, for exmaple `$button-focused-pressed-border-color` ## Normal and Big Modes Each theme has 2 modes of sizing - normal and big. Big mode increases spacing and sizing to be more touch-screen friendly. Themes select whether or not to use big mode by inspecting `Ext.platformTags` in the theme's `overrides/init.js` and adding a CSS class name of `x-big` to the `<html>` element on the page. For example, the triton theme only enables big mode when loaded on a phone and uses normal mode otherwise: Ext.theme.getDocCls = function() { return Ext.platformTags.phone ? 'x-big' : ''; }; All variables that set properties affecting visual size of a component, like `font-size`, `line-height`, and `padding` should have big counterparts. Big variables always have the `-big` suffix appended to the end: $button-padding: dynamic(1rem); $button-padding-big: dynamic(1.2rem); SASS rules target big mode using the `.x-big` selector: .#{$prefix}button { padding: $padding; .#{$prefix}big & { padding: $padding-big; } } ##Component UIs Every component should have a UI mixin for generating multiple visual renditions of that component. The mixin should be named `[xtype]-ui`. For example `button-ui` or `panel-ui`. UI mixins should have a parameter for each of the component's global variables, and the parameter names should be the same as the global variable names with the exception that the mixin parameters should not contain the xtype in their names. For example, a global variable named `$button-border-radius`, would correspond to a parameter of the `button-ui` mixin named `$border-radius`. The parameters to the UI mixin should all default to null, and should not produce any output if unspecified by the caller. This means that when the mixin is invoked it should produce a set of styling that represents a delta from the default UI. This minimizes the number of css rules required to create new UIs since the mixin automatically eliminates any null values from the output. The styling for the default UI should be applied using CSS class names that do not contain a UI name, for example `x-button`, not `x-button-default`. This is the key to minimizing the number of rules required to create additional UIs, since all buttons will have the `x-button` class in addition to one or more optional `x-button-[ui]` classes. It allows the default UI to serve as a base set of styles for all other UIs. A typical UI mixin should look something like this: @mixin button-ui( $ui: null // $xtype is the only variable that does not default to null // since it is only used in selector names and does not affect // the output unless other non-null values are passed. It is // typically only passed by mixins of subclasses (see section on // "Derived UIs" below) $xtype: button, $background-color: null, $border-radius: null ) { // returns '' if $ui is null, otherwise prefixes $ui with "-" // To generate default UI we will not pass the $ui parameter