0N/AWidget is the foundation class from which all YUI 3 widgets are derived.
0N/AIt provides the following pieces of core functionality:
0N/A* The render lifecycle method, in addition to the init and destroy
0N/A lifecycle methods provided by Base
0N/A* Abstract rendering methods to support a consistent MVC structure across
0N/A* A common set of base widget attributes
0N/A* Consistent class-name generation support
0N/A* "render" event now published with the defaultTargetOnly set to true.
0N/A to let developers define their own CSS PREFIX instead of
1472N/A* Changed default value for the tabIndex attribute to null, meaning by default
0N/A a Widget's bounding box will not be a focusable element.
0N/A* Widget now has built-in support for Progressive Enhancement.
0N/A 1) The document element (HTML) is now stamped with a class name
0N/A (yui-js-enabled) indicating that JS is enabled allowing for the
0N/A creation of JS-aware Widget CSS style rules for Progressive Enhancement.
0N/A 2) Widget has support for a class name representing the "loading"
0N/A state that can be used in combination with the "yui-js-enabled" class name
0N/A to create style rules for widgets that are in the process of loading.
0N/A There is support for use of both a generic Widget and type-specific
0N/A Widget class name by default (for example: "yui-widget-loading" and
0N/A "yui-tabview-loading").
0N/A 3) Widget's renderer will remove the "loading" class names from the
0N/A bounding box allowing the fully rendered and functional widget to be
0N/A Developer Usage / Requirements
0N/A - Developers can take advantage of the system by following two steps:
0N/A 1) Simply stamping the bounding box of their widgets with the
0N/A corresponding "loading" state class name. The idea being that the markup
0N/A for this widget is already on the page, and the JS components required
0N/A 2) Providing the definition of the loading style for the widget(s).
0N/A to render to parentNodes which are document fragments. If rendering to
0N/A a document fragment, the implementation is responsible for adding the
0N/A document fragment to the document during the render lifecycle phase.
0N/A* Split widget module into the following sub-modules
0N/A - widget-base : Core lifecycle and API support.
0N/A - widget-htmlparser : HTML parser support.
0N/A The "widget" module, is a roll up of the widget-base and widget-htmlparser
0N/A The widget-locale is a standalone module, which contains the deprecated
0N/A Internationalization support and has been replaced by the
Y.Intl language
0N/A pack support, to allow strings to be defined separately from code.
0N/A* Removed moveStyles support for 3.1. Can be re-added if required, but
0N/A currently does not seem to be in use.
0N/A* Made render event fireOnce (along with init and destroy in Base)
0N/A* Widget will now fire user-generated events like DOM elements do (
e.g. 0N/A 'click', 'mouseover'). Like all other Widget events, these events are
0N/A prefixed with the Widget name (
e.g. 'menuitem:click') and the default
0N/A context of the event listener will be the Widget that fired the event.
0N/A 1) Provide developers with the ability to listen for UI events as though the
0N/A Widget is an atomic element, as opposed to DOM events that will bubble up
0N/A through all of the elements that compose a Widget's UI.
0N/A 2) These are events that many Widget instances are going to want to publish
0N/A and fire, so Widget does this by default to ensure that these events are
0N/A fired in a performant, consistent way across Widget implementations.
0N/A 1) Widget developers don't have to explicitly publish a given UI event in
0N/A order for Widget consumers to listen for them. By default UI events are
0N/A only published and fired if someone is listening for them.
0N/A 2) Widget developers can choose to publish a given UI event in order to
0N/A explicitly control some aspect of the event. The most likely use case
0N/A event. For example: a developer might want to publish a click event
0N/A for a Menu Widget with the goal of providing the default click
0N/A the preventDefault() method.)
0N/A 3) The set of user-generated events published by widget is defined by the
0N/A UI_EVENTS prototype property. Widget developers can use this property
0N/A to pair down or extend the number of events that are published and
0N/A fired automatically.
0N/A 4) For performance, these events are only created when someone is
0N/A listening, and the actual firing of these events is facilitated by a
0N/A single, delegated DOM event listener.
0N/A* content box now expands to fill bounding box. CSS is used for browsers
0N/A which support box-sizing:border-box. Expansion is handled programmatically
0N/A for others (currently IE6 & IE7). Maybe some edge cases which need
0N/A* Added an "id" attribute.
0N/A* Added support for auto-rendering of widgets at the end of construction,
0N/A using the "render" attribute.
0N/A* Added support for single-box widgets (contentBox and boundingBox can
0N/A point to same node).
0N/A Widget developers can set CONTENT_TEMPLATE to null if they have a
0N/A widget which doesn't need dual-box support.
0N/A* Added _bindAttrUI and _syncAttrUI sugar methods, to bind after listeners
0N/A and sync methods, by attribute name.
0N/A* The widget's bounding box is now removed from the DOM and destroyed
0N/A when the widget it destroyed.
0N/A* Added "srcNode" attribute, which acts as the root for HTML_PARSER.
0N/A This allows widgets to support progressive enhancement, without having
0N/A to put the burden on the user to create and point to bounding boxes,
0N/A* Added protected _getSrcNode and _applyParsedConfig methods to allow for
0N/A HTML_PARSER customization, by allowing Widget developers to customize
0N/A the node passed into _parseNode on the input side, and the final merged
0N/A configuration on the output side of the srcNode parsing process.
0N/A The default Widget _getSrcNode implementation uses "srcNode" if set,
0N/A otherwise falls back to "contentBox", for 3.0.0 compatibility.
0N/A The default Widget _applyParsedConfig implementation aggregates the user
0N/A configuration literal, with the configuration output from parsed node,
0N/A with the user configuration taking precedence.
0N/ANOTE: All HTML_PARSER related changes are backward compatible.
0N/AExisting Widget implementations should still work. However HTML_PARSER
0N/Aimplementations based on contentBox being the root node should be
0N/Amodified to work off of srcNode before the 3.1.0 release.
0N/A* PluginHost moved down to Base.
0N/A* Render event args added to event facade instead of being passed
0N/A* "hasFocus" attribute renamed to "focused"
0N/A* "focused" attribute is read only
0N/A* "focused" attribute is set via:
0N/A - the "focus" and "blur" methods
0N/A* Only one DOM focus event handler is used now (two for WebKit) and it is
0N/A bound to the widget's ownerDocument. This allows modal widgets to maintain
0N/A a reference to the element in the document that previously had focus and
0N/A to be able to restore that focus when the modal widget is hidden.
0N/A* "tabIndex" attribute was updated
0N/A - accepts a number or null
0N/A - more documentation
0N/A3.0.0PR2 - Initial release