Static properties whose values are functions are regarded as static methods.

Perhaps in such cases such features should just get documented and referred to as static methods. In the future, however, it should be possible to register a feature as a static property, but where the type of the property can be function, through a formal feature registration mechanism.

Documenting extension modules can mess things up.

Loading extension modules in the documentation build script in order to document them can have the side effect of modifying a class, and other modules that are subclasses of the modified class that are then documented later appear to have features that they really do not have, because they've inherited the features that were extended on their base class by loading and documenting the extension module.

State properties whose initial values are objects or arrays are incorrectly indicated as having been overridden in a module that inherits the feature.

This is simply because the initial value in the subclass is a clone of the initial value in the base class and not a shared reference. The initial value is a clone because the whole property definition is a clone. Not sure what the solution is.

2.2.1. - improve page widget detection method

2.7.1. - have sections be collapsible, with collapsible state remembered across updates

2.7.2. - for widgets...

2.10.1. - mouseover nodes of widgets to show info tooltip about node and owner widget

2.12.1. - widget instance queries

2.12.2. - module queries

2.12.3. - DOM node queries

2.12.4. - localized string queries

2.12.5. - stuff that's already interspersed in the summary tab info

4.1.1. Add Head Comments Info

5.1.1. - all pages

5.1.2. - example pages

5.1.3. - misc

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript

13.1.1. - finish loop optimization approaches performance test...

if (blah) doSomething ();   ==>  blah && doSomething ();
if (!blah) doSomething ();  ==>  blah || doSomething ();

alert (blah);            // displays "Hello"
alert (blah + 'Brian');  // displays "Hello, Brian"

define blah

var blah = {};
blah.toString = function () {return 'Hello'};
blah.valueOf = function () {return 'Hello, '};

or...

var blah = new String ('Hello');
blah.valueOf = function () {return 'Hello, '};

or...

var blah = new String ('Hello');
blah.valueOf = function () {return this.toString () + ', '};

if (someInstance.constructor == SomeClass) {
  // ...
}

if (someInstance1.constructor == someInstance2.constructor) {
  // ...
}

someInstance2 = new someInstance1.Class (someInstance1.get ())

optimize the following statement...

someCondition ? variableA - variableB : variableA
variableA - (someCondition ? variableB : 0)
variableA - someCondition * variableB        // works if someCondition is guaranteed to produce a boolean
variableA - (someCondition && variableB)     // works even if someCondition is not a boolean value

19.1.1. General

19.1.2. Module References

resultTYPE = object.methodName (...);

object.methodName (...);

Add an Entry to the Site Map

19.2.1. Announce the New Explainer

20.2.1. - UIZE works in smart phones and other mobile devices with Web browsers that support JavaScript and other Web standards

20.2.2. - emphasize that UIZE file size is compact, and that features better suited to devices with more real estate, processing power, or memory need not be loaded in

20.4.1. - progressive enhancement

20.7.1. - subclassing existing widget classes, or other classes

20.7.2. - extending color support

20.7.3. - extending Fx

20.7.4. - adding support for communication protocols

I read over the JavaScript Library Documentation and here are my suggestions:

Looking at all my suggestions, I think I understand now where my confusions lie. In some regards I'm a visual learner so I like to see things rather than just read or hear them. So for the more tricky explanation, an example of what you're talking about would clear things up for me. Towards the end of the explainer it seems that you talked about some of the things I was mentioning earlier on the explainer, so maybe some well-placed links to further in the document might help as well.

But overall after reading the explainer, I think you really need to beat the developer over the head as to why library files are useful. There's all this explanation of how they were and some dancing you have to do, but only a little bit on why you would actually use them.

23.2.1. General:

23.2.2. Introduction:

23.2.3. Where They Live:

23.2.4. 3.1

23.2.5. 3.1.2.3

23.2.6. Real World Examples

23.2.7. 7.1

24.1.1. Order Unimportant

24.1.2. Requiring Extension Modules

You can have multiple consecutive module declarations that share common required modules and things will work correctly, rather than some of the required modules being loaded multiple times (which would cause all sorts of problems with modules stomping over themselves when re-declaring themselves and thereby crippling code).

EXAMPLE

Uize.module ({
  required:'Uize.Widget',
  builder:function () {
    alert ('build the first anonymous module');
  }
});

