readme

很棒的在线教学系统

  When rendering to any other element on the page, the behavior is 
  unchanged and both the container and shim are appended as the last 
  children of the element.

  Upgrade Impact For Containers Rendered To Document.Body
  -------------------------------------------------------
  If you have an xy coordinate and non-zero z-index specified for 
  your container there should be no negative impact.
  
  If you haven't specified an xy position, the fix could result
  in a shift in your container position, depending on other elements
  on the page.

  If you haven't specified a z-index and are relying on DOM order to 
  stack the container, you may see a change in stacking order of 
  the container or iframe shim.

  Both these changes can be resolved by setting a specific z-index
  and position based on the layout of other elements on your page.
  
  If you do need to revert to 2.3.0 behavior, a configuration property
  "appendtodocumentbody" has been added to Module, which can be set to
  true.

  The change to stacking order is discussed in detail below in 
  relation to other z-index fixes made for 2.3.1.

+ Z-index is now applied correctly for Overlay/Panel elements, their 
  corresponding iframe shims, and modal masks (for Panels).
  This fix applies to both the default z-index based on the CSS 
  for the Overlay/Panel and specific z-indices set using the 
  "zindex" configuration parameter.

  Default z-index values are:

     Overlay/Panel element: 2
     Iframe shim: 1
     Mask: 1
  
  The iframe shim and modal mask z-index will always be set to one less
  than the Overlay/Panel z-index.

  PLEASE NOTE:
  
  As a result of the fix to reduce "Operation Aborted" errors,
  setting a z-index of 1 on an Overlay/Panel rendered to document.body 
  will result in its iframe shim and modal mask (which will have a 
  z-index of 0) being rendered behind other positioned elements in the 
  document.

  This is because the Overlay/Panel, iframe shim and mask are 
  inserted as the first children of the BODY element and hence any 
  positioned elements with a z-index of 0 or auto which occur after 
  them in the document will be stacked on top of them as per W3C spec.

  If you need to keep the Overlay/Panel above positioned elements on your 
  page, it's z-index needs to be set to 2 or more.

  In general it's advisable to manage the z-index of positioned elements 
  on your page deliberately by setting a z-index, to avoid having their 
  order in the document define their stacking order.
  
  For detailed stacking order information see:
  - http://www.w3.org/TR/CSS21/visuren.html#layers
  - http://developer.mozilla.org/en/docs/Understanding_CSS_z-index:The_st
    acking_context

+ Module now correctly recognizes standard module header, body and footer 
  DIVs when they have extra CSS classes applied in addition to the 
  required hd, bd, and ft classes. e.g. <div class="bd news"></div>.

