Results 1 to 13 of 13
Thread: Hawk - a site framework
Sep 15, 2003, 11:48 #1
- Join Date
- Dec 2002
- Alabama, USA
- 0 Post(s)
- 0 Thread(s)
Hawk - a site framework
Hawk is a downgradable DHTML site framework with layout and menu managers.
This is a beta release and the documentation still needs much work.
I'd like to get your opinions and suggestions. If you have a little time to answer some of the following questions I would really appreciate it.
1. I've been testing on Win98 with Opera7.11, Mozilla1.4, and IE6.0. How does it work on different browsers and different operating systems?
3. The file structure is an essential part of this framework. Basically, for each page there can be separate files with the following relations (some are optional): site content, site style, site behavior, page content, page style, page behavior, and the page's main xhtml file itself. At first this seems excessive - but I think having this built into the framework may help to keep everything separated properly. It should also help to keep things abstracted into single reusable files instead of, for example, menu xhtml being duplicated in different files. What are your thoughts on this file structure idea? I know it's nothing new - it's just my latest toy ;-)
1. The closing of a box is not controlled by a timeout - it is controlled by how far away from the box the mouse is. Labels are the same - you're not off a label until you exceed a certain distance. How do you like this as compared to the timeout technique?
2. The menus float onscroll (this is optional) - but only after a certain time has completely elapsed after the last scroll. The horizontal menu disappears on the first scroll and reappears after the timeout. How do you like this technique (of course it could be tweaked) compared to floating immediately onscroll?
3. The menu automatically places a box to the right/left or bottom/top of its label depending on whether or not the box would fall off-screen. The algorithm favors right and bottom. This makes for a different type of 'cascade' when the menu is close to the window's right edge. The horizontal menu on this page is an example. What do you think of this? Perhaps the algo should favor right when the menu is positioned on the left, and favor left when it's positioned on the right, etc. Is it worth adding more code?
4. Properties are added to the menu box elements to create a multi-way tree. And there's a function provided for pre-order traversal. So it's easy to add new paint iterators to xMenu. The current paint method will draw a horizontal or vertical cascading style menu. I'm thinking of adding one which will draw the menu as a tree structure or collapsible list. Would this be useful? Is it worth the effort?
1. Resize the window to several different widths. Do the elements seem to get resized and repositioned properly? The algo allows you to specify a min and max width. When the window is less than minWidth, xBody (the columns' container) is given minWidth. When the window is greater than maxWidth, xBody is given maxWidth. When the window is between minWidth and maxWidth, xBody is given that width. Centering is optional.
2. Do you have a different width-determination idea? Perhaps based on a percentage of the window width?
3. xDocument supports any number of columns and allows you to specify the width of each column in pixels. One column can be specified with zero width - this column's width will get auto-calculated based on the combined width of the other columns, margins, etc. Do you like this? Would you prefer being able to specify the column widths in percentages of xBody width?