@@ -109,57 +112,100 @@
What is Semantic?
- The Standard
- The Library
+ The UI Spec
+ The Module Spec
+ The Semantic Library
What is Semantic?
-
Semantic has two parts. The semantic standard, and the semantic library.
+
Semantic has two parts. The semantic specification, and the semantic library.
-
The standard
-
The semantic standard attempts to create a standard design pattern for describing static UI components (UI elements), and dynamic UI components or behavioral definitions (Javascript modules).
+
The UI Specification
+
The semantic specification creates a standard language for describing user interface elements.
-
Static elements: menus, columns, grids, tables, buttons, forms.
-
Dynamic components: popups, modals, chat rooms.
-
Behavioral components: form validation, state management, history.
+
+
+ | UI Elements |
+ UI Only |
+ menus, columns, grids, tables, buttons, forms |
+
+
+ | UI Modules |
+ UI + Behavior |
+ popups, modals, chat rooms |
+
+
+ | Behavioral Modules |
+ Behavior Only |
+ form validation, state management, polyfills, history |
+
+
-
Defining UI
-
Semantic creates an exchange format for UI, by defining a consistent HTML structure and set of class names for representing UI elements.
-
Sharing a common standard for UI releases the burden from developers at being a naming authorities in their own projects.
-
If together as a community we can define a standard for interface elements, we can share designs without having to modify our site's code to match the arbitrary specifications of a library, and interface designs can be freely exchanged between projects and teams.
+
Exchanging Designs
+
Semantic creates an exchange format for UI, by defining HTML structures and class names for UI elements that attempt to create a common language and make front end development less prescriptive.
+
Sharing a language for UI releases the burden from developers at being a naming authorities in their own projects. We can share a common visual vocabulary as a community, and design interchangeable interface elements without having to rely on the prescribed standards of a single developer.
-
What's in an element
-
UI elements definitions are made of 4 parts:
-
- - A prototype form of an element (A bunny has two long ears and is furry)
- - A definition of the relationship between a plural and singular instance of an element (Three white bunnies are each white)
- - A definition of possible variations of the element (A bunny can be large or small and can be spotted or fuzzy)
- - A list of states which the element can exist. (A bunny can either be hopping, eating or sitting still)
-
+
What's in an Element?
+
UI elements definitions are made of 4 parts:
+
+
+ | A prototype form of an element |
+ A bunny has two long ears and is furry |
+
+ | A definition of the relationship between a plural and singular instance of an element |
+ Three white bunnies are each white |
+
+
+ | A definition of possible variations of the element |
+ A bunny can be large or small and can be spotted or fuzzy |
+
+
+ | A list of states which the element can exist |
+ A bunny can either be hopping, eating or sitting still |
+
+
UI elements can be thought of as nouns, and variations as adjectives. Variations are written so to only describe the innate features of that variation, and must account for the differences when declared along-side other variations.
For example, in English, a large planet has a different meaning than a large chair, and would require different specific contextual definitions, but both are the same variant "largeness" to the person using the word.
Variations can be used together without negating each other unless used in a paradoxical way (A large small bunny).
-
I don't know what you're talking about just show me the code
+
Just Show Me the Code
If you'd like to shortcut any more explanation, check out the standard definition for a UI button for a live example.
UI Button Spec
-
Defining Modules
-
The Semantic modules standard is created primarily to accomplish two things:
+
The Module Specification
+
In Semantic, modules are user interface elements which require a behavioral definition. For example, a pop-up is understood by the actual action that occurs, it "pops up". Without this logic any pop-up is incomplete.
+
Semantic UI modules have two components, a definition of the UI element and a behavioral definition in javascript. Semantic includes a standard javascript module pattern, which helps in defining interface elements in a similar context to UI.
+
+
The goal of the module design pattern is primarily to accomplish three things:
- - Provide conveniences for module authors so that they can be written faster and without clutter.
- - Add features which make understanding and debugging other developers' modules simpler
+ - Make debugging modules simpler by making techniques like performance profiling, and logging easier and more useful.
+ - Make understanding new code easier, by defining a common pattern for initializing, destroying elements, modifying settings, and allowing more advanced features.
+ - Reduce prescriptive aspects of
Why use Semantic Modules?
- - Puts accessibility first. Although Coffeescript is beautiful, and Angular is smart, Semantic has a different agenda: to be easy to use, and opinionless. Semantic can be thought of more as the Aaron Copland of programming libraries. It only requires an understanding of jQuery and Javascript to begin writing code. If you're stuck there are also plenty of examples to help you get started.
- - Is self documenting. Instead of reading through inline comments to determine what a developer is intending, semantic allows developers to pass meaningful debug data where its most useful: the javascript console. This allows you to see the sequence of events that occur in a module , along with useful debug information, like the value of significant variables. If you're in the source code, debug statements also read similarly to code comments which provide context. Show me
-
- Designed to separate the arbitrary bits from the core logic of your module. Ever scroll through an unfimiliar library looking for the line of code where they define the ID tag for an expected html structure? Semantic keeps you from ever having to do that again. Developer decisions like metadata, classnames, selectors, and messages are separated from the less arbitrary parts of code. Show me
- - Lets you access anything, and change everything. Methods defined as part of module definitions are all invokable. Semantic also maps from dot notation to their appropriate locations inside the module, allowing developers not to only make flat modules. Settings can be changed at initialization, or after. Module defaults can be changed whenever. Show me
- - Plays nice with other libraries. Modules have teardown methods which will remove any bound events or initialized code. Modules also use namespaced events so you can have more flexibility over defining and clearing them
- - Patterns for every need. Semantic has patterns that work well both as a widget factory, and as a single entity.
+ - Puts accessibility first.
+
Although Coffeescript is beautiful, and Angular is smart, Semantic has a different agenda: to be easy to use, and opinionless. Semantic can be thought of more as the Aaron Copland of programming libraries. It only requires an understanding of jQuery and Javascript to begin writing code. If you're stuck there are also plenty of examples to help you get started.
+
+ - Is self documenting.
+
Instead of reading through inline comments to determine what a developer is intending, semantic allows developers to pass meaningful debug data where its most useful: the javascript console. This allows you to see the sequence of events that occur in a module , along with useful debug information, like the value of significant variables. If you're in the source code, debug statements also read similarly to code comments which provide context. Show me
+
+
+ - Separates arbitrary decisions from the fundamental mechanics of your module.
+
Ever scroll through an unfimiliar library looking for the line of code where they define the ID tag for an expected html structure? Semantic keeps you from ever having to do that again. Developer decisions like metadata, classnames, selectors, and messages are separated from the less arbitrary parts of code. Show me
+
+ - Lets you access anything, and change everything.
+
Methods defined as part of module definitions are all invokable. Semantic also maps from dot notation to their appropriate locations inside the module, allowing developers not to only make flat modules. Settings can be changed at initialization, or after. Module defaults can be changed whenever. Show me
+
+ - Plays nice with other libraries.
+
Modules include a destroy method which will remove any bound events or initialized code. Modules also use namespaced events so you can have more flexibility over defining and clearing them
+
+
+ - Patterns for every need.
+
Semantic has patterns that work well both as a widget factory, and as a single entity.
+
You really like to talk. Lets see some code
@@ -189,7 +235,6 @@
Icons
Dividers
-
The aim is to release pieces of the library on a schedule over the course of the next few months.
UI Release Calendar
The module library
Javascript modules.
diff --git a/docs/shape.html b/docs/shape.html
index 8c85944a7..914e85c08 100755
--- a/docs/shape.html
+++ b/docs/shape.html
@@ -164,9 +164,15 @@
Settings
Settings can be modified in three different ways.
- - A settings object can be passed in when initializing the plugin
$('.foo').shape({ moduleName: 'Godzilla'});.
- - Default settings for the module can be overridden by modifying $.fn.shape.settings.
- - Settings can be changed after a module is initialized by calling the 'settings' method on the module with either a settings object or a name, value pair.
$('.foo').shape('setting', 'moduleName', 'Godzilla');
+ - A settings object can be passed in when initializing the plugin
+
$('.foo').shape({ moduleName: 'Godzilla'});
+
+ - Default settings for the module can be overridden by modifying $.fn.shape.settings.
+
$.fn.shape.settings.moduleName = 'Godzilla';
+
+ - Settings can be changed after a module is initialized by calling the 'settings' method on the module with either a settings object or a name, value pair.
+
$('.foo').shape('setting', 'moduleName', 'Godzilla');
+
Settings can also be read programmatically: $('.foo').shape('setting', 'moduleName');
diff --git a/docs/stylesheets/example.css b/docs/stylesheets/example.css
index 4daa2c10e..819b8b842 100755
--- a/docs/stylesheets/example.css
+++ b/docs/stylesheets/example.css
@@ -170,6 +170,19 @@ a:hover {
float: right;
clear: both;
}
+#example .page {
+ font-family: "Arial, Helvetica, sans-serif";
+}
+#example .page .of {
+ font-family: 'Neutraface';
+ font-size: 12px;
+ color: #AAAAAA;
+ padding: 0px 5px;
+}
+#example .page .menu,
+#example .page .of {
+ font-family: 'Neutraface';
+}
#example .side.buttons {
position: fixed;
@@ -198,6 +211,10 @@ a:hover {
margin-left: -630px;
}
+#example .settings.table td:first-child {
+ font-weight: bold;
+}
+
@media only screen and (max-width : 1640px) {
diff --git a/src/ui/flat/button.css b/src/ui/flat/button.css
index 0f3a47a5c..aa7c1023f 100755
--- a/src/ui/flat/button.css
+++ b/src/ui/flat/button.css
@@ -583,15 +583,17 @@ Containing Icon
display: block;
}
.ui.button.attached.top {
- margin-left: -1px;
- margin-right: -1px;
+ border: 1px solid rgba(0, 0, 0, 0.1);
+ border-bottom: none;
+
-webkit-border-radius: 5px 5px 0px 0px;
-moz-border-radius: 5px 5px 0px 0px;
border-radius: 5px 5px 0px 0px;
}
.ui.button.attached.bottom {
- margin-left: -1px;
- margin-right: -1px;
+ border: 1px solid rgba(0, 0, 0, 0.1);
+ border-top: none;
+
-webkit-border-radius: 0px 0px 5px 5px;
-moz-border-radius: 0px 0px 5px 5px;
border-radius: 0px 0px 5px 5px;
diff --git a/src/ui/flat/icons.css b/src/ui/flat/icons.css
index ab801dc36..beb701c84 100755
--- a/src/ui/flat/icons.css
+++ b/src/ui/flat/icons.css
@@ -36,8 +36,6 @@ i.icon:before {
font-family: 'Icons';
speak: none;
opacity: 0.75;
-
- vertical-align: top;
}
/* manual corrections */
diff --git a/src/ui/flat/menu.css b/src/ui/flat/menu.css
index 346b9ec6f..a02c1d69e 100755
--- a/src/ui/flat/menu.css
+++ b/src/ui/flat/menu.css
@@ -19,11 +19,18 @@
background-color: #EEEEEE;
font-size: 0px;
}
+.ui.menu a {
+ color: #333333;
+}
/* Items */
.ui.menu .item {
display: inline-block;
border-right: 1px solid rgba(0, 0, 0, 0.1);
+
+ -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
+ -moz-user-select: -moz-none;
+ -khtml-user-select: none;
}
.ui.menu .item:first-child {
border-left: 1px solid rgba(0, 0, 0, 0.1);
@@ -68,6 +75,8 @@
opacity: 1;
border: 1px solid rgba(0, 0, 0, 0.1);
+ border-top: none;
+
-webkit-box-shadow: 0px 1px 2px rgba(0, 0, 0, 0.1);
-moz-box-shadow: 0px 1px 2px rgba(0, 0, 0, 0.1);
box-shadow: 0px 1px 2px rgba(0, 0, 0, 0.1);
@@ -78,6 +87,13 @@
font-size: 0.9em;
display: block;
color: #555555;
+
+ -webkit-touch-callout: none;
+ -webkit-user-select: none;
+ -khtml-user-select: none;
+ -moz-user-select: none;
+ -ms-user-select: none;
+ user-select: none;
}
.ui.menu .dropdown.item .menu .item:first-child {
border-top: none;
@@ -132,6 +148,9 @@
background-color: #333333;
color: #FFFFFF;
}
+.ui.black.menu a {
+ color: #FFFFFF;
+}
.ui.black.menu .item {
border-right: 1px solid rgba(255, 255, 255, 0.1);
}
diff --git a/src/ui/flat/panel.css b/src/ui/flat/panel.css
index b20a2f8f7..d75197995 100755
--- a/src/ui/flat/panel.css
+++ b/src/ui/flat/panel.css
@@ -8,7 +8,7 @@
padding: 0px;
- box-shadow: 0px 0px 1px 0px rgba(0, 0, 0, 0.15);
+ box-shadow: 0px 0px 1px 0px rgba(0, 0, 0, 0.25);
-webkit-border-radius: 4px;
-moz-border-radius: 4px;
diff --git a/src/ui/flat/table.css b/src/ui/flat/table.css
index cd89fd767..910869027 100755
--- a/src/ui/flat/table.css
+++ b/src/ui/flat/table.css
@@ -1,7 +1,9 @@
.ui.table {
width: 100%;
border-collapse: collapse;
+ background-color: rgba(255, 255, 255, 0.95);
color: #333333;
+ box-shadow: 0px 0px 1px rgba(0, 0, 0, 0.25);
}
/* Standard Table Icons */