How to cope with Themes and CSS stylesheets?

  • Thread starter Thread starter Hillbilly
  • Start date Start date
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.
 
I didn't have time to study carefully what you asked, but I thought I'd
mention this, in case it should help.

I find the easiest way to compensate for various browsers is to use the
IF/ENDIF statement with the HTML link tag. This only works for IE but my
experience is that IE is the only browser that needs "special treatment"
from the stylesheet. Important - I turn off themes in web.config. Otherwise,
ASP.NET will compete with you for control over inserting the links in the
HTML. Then I use the following in my page markup.

<link id="cssScreen" runat="server" rel="Stylesheet"
href="~/App_Themes/Default/screen.css"
type="text/css" media="screen, projection" />

<link id="cssPrint" runat="server" rel="Stylesheet"
href="~/App_Themes/Default/print.css"
type="text/css" media="print" />

<!--[if IE]>
<link id="cssIE" runat="server" rel="Stylesheet"
href="~/App_Themes/Default/ie.css"
type="text/css" media="screen, projection" />
<![endif]-->
 
i focus on making the css browser compatiable. i code for safari & firefox,
then use the IE css hacks to support IE, including conditional (which can be
in the style sheet) and the odd ie 5/6 hacks. sometimes you will need a
little javascript to do the final fixup. most css sites have good lists of
browser hacks.

trusting agent string to pick stylesheets is also problematic and has its
own issues.

-- bruce (sqlwork.com)
 
I just re-read your post a second time.

You can still use the conditional comments in the markup, and keep Themes enabled, if you place your
CSS files outside of the App_Themes folder. If you place them anywhere in the App_Themes folder,
regardless of the theme name sub-folder, ASP.NET will find them and put the links in the page header
markup.

--
Regards,

Fred Chateau
fchateauAtComcastDotNet


Fred Chateau said:
I didn't have time to study carefully what you asked, but I thought I'd mention this, in case it
should help.

I find the easiest way to compensate for various browsers is to use the IF/ENDIF statement with
the HTML link tag. This only works for IE but my experience is that IE is the only browser that
needs "special treatment" from the stylesheet. Important - I turn off themes in web.config.
Otherwise, ASP.NET will compete with you for control over inserting the links in the HTML. Then I
use the following in my page markup.

<link id="cssScreen" runat="server" rel="Stylesheet" href="~/App_Themes/Default/screen.css"
type="text/css" media="screen, projection" />

<link id="cssPrint" runat="server" rel="Stylesheet" href="~/App_Themes/Default/print.css"
type="text/css" media="print" />

<!--[if IE]>
<link id="cssIE" runat="server" rel="Stylesheet" href="~/App_Themes/Default/ie.css"
type="text/css" media="screen, projection" />
<![endif]-->


--
Regards,

Fred Chateau
fchateauAtComcastDotNet


Hillbilly said:
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.
Click to expand...
Click to expand...
 
How do you enter conditional comments in a stylesheet?

My understanding is that conditional comments can only be used in the HTML markup.
 
With regard to both Fred and Bruce let's pick up on this thread as there are
three of us who cared to get involved in the subject. Besides, we're all on
the same page but somehow in a different paragraph :-)

I stopped using IE to layout and test pages --but-- the initial development
of my current work started with IE with intentions of detecting other
browsers and --then-- responding with loading style sheets dynamically as
needed to support other browsers. So we know now pragmatically speaking
doing so remains bass ackwards ainna?

So I adopted the use of Firefox (FF) exclusively for initial layout and
testing knowing we have a fallback position using conditional comments. I am
now even becoming tempted to use Safari or Chrome for the same reason as
WebKit has emerged as the most reliable parser and with exception of Brendan
Erich's recent reengineering of the JavaScript parser used by FF that
browser has taken second place in reliability which now belongs to browsers
built on WebKit. All Hail WebKit! ;-)

All that is fine and well but when using Themes I (all of us using Themes)
still have to determine how to dynamically load style sheets for all
browsers the best solution still being one which uses conditional comments
which male coping with IE rather brainless --except-- the cost of coping
with IE remains invalid XHTML when using Themes.

So I have determined VS2008 will not allow me to create nested Theme
folders. It will create a --new-- Theme folder of course but all folders
nested into that newly created Theme folder are ordinary folders and as Fred
points out will apparently be crawled and used to write declarations into
the head; that being what so fat appears to be an insurmountable problem.

Because it seems so easy and maintainable to implement this is what I'm
trying next...

App_Themes
IE6_Red (theme folder)
ie6_images_red (folder)
ie6_default.css
ie6_default.skin
IE7_Red (theme folder
ie7_images_red (folder)
ie7_default.css
ie7_default.skin
FF2_Red (theme folder)
ff2_images_red (folder)
ff2_default.css
ff2_default.skin

APPARENT PROS:

1.) Locating all Theme specific digital assets within a single
browser-dependent parent folder is a good practice as it promotes
consolidation and maintainability.
2.) No need to continue to use redundant folders located out of App_Themes
for all of the extra style sheets and images that are required anyway.
3.) Conditional comments can still be used to load style sheets in folders
not in App_Themes if wanted but doing so becomes redundant too as it is easy
to use Browser Capabilities and server-side code in Pre_Init to change the
Theme accordingly.
4.) Avoiding the use of conditional comments when using Themes allows us to
create and maintain valid XHTML as using conditional comments with Themes
requires writing the link element declaration into the body of the document
invalidating XHTML.

APPARENT CONS:

1.) Still have to write a marginal number of additional lines of code
2.) I still want to strangle Scott Gu instead of giving him a big hug ;-)

Finally IMO, all of this (or some other method) is still required and some
methodology must still be devised to cope with dynamically loading browser
dependent style sheets when using Themes because IE is not the only browser
that is FUBAR in this context of parsing and rendering styled HTML so there
is no way to really write browser compatible css as it requires so many
hacks (dozens?) which are insane to understand, insane to write and test and
insane to maintain and when I then go to writing server-side code for a
month or two and a new release of a browser occurs I have to go through
relearning all of the hacks all over again.
 
Back
Top