dojo commits

RevisionAuthorDateDescription
16241peller06 Jan 2009 16:16:36

Remove unneeded call to str.trim(). Refs #8182

16240elazutkin06 Jan 2009 15:41:46

Reducing the code by several bytes and improving the load time a little, !strict, refs #8182.

16239elazutkin06 Jan 2009 15:34:53

Restructuring dojo.trim() and dojo.string.trim() to make a choice (native
vs. manual) only once during the loading time. !strict. Fixes #8182.

16238peller06 Jan 2009 15:06:07

Update docs to indicate native String.trim() is used. Refs #8182

16237liucougar06 Jan 2009 14:54:05

refs #4634:
added an extra span within MenuBarItem so that disabled item should up
properly
don't open a disabled item's popup when changing focus from an item with
popup opened
added a disabled MenuBarItem to test page

16236peller06 Jan 2009 14:34:49

Try to be more standards-compliant. top:auto seems to work for spinner. Refs #8332

16235bill06 Jan 2009 10:21:51

Missing parameter to pasteItem() call, fixes #8354 !strict.

16234bill06 Jan 2009 10:18:46

IE doesn't like negative padding, even on a hidden node.
Fixes #8359 !strict.

16233bill06 Jan 2009 07:40:56

Defer focusing on a static Menu/MenuBar until user clicks it, or tabs into it. Once user clicks on a Menu/MenuBar, it focuses on it, and then (as before) any mouse movement or keyboard movement (via arrow keys) will change focus. Also (as before), focus is shifted to a context menu immediately when it's displayed.

Separated out CSS classes for indicating that a MenuItem is mouse hovered (dijitMenuItemHover), and to indicate which MenuItem is selected/active (dijitMenuItemSelected). Currently they look exactly the same, although that could be changed (including removing the hover effect altogether).

"Selected/active" is in the sense of the selected tab, and is controlled by the mouse or keyboard. Implementation-wise, it means that either the MenuItem has focus, or focus is on a submenu of that MenuItem.

Also added dijitMenuPassive/dijitMenuActive class to the Menu/MenuBar domNode so that CSS rules for hover can be customized based on whether or not the menu has focus. Once the menu gets focus the dijitMenuHover effect is disabled in favor of the dijitMenuSelected effect, so that the dijitMenuHover effect won't linger on "File" if user moved the mouse over "File" but then used the keyboard arrows to move to the "Edit" MenuBarItem. (This is a setting in tundra/nihilo/soria and can be changed if desired.)

Open issue with re-focus on click-execute of a leaf menu item... after executing a menu choice focus ends up nowhere (or maybe on the page itself). Probably should be going to the menubar?

Refs #4634 !strict

16232alex06 Jan 2009 01:46:24

some size reductions. Also (finally) enables the QSA branch. Not sure how I missed that.

Refs #7072. Refs #4425. !strict

16231peller05 Jan 2009 21:47:33

Use native String.trim() where available. Fixes #8182

16230elazutkin05 Jan 2009 20:23:09

Adding dojo.toDom() with unit tests, the code by James Burke (thank you!)
with minor optimizations, and an extra argument to specify the document
explicitly, !strict, refs #7890.

16229alex05 Jan 2009 19:57:59

fixing regression in XML tests related to tag name case sensitivity. Fixes #8356. !strict