Jim Buyens and Rob Giordano - FrontPage Theme/Style Corruption

[mark]

FrontPage Is Not Handling Themes and Style Sheets Properly

The Problem
Method
Procedure
Review
Results
Conclusion

=====

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.

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
(i) I create a new themeless site and pointed an empty style sheet to the
index file. I created a few elements in the style sheet and WOW! the site
page responds well, displaying things just the way I had asked for them to be
displayed. Then I go back to my style sheet and added a few more elements.
Next, I open my page in design view. The second style sheet edit has randomly
(?) swapped 1st edit and 2nd edit changes to font appearance and returned
some elements to default appearance (no style application. This result we
will just call "messed up" customization. Attempts to correct the style sheet
tangle were usless. Though we always make at least three attempts to resolve
the issue. FrontPage remembers the site so attempts 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 like 'em! Now, I want 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 messed 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. When i
returned to design view of index htm, none of me changes are displayed. But
FrontPage remembered my changes from the preceeding example and applied about
half of the junk settings that appeared in the previous example when I tryed
to tweak a few things.

I created a new site and applied a theme. I opened the theme dialog and
edited a few element attributes and applied them and displayed fine. I opened
the theme dialog again and FrontPage screwed my attributes around.

=====

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.
One can only hope that FrontPPage Product Development, FrontPage
Programming, Windows Server Programming, and Microsoft Office Programming
will put theiuir 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 particual 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 "Modifies the appearance of a hyperlink the visitor
has just clicked."

 

[mark]

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"

 

[mark]

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.

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
(i) I create a new themeless site and pointed an empty style sheet to the
index file. I created a few elements in the style sheet and WOW! the site
page responds well, displaying things just the way I had asked for them to be
displayed. Then I go back to my style sheet and added a few more elements.
Next, I open my page in design view. The second style sheet edit has randomly
(?) swapped 1st edit and 2nd edit changes to font appearance and returned
some elements to default appearance (no style application. This result we
will just call "messed up" customization. Attempts to correct the style sheet
tangle were usless. Though we always make at least three attempts to resolve
the issue. FrontPage remembers the site so attempts 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 like 'em! Now, I want 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 messed 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. When i
returned to design view of index htm, none of me changes are displayed. But
FrontPage remembered my changes from the preceeding example and applied about
half of the junk settings that appeared in the previous example when I tryed
to tweak a few things.

I created a new site and applied a theme. I opened the theme dialog and
edited a few element attributes and applied them and displayed fine. I opened
the theme dialog again and FrontPage screwed my attributes around.

=====

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

 

[mark]

FrontPage Is Not Handling Themes and Style Sheets Properly 2
( FINAL )

The Problem
Method
Procedure
Review
Results
Conclusion

=====

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 for testing to compare
changes applied in Design View vs. Code View. The results are the same in
either view. The operating environment housing the FrontPage installation is
being tested. Two design features are tested: theme dialogs and style sheet
selector 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 Recommended list, whichever is best - an "optimal
Windows" system.

=====

PROCEDURE
Two approaches 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 isolate this design approach comparison.

Theme and style approaches are applied to new sites in new environments (see
above) using the step-by-step procedures recommended in FrontPage Help and in
current Microsoft publications 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 theme-less 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 as appears
in several themes shipped with FrontPage 2003. This result we will just call
"mess up" customization. Attempts to correct the mess up are useless. Though
we always make at least three attempts to resolve the issue. FrontPage
remembers the site. Subsequent attempts always imply creating a new site and
starting over.

(ii) I create a new empty site and add a new theme (bottom of the 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 procedures 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 preceding 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 that is demonstrating the tested corruption of the FrontPage
2003 editor. One can only hope that FrontPage 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 styles in Microsoft SharePoint templates. Integrating
these descriptions with intellisense is a must! In total there are less than
500 selectors shipped by Microsoft on my desktop. The benefits of this
upgrade to FrontPage far outweigh the cost, we are all certain!

Presently, the deep freeze Description field simply and continually displays:
"Click button blah blah blah
Click button blah blah blah"

 

[mark]

Is there any way to adjust registry settings and FrontPage and Office (2003)
settings in the Windows XP Documents and Settings folder?

FrontPage Is Not Handling Themes and Style Sheets Properly

The Problem
Method
Procedure
Review
Results
Conclusion

=====

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.

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
(i) I create a new themeless site and pointed an empty style sheet to the
index file. I created a few elements in the style sheet and WOW! the site
page responds well, displaying things just the way I had asked for them to be
displayed. Then I go back to my style sheet and added a few more elements.
Next, I open my page in design view. The second style sheet edit has randomly
(?) swapped 1st edit and 2nd edit changes to font appearance and returned
some elements to default appearance (no style application. This result we
will just call "messed up" customization. Attempts to correct the style sheet
tangle were usless. Though we always make at least three attempts to resolve
the issue. FrontPage remembers the site so attempts 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 like 'em! Now, I want 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 messed 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. When i
returned to design view of index htm, none of me changes are displayed. But
FrontPage remembered my changes from the preceeding example and applied about
half of the junk settings that appeared in the previous example when I tryed
to tweak a few things.

I created a new site and applied a theme. I opened the theme dialog and
edited a few element attributes and applied them and displayed fine. I opened
the theme dialog again and FrontPage screwed my attributes around.

=====

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.
One can only hope that FrontPPage Product Development, FrontPage
Programming, Windows Server Programming, and Microsoft Office Programming
will put theiuir 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 particual 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 "Modifies the appearance of a hyperlink the visitor
has just clicked."

 

[Stefan B Rusynko]

You are barking up the wrong tree

FP style sheets and themes are completely independent of any registry settings and do not use the registry to control theme / style
sheet appearance

--

_____________________________________________
SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!" (-;
To find the best Newsgroup for FrontPage support see:
http://www.frontpagemvps.com/FrontPageNewsGroups/tabid/53/Default.aspx
_____________________________________________


| Is there any way to adjust registry settings and FrontPage and Office (2003)
| settings in the Windows XP Documents and Settings folder?
|
| "mark" wrote:
|
| > FrontPage Is Not Handling Themes and Style Sheets Properly
| >
| > The Problem
| > Method
| > Procedure
| > Review
| > Results
| > Conclusion
| >
| > =====
| >
| > 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.
| >
| > 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
| > (i) I create a new themeless site and pointed an empty style sheet to the
| > index file. I created a few elements in the style sheet and WOW! the site
| > page responds well, displaying things just the way I had asked for them to be
| > displayed. Then I go back to my style sheet and added a few more elements.
| > Next, I open my page in design view. The second style sheet edit has randomly
| > (?) swapped 1st edit and 2nd edit changes to font appearance and returned
| > some elements to default appearance (no style application. This result we
| > will just call "messed up" customization. Attempts to correct the style sheet
| > tangle were usless. Though we always make at least three attempts to resolve
| > the issue. FrontPage remembers the site so attempts 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 like 'em! Now, I want 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 messed 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. When i
| > returned to design view of index htm, none of me changes are displayed. But
| > FrontPage remembered my changes from the preceeding example and applied about
| > half of the junk settings that appeared in the previous example when I tryed
| > to tweak a few things.
| >
| > I created a new site and applied a theme. I opened the theme dialog and
| > edited a few element attributes and applied them and displayed fine. I opened
| > the theme dialog again and FrontPage screwed my attributes around.
| >
| > =====
| >
| > 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.
| > One can only hope that FrontPPage Product Development, FrontPage
| > Programming, Windows Server Programming, and Microsoft Office Programming
| > will put theiuir 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 particual 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 "Modifies the appearance of a hyperlink the visitor
| > has just clicked."

 

[Stefan B Rusynko]

External style sheet together with themes are incompatible
- due to CSS cascading
A FP theme is applied using CSS and when used is always applied last
(thus cascading over any styles in any other custom style sheet)

Always add your custom styles to the theme style using Format Theme Modify/Customize Text More Text Styles
For info on how to edit your theme style outside of FP see
http://sbrenjoy.bizland.com/frontpage/themes/newthemes.html#Granular
For info on the WSS styles in a FP theme see
http://www.sharepointcustomization.com/resources/tipstricks/wss_cssguide.htm
For learning CSS start here
http://www.w3schools.com/css/default.asp

--

_____________________________________________
SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!" (-;
To find the best Newsgroup for FrontPage support see:
http://www.frontpagemvps.com/FrontPageNewsGroups/tabid/53/Default.aspx
_____________________________________________


| FrontPage Is Not Handling Themes and Style Sheets Properly 2
| ( FINAL )
|
| The Problem
| Method
| Procedure
| Review
| Results
| Conclusion
|
| =====
|
| 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 for testing to compare
| changes applied in Design View vs. Code View. The results are the same in
| either view. The operating environment housing the FrontPage installation is
| being tested. Two design features are tested: theme dialogs and style sheet
| selector 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 Recommended list, whichever is best - an "optimal
| Windows" system.
|
| =====
|
| PROCEDURE
| Two approaches 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 isolate this design approach comparison.
|
| Theme and style approaches are applied to new sites in new environments (see
| above) using the step-by-step procedures recommended in FrontPage Help and in
| current Microsoft publications 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 theme-less 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 as appears
| in several themes shipped with FrontPage 2003. This result we will just call
| "mess up" customization. Attempts to correct the mess up are useless. Though
| we always make at least three attempts to resolve the issue. FrontPage
| remembers the site. Subsequent attempts always imply creating a new site and
| starting over.
|
| (ii) I create a new empty site and add a new theme (bottom of the 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 procedures 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 preceding 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 that is demonstrating the tested corruption of the FrontPage
| 2003 editor. One can only hope that FrontPage 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 styles in Microsoft SharePoint templates. Integrating
| these descriptions with intellisense is a must! In total there are less than
| 500 selectors shipped by Microsoft on my desktop. The benefits of this
| upgrade to FrontPage far outweigh the cost, we are all certain!
|
| Presently, the deep freeze Description field simply and continually displays:
| "Click button blah blah blah
| Click button blah blah blah"
|

 

[mark]

Hi Stefan,

I use the More Text Styles or MTS method that you describe OFTEN. MTS is not
the solution. MTS often becomes a liability on any WSS or Windows SharePoint
Services virtual account at bCentral.com and FrontPagesWebHosting.com. FYI
"virtual" generally means "not on a dedicated server", although recently FWHN
began offering a low cost "virtual dedicated" solution. So let's look at this
issue carefully.

First, another way to get similar results to MTS is to "tinker" with css
files published to WSS by FrontPage. The operative word is "tinker" since
many css files are published to the WSS site and their specific use and
launch sequence are undocumented. How nice it would be if FrontPage would
"text" the css files it creates during a publish with a note including what
the css file does; also including a comprehensive list of css files for the
site and then isolating server files and FrontPage files and the order that
they should launch in. I have only tinkered a few times as FrontPage is not
ready for this level of sophistication yet. Having determined that our
approach has been thorough, let's get back to standard basics.

The really BIG-BIG-BIG problem with the MTS method you suggest is that
FrontPage doesn't seem to know how to negotiate style settings with the WSS
virtual account server [and visa versa]. Using MTS to change an existing
style element or even creating a new style element can totally corrupt style
throughout the WSS account holder's site. For example,
www.sharepointcustomization.com (a preferred Microsoft partner) describes how
to change gradient images for WSS toolbars. Big disaster if you open the MTS
User Defined Styles dialog to attempt those techniques! The corruption is
incremental and inevitable. Even apperently unrelated style settings are
eventually corrupted - en masse! Server memory issue? Who knows!

Generally, the MTS method can only be "applied online by SharePoint Server
administration" to the WSS server templates. Any change (however small) made
to the theme's style on a hosted WSS site using the MTS method will conflict
with the administration style settings (namely, the default theme template
style sheets): the "culprit" virtual site (editing those settings using
FrontPage) will be "fried". Now, please keep in mind that any new theme you
apply to a WSS site then becomes lodged in the server; more on this in a
minute. In fact, using the SharePointCustomization guide to adjust as many
style elements as possible, FrontPagesWebHosting.com technicians scream at me
that I have "FRIED" everyone's site on my shared server node ("100's of
sites" - naturally, mine wasn't recovered ~o_o~). This is an excellent (but
unfriendly) way to create an isolated environment to test the limits of style
management using FrontPage 2003 to edit a virtual WSS account (my apologies
to all concerned, this was not intentional). I am certain that Product
Development can do a better job than FWHN and I!

There is presently only one work around. The workaround does not allow the
designer to go safely beyond HTML Tags to User Defined Styles in the MTS
dialog. Create a local site containing a copy of the "wss.css" file -
whatever it is called. The css file is not critical - I tried this a few
times, the workaround does just as well without it, but it might help and it
can't hurt. In FrontPage use the Format » Style command to isolate this file
and save it to your theme creation site. Insert the WSS web part page's
linkrel statement pointing to the local wss.css. Edit your theme's style on
the "linkrel'd" page, giving your theme a unique name. Open your WSS site and
apply the new theme. You can safely do this only once, so it is a good idea
to place your local theme creation sites in "dated" folders like
"nature060321-1410", "nature060321-1550", etc.

THINGS THAT DO NOT WORK.
1. Editing a used local theme creation site's style settings and then
applying the adjusted theme to the WSS site using the same theme name (or the
name of any default themes run from the server, or the name of any other
theme you have recently applied on the same server, and maybe you should not
even use a theme name applied by anyone else on the same server node or
server).
2. Attempting to define your own theme using the FrontPage Create New Theme
method for the WSS site online or locally.
3. Attempting to apply any style sheet to a WSS site without using a
Microsoft FrontPage 2003 generated theme.
4. Attempting to build a theme creation site on the WSS account and then
applying the new theme on the same WSS server ( tested this futlity on two
sets of WSS accounts first on different servers, then on different server
nodes with the same incrementing style corruption).

So you see, the theme/style corruption problem is not so easily resolved.
Standard FrontPage styling tactics wreak havoc on WSS sites. Is there a
workaround, or technology offered by microsoft to bypass this problem?

An obvious cheap workaround is for the WSS server to block authors from
applying any previously used theme name - this could be an easily distributed
hotfix. Another immediate fix (this one distributed to FrontPage authors)
would make it impossible to use the More Text Styles method with any WSS site
opened on the desktop (a memory cache nightmare). Yet another desktop hotfix
would allow FrontPage to option saving themes with a new file name,
defaulting to a new file name and coupled with a popup help file suggesting
WSS authors never use the same theme name twice (lame education). Eventually,
desktop designers should be given an improved FrontPage product and
SharePoint server product that will allow safe style management using
FrontPage to author WSS virtual accounts.

SharePoint is going to grow rapidly in popularity. My customers are soaking
up the functionality and lambasting drab appearance. A FIX IS NEEDED.

You might want to run this by Mike et al at Studio9, where SharePoint
version 3 is presently under development. I would send it through myself
except that my concern here is too non-specific; my focus is shifting
erratically server-side and author-side. You have a much better understanding
of how FrontPage is supposed to work. And you have my situation,
well-described herein. I think the team in Product Development would enjoy a
close look at this issue and quite easily correct the problem.

WSS Virtual Server accounts (a most popular hosting format) cause serious
conflicts for the server when FrontPage authors attempt to change theme style
settings. This is a significant problem as many customers use virtual
accounts (over 10,000 at FrontPagesWebHosting.com, I am advised by detractors
whom I must now befriend). TIA.

GOOD LUCK!!!!!

Kind regards, (e-mail address removed)

External style sheet together with themes are incompatible
- due to CSS cascading
A FP theme is applied using CSS and when used is always applied last
(thus cascading over any styles in any other custom style sheet)

Always add your custom styles to the theme style using Format Theme Modify/Customize Text More Text Styles
For info on how to edit your theme style outside of FP see
http://sbrenjoy.bizland.com/frontpage/themes/newthemes.html#Granular
For info on the WSS styles in a FP theme see
http://www.sharepointcustomization.com/resources/tipstricks/wss_cssguide.htm
For learning CSS start here
http://www.w3schools.com/css/default.asp

--

_____________________________________________
SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!" (-;
To find the best Newsgroup for FrontPage support see:
http://www.frontpagemvps.com/FrontPageNewsGroups/tabid/53/Default.aspx
_____________________________________________


| FrontPage Is Not Handling Themes and Style Sheets Properly 2
| ( FINAL )
|
| The Problem
| Method
| Procedure
| Review
| Results
| Conclusion
|
| =====
|
| 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 for testing to compare
| changes applied in Design View vs. Code View. The results are the same in
| either view. The operating environment housing the FrontPage installation is
| being tested. Two design features are tested: theme dialogs and style sheet
| selector 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 Recommended list, whichever is best - an "optimal
| Windows" system.
|
| =====
|
| PROCEDURE
| Two approaches 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 isolate this design approach comparison.
|
| Theme and style approaches are applied to new sites in new environments (see
| above) using the step-by-step procedures recommended in FrontPage Help and in
| current Microsoft publications 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 theme-less 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 as appears
| in several themes shipped with FrontPage 2003. This result we will just call
| "mess up" customization. Attempts to correct the mess up are useless. Though
| we always make at least three attempts to resolve the issue. FrontPage
| remembers the site. Subsequent attempts always imply creating a new site and
| starting over.
|
| (ii) I create a new empty site and add a new theme (bottom of the 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 procedures 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 preceding 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 that is demonstrating the tested corruption of the FrontPage
| 2003 editor. One can only hope that FrontPage 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 styles in Microsoft SharePoint templates. Integrating
| these descriptions with intellisense is a must! In total there are less than
| 500 selectors shipped by Microsoft on my desktop. The benefits of this
| upgrade to FrontPage far outweigh the cost, we are all certain!
|
| Presently, the deep freeze Description field simply and continually displays:
| "Click button blah blah blah
| Click button blah blah blah"
|

 

[mark]

The wrong tree in my back yard, but Microsoft's grand-daddy oak.
ie - windows server registry settings, etc, etc, etc
ie - windows product development, etc etc etc
Is there something wrong with mentioning the enormity of a problem?
We await Vista and the next version of FrontPage.
2008? Are we ahead of schedule? Are we ready to be ahead?

Back to the point, FP style is managed easily through the theme settings.
Unfortunately, on a SharePoint server, these settings create havoc when
applied by anyone but SharePoint server administration. Naturally, Microsoft
does not want to grey-out Themes in the FP Task Pane. Another exciting issue
of Redfern Roulette!

You are barking up the wrong tree

FP style sheets and themes are completely independent of any registry settings and do not use the registry to control theme / style
sheet appearance

--

_____________________________________________
SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!" (-;
To find the best Newsgroup for FrontPage support see:
http://www.frontpagemvps.com/FrontPageNewsGroups/tabid/53/Default.aspx
_____________________________________________


| Is there any way to adjust registry settings and FrontPage and Office (2003)
| settings in the Windows XP Documents and Settings folder?
|
| "mark" wrote:
|
| > FrontPage Is Not Handling Themes and Style Sheets Properly
| >
| > The Problem
| > Method
| > Procedure
| > Review
| > Results
| > Conclusion
| >
| > =====
| >
| > 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.
| >
| > 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
| > (i) I create a new themeless site and pointed an empty style sheet to the
| > index file. I created a few elements in the style sheet and WOW! the site
| > page responds well, displaying things just the way I had asked for them to be
| > displayed. Then I go back to my style sheet and added a few more elements.
| > Next, I open my page in design view. The second style sheet edit has randomly
| > (?) swapped 1st edit and 2nd edit changes to font appearance and returned
| > some elements to default appearance (no style application. This result we
| > will just call "messed up" customization. Attempts to correct the style sheet
| > tangle were usless. Though we always make at least three attempts to resolve
| > the issue. FrontPage remembers the site so attempts 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 like 'em! Now, I want 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 messed 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. When i
| > returned to design view of index htm, none of me changes are displayed. But
| > FrontPage remembered my changes from the preceeding example and applied about
| > half of the junk settings that appeared in the previous example when I tryed
| > to tweak a few things.
| >
| > I created a new site and applied a theme. I opened the theme dialog and
| > edited a few element attributes and applied them and displayed fine. I opened
| > the theme dialog again and FrontPage screwed my attributes around.
| >
| > =====
| >
| > 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.
| > One can only hope that FrontPPage Product Development, FrontPage
| > Programming, Windows Server Programming, and Microsoft Office Programming
| > will put theiuir 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 particual 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 "Modifies the appearance of a hyperlink the visitor
| > has just clicked."