H
Hillbilly
Themes, Skins and CSS are inseparable (when Themes are used) but there are
some real problems with changing CSS stylesheets to respond to the many
quirks in the many different browsers. I'll skip the rest of what can be
said about the problem as I believe it is widely known and I would be
preaching to the choir.
So, after painting myself into a corner I'm looking for a way out to salvage
the entire application noting its too late to adopt a StyleSheetTheme which
I did not understand when I decided to use the Theme and has the same
problem anyway: how to dynamically change CSS stylesheets to respond to the
rendering problems by the many instances of different browsers we have to
support.
// Current structure (which is why I am in trouble)...
App_Themes
Red
Images
default.css
default.skin
Blue
Images
default.css
default.skin
Green
Images
default.css
default.skin
// Conceptual Structure: nested folders
// FF2 i.e. Firefox R2 for example
App_Themes
Red
FF2_Red
Images
default.css
default.skin
FF3_Red
Images
default.css
default.skin
...
...
Blue
FF2_Blue
Images
default.css
default.skin
FF3_Blue
Images
default.css
default.skin
...
...
Note: Because IE supports conditional comments I have been compelled to
accept invalid XHTML by using conditional comments to load stylesheets into
the <body> to work around IE CSS rendering problems. This is easy using
BrowserCapabilities and is required because Themes do not allow me to change
what is written into the head in any way that supports CSS cascading with
multiple stylsheets or conditional comments.
I also use a GlobalBaseClass to inherit from System.Web.UI.Page which allows
me to dynamically change Themes in Pre_Init as dynamically changing a Theme
is not otherwise supported by the MasterPage which is a UserControl.
The **larger problem though** has been trying to change CSS stylesheets to
cope with --other-- browsers that also have many rendering problems. I think
nested folders may conceptually solve the problem . So here is the actual
question...
Has anybody actually used nested folders in App_Themes successfully while
maintaining the ability to dynamically change the Theme during runtime? If
using nested folders works and I can dynamically reference a Theme as
Red/FF2_Red for example it would solve my problems including not being
compelled to invalidate XHTML as I would no longer have to use the
conditional comments to write IE stylesheet declarations into the body of
the HTML document when using Themes.
some real problems with changing CSS stylesheets to respond to the many
quirks in the many different browsers. I'll skip the rest of what can be
said about the problem as I believe it is widely known and I would be
preaching to the choir.
So, after painting myself into a corner I'm looking for a way out to salvage
the entire application noting its too late to adopt a StyleSheetTheme which
I did not understand when I decided to use the Theme and has the same
problem anyway: how to dynamically change CSS stylesheets to respond to the
rendering problems by the many instances of different browsers we have to
support.
// Current structure (which is why I am in trouble)...
App_Themes
Red
Images
default.css
default.skin
Blue
Images
default.css
default.skin
Green
Images
default.css
default.skin
// Conceptual Structure: nested folders
// FF2 i.e. Firefox R2 for example
App_Themes
Red
FF2_Red
Images
default.css
default.skin
FF3_Red
Images
default.css
default.skin
...
...
Blue
FF2_Blue
Images
default.css
default.skin
FF3_Blue
Images
default.css
default.skin
...
...
Note: Because IE supports conditional comments I have been compelled to
accept invalid XHTML by using conditional comments to load stylesheets into
the <body> to work around IE CSS rendering problems. This is easy using
BrowserCapabilities and is required because Themes do not allow me to change
what is written into the head in any way that supports CSS cascading with
multiple stylsheets or conditional comments.
I also use a GlobalBaseClass to inherit from System.Web.UI.Page which allows
me to dynamically change Themes in Pre_Init as dynamically changing a Theme
is not otherwise supported by the MasterPage which is a UserControl.
The **larger problem though** has been trying to change CSS stylesheets to
cope with --other-- browsers that also have many rendering problems. I think
nested folders may conceptually solve the problem . So here is the actual
question...
Has anybody actually used nested folders in App_Themes successfully while
maintaining the ability to dynamically change the Theme during runtime? If
using nested folders works and I can dynamically reference a Theme as
Red/FF2_Red for example it would solve my problems including not being
compelled to invalidate XHTML as I would no longer have to use the
conditional comments to write IE stylesheet declarations into the body of
the HTML document when using Themes.