Uize.module ({
  required:'Uize.Widget',
  builder:function () {
    alert ('build the second anonymous module');
  }
});

The first anonymous module being declared requires the Uize.Widget module. If this module is not already loaded, then the module loader mechanism will load it asynchronously. The second anonymous module declaration occurs immediately after the first (because this code is synchronous), and it also requires the Uize.Widget module. A second request to load this required module externally is not made, because the module loader mechanism knows that loading of the module is already in progress.

You can have an inline module declaration that requires other external modules, and subsequent inline module declarations that require that first module will correctly wait until it is built - rather than trying to load it externally

EXAMPLE

Uize.module ({
  name:'Uize.MyInlineModule',
  required:'Uize.Widget',
  builder:function () {
    alert ('build Uize.MyInlineModule');
  }
});

Uize.module {{
  required:'Uize.MyInlineModule',
  builder:function () {
    alert ('build the anonymous module that requires Uize.MyInlineModule');
  }
});

The Uize.MyInlineModule module may not be built yet when the second, anonymous module is declared because Uize.MyInlineModule requires the module Uize.Widget that may not yet be defined and may have to be loaded asynchronously. Now, when the anonymous module is declared, the module loader mechanism doesn't try to load Uize.MyInlineModule externally even though it is not yet defined, because it knows that this required module is in the process of being defined.

Document the pattern of creating inner classes.

24.4.1. Private Inner Classes

Uize.module ({
  name:'MySite.MyClass',
  required:[
    'MySite.Widget',  // required as base class of inner class
    'Uize.Data'       // required for inner class
  ],
  builder:function () {
    /*** create the inner class ***/
      var _MyInnerClass = MySite.Widget.subclass ();
      // code here to further create the inner class

    /*** build the class ***/
      // code here to build the main class for the module
  }
});

24.4.2. Public Inner Classes

24.4.3. Can't Have Inner Subclasses

Uize.map (30,'key > 1 ? this [key - 2] + this [key - 1] : key')

Can't do this with JavaScript 1.6's map method (or the map methods in any other framework), because the map function can't reference the newly created target array.

<!--
// -->

Describe the many ways in which UIZE is utilized on the zazzle.com Web site.

In discussion of UIZE, WRT how UIZE compares to other frameworks.

29.3.1. Discuss convenience iterators...

A feature can be a side effect of an implementation by design.

In other words, an elegant design can have the intention of producing positive side effects. From a certain perspective, it might seem purely lucky or fortuitous that certain good things fall out of a particular implementation choice. But a good designer has their mind tuned to deliver positive knock-on effects from their design choices.

30.2.1. - lazy assignment combined with conditional execution

if (!_param) _param = _lastValue;
if (_param) {
  // do stuff
}
_lastValue = _param;

if (_param || (_param = _lastValue)) {
  // do stuff
}
_lastValue = _param;

30.4.1. - how to test if a multi-line string contains any lines exceeding a specific length

function hasLineExceedingMaxLength (sourceStr,maxLength) {
  return new RegExp ('^.{' + (maxLength + 1) + ',}$','m').test (sourceStr);
}

30.4.2. - how to create a copy of an array...

myArray.concat ();

30.4.3. - how to split out the characters from a string into an array of characters...

myString.split ('');

30.4.4. - how to double space the characters in a string...

myString.split ('').join (' ');

C:/~uize/UIZE-JavaScript-Framework/examples/hierarchical-selector.html

C:/~uize/UIZE-JavaScript-Framework/examples/two-hierarchical-selectors.html

C:/~uize/UIZE-JavaScript-Framework/examples/button-types.html

C:/~uize/UIZE-JavaScript-Framework/examples/button-toggle.html

C:/~uize/UIZE-JavaScript-Framework/examples/swap-image-png.html -- mention "JavaScript animation"

33.1.1. - each individual test can specify its title, so that...

33.1.2. - give better status updates, so that the user knows...

34.1.1. - Changed.* event

34.3.1. - Color Theme Transformation

34.5.1. - an example that illustrates animating the positioning of the browser window

34.6.1. - an example that demonstrates fading of many different CSS style properties

34.9.1. - form elements

34.10.1. - dynamic options, with more elaborate HTML

34.14.1. Widget Adoption by Page Widget

Uize.Validator

Uize.Widget.FormElement

36.1.1. - Firefox

36.1.2. - for IE