the present invention has many applications , as will be apparent after reading this disclosure . in describing an embodiment of a browser interface system according to the present invention , only a few of the possible variations are described . other applications and variations will be apparent to one of ordinary skill in the art , so the invention should not be construed as narrowly as the examples , but rather in accordance with the appended claims . embodiments of the invention will now be described , by way of example , not limitation . it is to be understood that the invention is of broad utility and may be used in many different contexts . the example of a browser session is a user at a user location operating a user computer to control a browser , which is typically software running on a general purpose user computer , but might be another device , such as a dedicated hardware browser or firmware operated by a portable device . the browser sends requests over a network for pages or portions of pages and displays received pages or portions of pages . the browser might also maintain local data storage for cookies , cached pages , scripts , code and the like . typically , the browser requests are directed over the network to page servers , such as http ( hypertext transport protocol ) servers ( also called “ web servers ” as the pages served are often considered part of the world wide web of hyperlinked documents ). the user can be a human or a machine , but is more often a human user . a “ page ” might be a conventional html page returned in response to a browser request , which can be a pre - existing page or a page generated in response to the request . the page might contain display portions , formatting portions and executable portions . as used herein , the term page might refer to html pages , messages , data blocks , packets , or other structured or unstructured data units that are considered logic units in a page request system . referring now to the figures , an exemplary browsing system will now be described . fig1 is a block diagram of a system 100 according to embodiments of the present invention . using system 100 , a user can operate a client system 102 running a browser to send requests 104 for pages and receive responses 106 to those requests from servers 108 . responses 106 are typically pages , but under error conditions , such as when a page does not exist , a request is malformed , a server is not available or the requesting user does not have access authority , response 106 might be an error message or an error page . fig1 shows only one client and one server , but it should be understood that the typical system might have many clients and many servers . as shown , server 108 is a separated from client system 102 by a network 110 , in this case a global internetwork of networks known as the “ internet ”. the bandwidth and responsiveness of a client — the server path through network 110 can sometimes diminish the browsing experience . since the typical browsing system can handle the necessary computing tasks quickly , the network and / or servers are more typically the cause of bottlenecks and slowdowns . however , by using some of the techniques described herein , a browsing system can make requests and a server can respond with pages having features that can provide responsiveness to the user even in the face of network slowdowns . fig2 is a swim diagram illustrating actions and flows between a client ( such as the user &# 39 ; s browser ) and a server , wherein each communicates using a protocol such as http and / or its extensions . the steps executed by the client or server are labelled in the order shown with labels “ s 1 ”, “ s 2 ”, “ s 3 ”, etc . other steps , not shown , might also be performed and not all of the labelled steps need be performed . once the user initiates an instance of the browser ( s 1 ), the browser can accept input from the user . in this example , the user has requested the page identified by the url ( uniform resource locator ) “ http :// plus . yahoo . com / index . html ” and the browsers gets this request from the user ( s 2 ). the browser can get the request by the user typing in the url , selecting from a bookmark list , clicking on a link of a displayed page or other method . the browser then sends an http request to the server identified with the domain portion of the url of the request ( i . e ., “ plus . yahoo . com ” in this example ). once the server receives the request ( s 3 ), it retrieves the page ( s 4 ) and sends it to the requesting browser ( s 5 ). the page might contain html data , such as page text , formatting and the like , but would also contain dynamic elements . one standard for such dynamic elements is the dhtml ( dynamic hypertext markup language ) standard . once the browser receives the page ( s 6 ), the browser processes the page ( s 7 ) and displays the selected layers to the user ( s 8 ). with the selected layers of the dhtml pages displayed , the user might then select an element on the display to cause an action . some selection might be done by positioning a cursor over an element , while other selection might also include indicating a selection such as by pressing a mouse button with the cursor over an element . of course , to the browser , the happenstance presence of a cursor somewhere on the display can be treated as a positioning selection , so that the action taken by positioning a cursor might be taken even if the user did not change the position of the cursor as would normally be expected for what is understood as “ selecting ”. however a selection action or event is noted , the browser detects or interprets user input ( s 9 ) and then takes an action for that selection based on the dhtml code for the element selected ( s 10 ). examples of pages and elements are described below . while dhtml has been in use for presenting content and positioning content , examples shown below provide for tools with interface elements ( e . g ., buttons , forms ) on layers and / or uses of layers for interfacing . fig3 illustrates a portion of a page 300 with dynamic interface elements . page 300 is passed to a browser as a dhtml page , with all the components needed for the interface included in the dhtml page . this allows the browser to respond to user actions without requiring another request to be sent to a server , possibly delaying the response . as shown there , a “ slide sheet ” 301 for advanced searching descends from a search toolbar when activated , either by the user selecting the “ advanced search ” button or merely rolling a cursor over the button . with the advanced search slide sheet , the user can perform advanced searches without appearing to move away from a current page being displayed , as the search toolbar could be part of the currently displayed page , with opening the slide sheet only obscuring a part of that displayed page . the dhtml “ advanced search ” link can be represented by a text element 302 or a graphical element , possibly providing a consistent visual language to denote such dynamic links . when a user has not selected the advanced search , the slide sheet remains hidden and when selected , appears to slide down from behind the toolbar . the slide sheet can contain various advanced search option elements . a tabular navigation system can be used within the slide sheet if advanced options need to be separated into sections . depending on the display real estate available for the slide sheet and the number of elements to be presented , the slide sheet might also include scroll elements to allow for scrolling of the elements within the real estate allotted . in some implementations , the slide sheet could be vertically expandable so that the user can control the real estate used , possibly obviating the need for the scroll bar . within the slide sheet shown , a “ search ” button 306 is provided that might initiate an action that works the same way , or in a similar way , as a “ search ” button 308 provided in the search toolbar and usable even when slide sheet 301 is hidden . the user can close slide sheet 301 by completing a search , clicking on either search button , clicking outside the slide sheet , clicking the “ advanced search ” element 302 again or by clicking the “ x ” close window icon on the top right corner of slide sheet 301 . such a search slide sheet might be used in various areas of a portal site , such as a main page , a music page , a movies page , a games page , a sports page , a local new / information page and / or a news page . a finance page might incorporate a similar tool for functions such as ticker look up . if each of those pages has different search elements , the side sheets can be different for different pages . the selections made by the user on the slide sheet , or other dynamic interface element , can be stored at the client system and conveyed to the server that sent the page ( or other designated server ) asynchronously or synchronously ( blocking ). for example , one server might provide a page to a browser that designates a second server as the server to collect user input collected from a dynamic interface element . preferably , if a delay is possible all , the client system might take an action based on user input on a dynamic interface element even before a server receives the collected user input , in some cases , a user might request a page having such dhtml elements , but not nave a browser capable of processing dhtml constructs . in such cases , the dhtml page would be configured to substitute other functionality . for example , when a user with a non - enabled browser selects advanced search element 302 , they would be directed to an html page for advanced search , typically taking the user away from the page containing the element . in another instance , dynamic content delivery is provided within a page using dynamic interface elements , thus allowing the user to remain with a page and see additional elements . an example of such a dynamic content delivery construct is shown in fig4 . with such a construct , a number of summaries of items are shown , with one of the items shown . in this example , the items are news stories and the summaries are headlines , but other types of items are possible . dynamic layer 400 is used for display of an item 402 and summaries 404 for that item and other items . the summary corresponding to the display item , summary 406 in this case , is shown with a visual cue 408 , thus allowing the user to quickly identify which headline is being shown in greater detail above . if the displayed item has associated images or video , or other media , it can be displayed in area 410 . depending on the selection and / or cursor position , the browser might ( according to instructions in the page provided by a server ) transition automatically through each of the items , showing it in turn and stopping when the user selects a specific item , either by clicking on the item , clicking on the summary , moving the cursor to the summary , or taking another indicative action . this content delivery mechanism might be found on main pages within properties of a portal web site . in a main news page , top and featured stories can be dynamically rotated in order to serve up more information to the user . the user is able to interrupt the rotation by directly selecting a particular top story from a short list featured on the page , or maybe by just moving the cursor into an item display area or holding down a key . to get the full story ( more than just the item shown , in most cases ), the user can select the item or the headline . the automatic transitioning between items can be done in a number of ways . for example , the browser could rotate through the items , fading out one and fading in another . one way to do this is to have the current item in one layer , the next item on another layer , with the next item &# 39 ; s layer being transparent and on top of the current layer and gradually increase the opacity of the next item &# 39 ; s layer . alternatively , the current layer might be opaque and on top with that layer gradually becoming more transparent . in some cases , where the items contain media that take time to display , the rotation of a current item out and a next item in might be tied to when the current item is done displaying , such as beginning the transition shortly after the current item is done playing . where controls are provided to control the playing of media , such as rewind , pause and fast forward , the user might control when the rotation occurs . in any case , the browser should delay enough to allow for comfortable reading of the text presented and present a visual and / or audio cue that a transition is to begin . when the display transitions from one item to another , the visual cues , such as visual cue 408 would change to the now current item . the order of rotation can be random or defined by some set of rules , but an expected order might be from top to bottom , repeating the top item when the bottom item is rotated out . the list of item summaries ( and thus the items ) might be sorted at the server by importance or interest . in addition to the rotated in items and their summaries , dynamic layer 400 might also provide links such as “ more top stories ” and “ see related stories ” that take the user away from the current page to new pages , as with conventional links . other cues might be provided to the user . for example , a cue might be provided when a user rolls a cursor over the highlighted story to indicate that the rotation is paused . to avoid jarring actions , the browser ( again controlled by instructions from the page ) might delay action on a roll over for a few seconds and then perform a smooth transition . since each of the transitions between items and navigation among elements of dynamic layer 400 can be handled by the browser without reference to a server , the user interaction can happen quickly without concern for network activity or bottlenecks . if statistic information on views is needed , the page can collect status messages and send those to the server ( useful for determining which items are of interest over a large audience and which are not ), but such server interaction does not delay the display experience . such a dynamic layer page might be used in various areas of a portal site , such as a main page , a music page , a movies page , a games page , a sports page , a local new / information page and / or a news page . in some cases , a user might request a page having such dhtml elements , but not have a browser capable of processing dhtml constructs . in such cases , the dhtml page would be configured to substitute other functionality . for example , a user with a non - enabled browser might be presented with the items and summaries , but have to select a summary to view the item . where the item includes a video object , that object can be presented directly , via a plug - in or the like , in one of the layers . with the video handled directly , opening an external player is not needed , thus making the pages more flexible . for example , the area allocated to the video could be automatically adjusted based on a detected aspect ratio , and the area can be expanded or contracted by the user without requiring a reload of the video stream . another example of a use of dynamic pages is shown in fig5 . there , a tool layer 500 is shown . tool layer 500 allows users to perform popular activities and / or actions without leaving a page of focus . tool layer 500 includes buttons , such as buttons 502 that react in some ways when they are rolled over to indicate their rich dynamic functionality , such as highlighting and a tool tip after a delay . the page includes dhtml layer ( s ) with all the necessary interactive elements for the user to complete the activity or action , typically without requiring communication with the server . for a wizard - like activity or tour , this module can be self - contained and close upon completion , with the user inputs recorded at the client system , being transmitted to a server as needed . when a tool is selected , by a click or otherwise , the user is presented with a dhtml layer ( preferably , through a consistent visual transition ) wherein the interactive elements necessary to complete the task are contained . links contained within this module typically pop up another browser window . such tool layers can be used in a number of ways . for example , a main portal page might include a tool button for sending an e - mail . in response , the browser could present a new layer for entry of the e - mail , without the user perceiving any direction away from the main portal page . furthermore , since the e - mail layer is part of the page already at the browser , the opening of the layer and the restoring of the main page will not be delayed by network or server delays . other uses might include website services for quickly uploading files , calendar updates , photo uploading , searches , yellow page inquiries , etc . for a layer such as an e - mail layer , the portion used for entry of the e - mail can be semitransparent , to keep the user oriented with the page from which the e - mail function was selected . this will often result in a less disorienting , cleaner presentation . fading can be provided as well . to accommodate browsers without dynamic page or dhtml capability , the server could detect , by “ sniffing ” or otherwise , whether a browser is enabled and then serve up the dynamic page or fall back to a separate page without the tool capability . in addition to dynamic pages that include user interface elements , such as buttons and forms , some dynamic pages might operate without such elements . for example , fig6 shows the use of layers for subnavigation . one implementation of subnavigation layers is using a dhtml pop - up that reveals the subsections and / or subcategories of main menu items . the submenus can be revealed when the user rolls over links on the main menu . if the main menu does not have an apparent set of subnavigation items , this layer might be used to describe the menu item and / or provide quick links to popular subsections within that item . in some systems , to keep the interaction simple , the selected menu item is highlighted when selected and a limited number of sublevels ( such as one sublayer ) are used . in the example of fig6 , when the user rolls over a top level menu , the subsection dhtml menu or description will appear on the right side . the dhtml submenu should remain open as long as the cursor remains in the main menu item selected or in the dhtml submenu itself , but dhtml submenus disappear when user rolls away from the selected item or the dhtml menu itself . such layers might be used in various areas of a portal site , such as a main page , a music page , a movies page , a games page , a sports page , a local new / information page and / or a news page . in some cases , a user might request a page having such dhtml elements , but not have a browser capable of processing dhtml constructs . in such cases , the dhtml page would be configured to substitute other functionality , such as showing the submenu items beneath menu items in a flattened , indented menu and , for menu items that do not have subsections , take the user to the page itself when the link is clicked . some pages can be complex combinations of constructs described above . for example , fig7 shows a “& amp ; personal assistant ” set of layers for performing tasks specific to the user . in some cases , the dynamic ( dhtml or other protocol ) page used can be cached by the user so that the servers do not have to repeatedly send a user &# 39 ; s page to the user , for thousands or millions of users . this can be so even if the content of the page were to change as the cached page could include placeholders for information that is retrieved from a server each time the page is used , even if the page itself is not retrieved each time . with the personal assistant set of layers , an “ assistant ” module within certain properties is provided where content , tools , features and promotions are presented up front based on the user &# 39 ; s preferences , which can be managed actively or passively . the customization might comprise event alerts ( i . e ., auctions results , concert tickets going on sale , etc . ), information alerts ( news , finance ), promotions ( new product release ) or personal information ( bills due , etc .). preferably , the list is limited to some number ( such as 10 ) entries to avoid clutter and has links that lead to the items themselves . for example , an “ edit ” link allows the user to edit their preferences on a separate page . tins separate page will contain explicit items and preferences the user chooses , permission for promotional items to be featured , permission for passive personalization to be used , promotion or news of upcoming personalization features , etc . a “ more ” link might reveal additional personalization items through a vertically expandable dhtml slide sheet if the module cannot initially contain all items . if the user has not personalized their module , it will contain promotion , instruction , or tour for the assistant module . when the assistant is personalized , it will contain a finite list of items actively or passively customized to the user &# 39 ; s preferences . the items listed might contain links , which when clicked will allow users to interact further with that specific item . if the module cannot fully contain all the personalization items , a “ more ” link will be provided , which when clicked , will present a sliding sheet to reveal the rest of the list . preferences may contain actively customizing the types of alerts or content the module presents and filters , it may also include color customization , graphical element and other personalization features . such layers might be used in various areas of a portal site , such as a main page , a music page , a movies page , a games page , a sports page , a local new / information page and / or a news page . in some cases , a user might request a page having such dhtml elements , but not have a browser capable of processing dhtml constructs . in such cases , the dhtml page would be configured to substitute other functionality , such as sending the user to a separate page listing all the items when they click on “ more ”. yet another dynamic page is illustrated in fig8 . there , a premium promotional module is shown , which rotates among a series of promotional or informational items , using a consistent and unobtrusive animated transition . the items appear in one of a plurality of spaces , and the items might transition from spaces in a staggered schedule so that they to not all transition at once . by way of example , a top page of a portal web site might contain a promotional module . the transition might be consistent with other transitions of other dynamic pages , such as an animation , fade in , box in , etc . the rotation can occur even if the user is idle , preferably being unobtrusive and consistent throughout the module . if the user rolls over a particular space , the rotation for that space will be paused , with rotation resuming when the user rolls away from the module or space . links within the modules will act like regular links . users with non - dhtml enabled browsers can be provided with such a set of spaces , but the rotation will likely not be present . one underlying architecture that could be used to present features described above is to have separate tools on layers of a dhtml page and move the layers by changing their position , thus obviating the need for a page refresh . where some of the changes should be sticky , such as when the user drags one layer to a new position or changes positions of layers relative to each other , the change could be done without refreshing the page from the server , by the changes might be communicated to the server so that the next time the user comes to that page , the layers are in the order the user put them in at the last visit . in effect , this allows the user to drag and drop portions of a portal page layout , for example , and see them move relative to each other at speeds that might not be possible given network and / or server conditions . the communication of the change can be sent to the server without blocking the movement at the user &# 39 ; s machine . in addition to communicating changes , references that a user makes , such as navigating a submenu or selecting an item for further detail , can be communicated to the server even though server action is not needed to respond to the user &# 39 ; s action . the above description is illustrative and not restrictive . many variations of the invention will become apparent to those of skill in the art upon review of this disclosure . the scope of the invention should , therefore , be determined not with reference to the above description , but instead should be determined with reference to the appended claims along with their full scope of equivalents .