Reply to thread

Message: [QUOTE="mark, post: 6580273"] TYPOS CORRECTED (Lord my aching head!) FrontPage Is Not Handling Themes and Style Sheets Properly The Problem Method Procedure Review Results ===== THE PROBLEM FrontPage has difficulty managing style sheet and theme customizations depending on the environment where FrontPage is used. ===== METHOD The FrontPage Format menu commands for Theme... and Style... are used to effect changes to page appearance. It is not relevant if the changes are applied in Design View or in Code View. The results are the same. The operating environment housing the FrontPage installation is being tested. Two design features are tested: theme dialogs and style sheet style settings. Theme/style approaches are applied in three environments, desktop alone, desktop and Windows Server 2003 HTML site, desktop and Windows SharePoint Services 2.0 site. The three test environments are isolated by creating each environment in a separate system installation of Windows XP and Microsoft Office 2003 including FrontPage 2003. Software and Hardware are either Microsoft or at the top of the Microsoft Recmmended list, whichever is best - an "optimal Windows" system. ===== PROCEDURE Two appraoches are considered: theme dialogs and style sheet editing. a) I create a new site and apply a style sheet and then a apply a theme. b) I create a new site and apply a theme and then apply a style sheet. Comparing the two approaches does not isolate any distinction between order of approach and FrontPage performance in design. Thus the report below does not isoalate this design approach comparison. Theme and style approaches are applied to new sites in new environments (see above) using the step-by-step proceedures recommended in FrontPage Help and in current Microsoft pulications by Jim Buyens. A) Style Sheet - I open a style sheet and apply changes to some attributes. I go back to design view and review page appearance. I return to edit the style sheet and apply a few more changes to some elements. I re-open design view and again review page appearance. B) Theme Dialog - I open the theme dialog and apply changes to some attributes. I go back to design view and review page appearance. I return to the theme dialog and apply a few more changes to some elements. I re-open design view and again review page appearance. ===== TESTING REVIEW Each of the four test reviews below includes multiple test runs. (i) I create a new themeless site and point an empty style sheet to the index file. I add a few elements in the style sheet (body, h1, etc) and WOW! the site page responds well, displaying things just the way I want them displayed. h1 displays in a beautiful leaf green 24pt Ms Trebuchet. Then I go back to my style sheet and edit and add a few more elements. Next, I open my page in design view for a second review of my applied changes. FrontPage has randomly (?) swapped 1st edit and 2nd edit changes to font appearance and returned some elements to default appearance (no style application). One selector (h1) has called up a standard 36 pt Times New Roman font. This result we will just call "mess up" customization. Attempts to correct the style sheet tangle are usless. Though we always make at least three attempts to resolve the issue. FrontPage remembers the site. Subsequent attempts at the theme/style test here imply creating a new site and starting over. (ii) I create a new empty site and add a new theme (bottom of theme task pane) and in the theme dialog add some attributes to elements. Of course, returning to design view my style choices are gorgeous and display just like I want 'em! Now, I need to tweak a few things and so I go back to the theme dialog and change a few attributes. When I return to design view [groan] the attributes are a mess up. (iii) I create a new site with an empty theme and open and edit theme style sheets, honoring the proccedures applied within the various style sheets: for example in the color1.css sheet only color attributes are set. Jim Buyens explains this syntax conformity very well. When i return to design view of index htm, none of my changes are displayed. But FrontPage remembers my changes from the preceeding test run item and reapplies about half of the default style attributes. This recall of dumped junk style settings hanging on after a few system reboots! Hey, this baby needs weaning! (iv) I create a new site and apply a theme. I open the theme dialog and edit a few element attributes and they display just perfect in design view. I open the theme dialog again and the page is a mess up. ===== RESULTS Three environments are tested. 1) desktop only 2) desktop and Windows 2003 server HTML site 3) desktop and Windows SharePoint Services 2.0 1a) desktop style - does not work period 1b) desktop theme - works 2a) desktop style - mess up 2b) desktop theme - works 2c) site style - mess up 2d) site theme - works 3a) desktop style - mess up 3b) desktop theme - mess up 3c) site style - mess up 3d) site theme - mess up CONCLUSION This is an end user client based conclusion. There are likely registry keys that need to be reset/created and product files in the Documents and Settings folder that need to be edited to correct the shortcoming providing etsed corruption of the FrontPage 2003 editor. One can only hope that FrontPPage Product Development, FrontPage Programming, Windows Server Programming, and Microsoft Office Programming will put their heads together and finally complete the FrontPage GUI for style design. Many product suggestions are no doubt in circulation. My top wish is a dialog box that lists Styles in a scroll box as is presently the case; but also, provides a description of the particular style selector that is highlighted in the Styles scrolling list. When "a:active" is selected. or ".a-active" is typed in the Styles list selection box, then in the description field a description of the style attribute is provided. For the "a:active" selector, the description might be ".a.active - Modifies the appearance of a hyperlink the visitor has just clicked." This would involve adding intelligent descriptions to the style bloated SharePoint templates. Integrating these descriptions with intellisense is a must! Presently, the deep freeze Description field simply and continually displays: "Click button blah blah blah Click button blah blah blah" [/QUOTE]

Verification