+ An empty header (set to $#160;) is created for draggable Panels which
  don't have a header specified, to provide a drag handle. This fixes a
  regression introduced in 2.3.0 so that 2.2.2 behavior is restored.
  
+ Dialog.destroy has been fixed to account for Dialog form elements which 
  may not be direct children of the standard module body ("bd") element.

+ SimpleDialog.destory now completes successfully if the optional 
  button-beta.js dependancy is not included on the page.
  
+ Destroying Overlays registered with the OverlayManager no longer results in a 
  JavaScript error. The Overlay is destroyed and removed from the 
  OverlayManager correctly.
  
+ Submitting a Dialog form directly (e.g. using a "submit" button, hitting
  enter on a single text field form) no longer throws a JavaScript error.

Known Issues
------------

+ IE: Borders for tables with border-collapse:collapse remain visible
  -------------------------------------------------------------------
  If an Overlay, or any of its subclasses, contains a table with its
  border-collapse CSS property set to "collapse" instead of the default 
  value of "separate", the borders of the table will remain visible, when 
  the Overlay is configured to be hidden initially. The table contents 
  will be hidden correctly.
  
  This is due to an IE bug, reproducible by the basic test case below:
  
     <style type="text/css">
        .box  {visibility:hidden;}
        td    {border:1px solid red;}
        table {border-collapse:collapse;}
     </style>

     <div class="box">
        <table>
           <tr>
               <td>1</td>
               <td>2</td>
           </tr>
        </table>
     </div>

  Setting the DIV elements "style.visibility" JS property fixes the 
  problem with the simple test case. NOTE: Setting the style in markup 
  using the DIV's style attribute does not.

  Extending this to Container, the simplest workaround if you're not 
  using effects, is to use Overlay's hide() method to setup visibility. 
  This will set the Overlay's element "style.visibility" property. e.g.

      // Start visible, then hide.
      var ovr = YAHOO.widget.Overlay("ovr");
      ovr.render();
      ovr.hide();
      
  You can also apply this workaround if you want to use effects by 
  setting the effect up after you hide. e.g.
  
      // Start visible, but don't apply effects, 
      // to avoid initial animation.
      var ovr = YAHOO.widget.Overlay("ovr");
      ovr.render();
      ovr.hide();
      ovr.cfg.setProperty("effect", {effect:.....});

  If initial flicker is a problem with the above, you can set the 
  visibility directly on the Overlay element after rendering e.g.

      var ovr = YAHOO.widget.Overlay("ovr", {visible:false});
      ovr.render();
      YAHOO.util.Dom.setStyle(ovr.element, "visibility", "hidden");

  but if possible one of the previous methods should be used since 
  they use the public API as opposed to manipulating the DOM directly.

*** version 2.3.0 ***

Fixed the following bugs:
-------------------------

+ Improved creation of the <iframe> element used to monitor changes to the 
  browser's font size so that:
  
    - Safari's status bar no longer displays a "Loading..." message after the 
      page has loaded.
  
    - Firefox no longer reports duplicate cookie information.
    
    - The browser scrollbars no longer flash on and off in Firefox.

+ It is now possible to set the "button" configuration property of a 
  YAHOO.widget.Dialog instance after it has be rendered.

+ Form elements appended to a YAHOO.widget.Dialog instance via the "setBody"
  method are now automatically registered using the "registerForm" method.

+ The "focusFirst" method of YAHOO.widget.Dialog will no longer result in a 
  JavaScript error in IE if the first element in the Dialog instance's form
  is a radio button.

+ YAHOO.widget.Panel instances whose "draggable" property is set to "true" and
  "width" property is set to "auto" are now able to be dragged in IE 6 (Quirks
  and Strict Mode) and IE 7 Quirks Mode.

+ Updated focus methods of YAHOO.widget.Dialog to prevent JavaScript errors 
  that result from trying to set focus to elements that hidden or disabled.

+ Pressing the enter key will no longer result in a YAHOO.widget.Dialog 
  instance's "validate" method being called twice.

+ Pressing the enter key while focused on a form field inside a Dialog will no
  longer trigger the "click" event handler defined by the Dialog's default 
  button in IE and Firefox.

+ Pressing the enter key when focused on a form field inside a 
  YAHOO.widget.Dialog instance with no buttons created via its "buttons" 
  configuration property will no longer result in a JavaScript error.

+ Aqua scrollbars will no longer bleed through Container widgets in Firefox
  for Mac OS X.

+ The "width" and "height" configuration properties of YAHOO.widget.Overlay
  now supersede the "fixedcenter" and "context" configuration properties to 
  ensure correct positioning of Overlay instances using the "fixedcenter" 
  and "context" configuration properties.

+ Calling the "destroy" method on a YAHOO.widget.Overlay instance no longer 
  results in a JavaScript error on the subsequent focus of another 
  Overlay instance.

+ YAHOO.widget.Tooltip instances without a value specified for the "width" 
  configuration property will be rendered at a width equal to the offsetWidth
  of their root <DIV/> element to prevent their width from being clipped or 
  constrained by their parent HTML element.


Changes:
--------

+ Rendering of YAHOO.widget.Tooltip instances is now deferred using the 
  "onDOMReady" event handler of YAHOO.util.Event rather than waiting until 
  the "load" event of the Tooltip's parent window fires.

+ Deprecated "browser" property of YAHOO.widget.Module in favor 
  of YAHOO.env.ua.

+ The "moveEvent" of a YAHOO.widget.Panel instance now also fires with the 
  "endDrag" event of the its YAHOO.util.DD instance.

+ Updated modal functionality of YAHOO.widget.Panel:
    
    - The creation of a Panel instance's modality mask is now deferred until it
      is initially made visible.

    - Showing a modal Panel instance will now result in the Panel and its 
      associated modality mask element having a higher z-index than all other
      YAHOO.widget.Overlay instances and Overlay subclasses.

+ Updated the "underlay" configuration property of YAHOO.widget.Panel:

    - The creation of the underlay element is deferred until the Panel
      instance is initially made visible.

    - For Gecko-based browsers on Mac OS X the underlay elment is always 
      created as it is used as a shim to prevent Aqua scrollbars below a Panel 
      instance from poking through it.

    - For IE 7 (Quirks Mode) and IE 6 (Quirks Mode and Standard Mode) the 
      underlay element is resized in response to a change to a Panel instance's 
      "width" or "height" configuration properties, a change to the browser's 
      font size or the firing of the contentChangedEvent (triggered by use of  
      the "setHeader," "appendToHeader," "setBody," "appendToBody," 
      "setFooter," or "appendToFooter" methods). 

+ Updated the "iframe" configuration property of YAHOO.widget.Overlay:

    - The creation of the <iframe> shim element is deferred until the Overlay
      instance is initially made visible.

    - The <iframe> shim element is resized when a change to an Overlay 
      instance's content is made at runtime via the "setHeader," 
      "appendToHeader," "setBody," "appendToBody," "setFooter," or 
      "appendToFooter" methods.

+ Updated the "buttons" configuration property of YAHOO.widget.Dialog:

    - YAHOO.widget.Button is now an optional dependancy, and if included, each
      button in a Dialog will be an instance of Button.

    - The "text" property of each button now accepts HTML
    
    - The "handler" property of each button can now be set to:
    
        + A reference to a function that should fire when the button is 
          clicked.  (In this case scope of this function is always its 
          Dialog instance.)

        + An object literal representing the code to be executed when the 
          button is clicked.  The format is:  
          {
            fn: Function (The handler to call when the event fires.),
            obj: Object (An object to pass back to the handler.),
            scope: Object (The object to use for the scope of the handler.)
          }   


Added the following features:
-----------------------------