diff --git a/README b/README index df2e709..1cb86e0 100644 --- a/README +++ b/README @@ -1,39 +1,22 @@ - _____ _____ - /\ \ /\ \ - /::\ \ /::\ \ - \:::\ \ /::::\ \ - \:::\ \ /::::::\ \ - \:::\ \ /:::/\:::\ \ - \:::\ \ /:::/ \:::\ \ - /::::\ \ /:::/ \:::\ \ - /::::::\ \ /:::/ / \:::\ \ - /:::/\:::\ \ /:::/ / \:::\ \ - /:::/ \:::\____\/:::/____/ \:::\____\ - /:::/ \::/ /\:::\ \ \::/ / - /:::/ / \/____/ \:::\ \ \/____/ - /:::/ / \:::\ \ -/:::/ / \:::\ \ -\::/ / \:::\ \ - \/____/ \:::\ \ - \:::\ \ - \:::\____\ - \::/ / - \/____/ - TYPE/CODE - From 2010 till ∞ + >4SESz., _, ,gSEE2zx.,_ .azx ,w. +@Sh. "QEE3. JEE3. &ss `*4EEEEE2x.,_ "EEV ,aS5^;dEEEE2x., VEEF _ +\E2`_,gF4EEEx.?jF EE5L `*4EEEEE2zpn..ZEEF ;sz. `*EEESzw.w* '|EE. + ,dEEF `"?j] _,_ ,_ _, _,. L.EEEF !EEF _,, `"`` EE7 ,,_ + :EEE7 ,ws,`|EEL`JEEL`JEE)`JEEL zE5` E3. / [EE3 ,w. zE2` Ek .zE5^JZE3.,6EF [3 + {EEE. VEE7.EE2 AE3. EEV ZEEL{EEL ws. ; [EE1 EEEt{E3. JEELEE3. JE5LJEEF ,w, + \EEk,,>^ JEEL,@EEF ZE5L,ZE5^ "Q3. V2`. \EEk,,J' "Q[ yE2^ VE[_zEE[,"QEL V5F + ,ss :EE7 ;EEF L,szzw.. ,., `` + \E5.,E5F EE1. /; ``*4EEEZhw._ EEEL + ```` `` JEEE. `"45EEEhw.,,,] + +From 2010 till ∞ -typecode-js UI Library v0.1 - -All components require jQuery and the seed file (tc.seed.js) to be loaded first. -Other dependencies are listed in individual source files. - +typecode-js UI Library v0.2 Versions 0.1 - first release version, only whole version with all files in top level directory - - -Some notes added as an example. \ No newline at end of file +0.2 - Experimenting with requirejs \ No newline at end of file diff --git a/doc/index.html b/doc/index.html index 565a39a..2560465 100644 --- a/doc/index.html +++ b/doc/index.html @@ -60,7 +60,7 @@
The majority of the components in Typecode-JS are constructor functions that take one argument when they are instantiated. The convention we use is to call this argument options
. It's an object that the user passes in that defines configuration parameters for the given component. It is typically merged with a set of defaults that the component defines. Sometimes certain config params are required to be passed in, and sometimes they really are optional. Internally, a given component usually has a variable named o
, which is the result of merging the passed in options
with the defaults.
A lot of the instantiable components in the library manipulate, create, and/or refer to HTML elements that are either already in or eventually get added to the DOM. For example, an NI.Overlay
overlay
refers to an HTML container element (such as a <div>
) that holds whatever content is being displayed in a pop-up. Typically, components of this nature keep a variable named $e
, which is a jQuery object representing the outermost element that the component affects. (The dollar sign in variable names is just a convention we use to signify that the variable is a jQuery object). Many of the components that have an $e
element allow that element to be explicitly passed in through the options
object. In some cases, you can alternatively pass in an option named selector
, which is a jQuery selector that the component will use to find and define its $e
variable. This pattern is currently not fully consistent throughout the library, but it's what we've generaly been moving to.
A lot of the instantiable components in the library manipulate, create, and/or refer to HTML elements that are either already in or eventually get added to the DOM. For example, an NI.Overlay
overlay
refers to an HTML container element (such as a <div>
) that holds whatever content is being displayed in a pop-up. Typically, components of this nature keep a variable named $e
, which is a jQuery object representing the outermost element that the component affects. (The dollar Log in variable names is just a convention we use to signify that the variable is a jQuery object). Many of the components that have an $e
element allow that element to be explicitly passed in through the options
object. In some cases, you can alternatively pass in an option named selector
, which is a jQuery selector that the component will use to find and define its $e
variable. This pattern is currently not fully consistent throughout the library, but it's what we've generaly been moving to.
We're generally good about not defining the visual styling of elements used throughout the library. Occasionally, you will see some javascript code in Typecode-JS that does explicitly set css properties on certain elements. We only do this when the elements require those properties to do what they're supposed to. These properties tend to be things like display
or position
and never affect the visual design of anything.