When do multiple stylesheets make sense?

[Phlawm53]

I'm contemplating how best to organize a Flare project's CSS file or files when the project includes multiple types of output.

I've been using Flare for a bit more than three years and am generally pretty good at defining CSS styles and otherwise working with CSS. So I don't have a "problem" as such. But I am doing a bit of thinking (uh oh) about CSS "strategy".

Today I have several projects that have both print (PDF, Word) and online help (WebHelp, HTML5 Help) Targets. Although I've generated other Targets (ePub, Air, et al.) "for fun", I may at some point need to generate them as production-quality outputs.

So I''m hoping to learn from others' experience how best to organize a "complex" Flare project's CSS file or files.

My current approach is to use a single CSS file for a given project, organized as follows:

• The stylesheet's default units are for print mediums or targets, and so are specified in points (pts) and inches (in).
• The stylesheet's default section also includes shared specifications that don't use measurement units such as heading color, font-family, float / clear classes, and so on.
• A @media non-print section specifies units in ems.

I'm now considering splitting the single CSS stylesheet into separate Print, Nonprint, and Shared stylesheets. Both the print and non-print stylesheets would begin with an @import statement to acquire the Shared (that is, non-measurement specific) styles. I'm thinking that the benefits of so doing will be that it will be easier to:

• Implement changes to a specific category (shared, print, non-print) without having to deal with all the other unrelated stuff contained in a single large stylesheet.
• More easily create — and manage — a separate set of measurement-specific style definitions for other Target types (ePub, et al.) in future projects.

I'm wondering if this is in fact a good idea or a not-so-good idea. For example:

• Does splitting stylesheets into specialized categories make it clumsier to, say, author topics or preview them in Flare's XML Editor?
• Does this strategy in fact make it more difficult rather than less difficult to manage a project's CSS files or troubleshoot CSS problems?
• What other issues or considerations should one incorporate into a "CSS Strategy"?
• And so on…

Any guidance or acquired wisdom you can share with me about the best way to implement a "robust" stylesheet strategy will be appreciated.

Cheers & thanks in advance for your help,
Riley
SFO

[Nita Beck]

I am a proponent of separate stylesheets depending on the output type, but I believe that I'm in the minority. Yes, I have to make sure that I have the same named styles in each of the stylesheets that I plan to use in the same project. But I've found that, once the stylesheets are set up, it is not all that difficult to make sure that each has the same named styles.

Let me give an example.

For one of my clients, I have a set of base stylesheets: HelpStyles, UserGuideStyles, QuickStartGuideStyles. These are managed in a global project, along with a bunch of other things I don't need to go into here.

Then I have "local" projects for each of the client's different products. For some of the products, I only ever produce a User Guide, so the only stylesheet I need to import is the UserGuideStyles (along with the correct page layouts). For other products, I produce a Help system and a Quick Start Guide, so I import the HelpStyles and UserGuideStyle stylesheets.

Regarding using an @import in a stylesheet, I actually do that too! The "global" HelpStyles don't use any colors anywhere; for example, all the headings are gray and all the p.Notes have a gray background. But in the "local" projects for which I produce Help, I use a local stylesheet that imports all the styles from the imported HelpStyles stylesheets and then applies colors, as a way of branding the output with the brand colors of the product. If the dominant color in the product's UI is a nice blue, then the headings in its Help system will be that same blue, and the p.Notes will have a light blue background. Another product's dominant UI color might be maroon, so the local stylesheet for its Help system will turn the headings maroon (and I think I made the background of the p.Notes a nice beige, 'cause "light maroon" was pink, which looked tacky).

This whole scheme has been incredibly easy to manage.

Hope these ideas help...

[Phlawm53]

Nita:

Thanks for sharing your approach.

For some of the products, I only ever produce a User Guide, so the only stylesheet I need to import is the UserGuideStyles (along with the correct page layouts). For other products, I produce a Help system and a Quick Start Guide, so I import the HelpStyles and UserGuideStyle stylesheets.

Does that mean that a stylesheet for a given document type includes both print measurement units and online measurement units?

I've been thinking in term of dividing stylesheets on the basis of print / online measurement units. Your approach has led me to contemplate another basis for separating stylesheets on the basis of document type rather than online / print output type(?)

Cheers & thanks 'gain,
Riley
SFO

[nickatwork]

Hi,
Quite interested in what you guys are talking about here. But I'm a little confused, why are mediums not a viable option for your projects? Is it because you are using global projects? I'm creating multiple output types, for different products with different UIs, but I just create additional mediums. Most of the styles usually will have the same set up, indents, spacing etc but I am usually changing just the colour schemes that I use or font size and thats maybe 4 or 5 modifications to the style in each medium.

[Nita Beck]

Hi,
Quite interested in what you guys are talking about here. But I'm a little confused, why are mediums not a viable option for your projects? Is it because you are using global projects? I'm creating multiple output types, for different products with different UIs, but I just create additional mediums. Most of the styles usually will have the same set up, indents, spacing etc but I am usually changing just the colour schemes that I use or font size and thats maybe 4 or 5 modifications to the style in each medium.

Of course mediums are a viable option. Never said they weren't. Riley asked for thoughts on when multiple stylesheets might be appropriate.

There was a long discussion on the merits of mediums vs. separate stylesheets a while back. I'm pressed for time right now but I'll try to go back and find it and will post the link.

[Nita Beck]

Here's the link to that old discussion. (I forgot that I actually started the discussion!)

http://forums.madcapsoftware.com/viewto ... 17&start=0

[Phlawm53]

Nita: Thanks for that link.

Among the many useful comments in that thread was:

Another advantage of Mediums (in addition to only having to maintain one file, as you have mentioned), is that they should also apply when the user prints from your help. For example, if you use the medium "print", Flare will add
@media print { ... } to your stylesheet. Those styles will also apply when the user hits File>Print in your browser, or hits the print button in CHM help.

(See http://forums.madcapsoftware.com/viewto ... =15#p52835)

Based on what I've learned so far, I'm going to experiment with separating stylesheets on the basis of output type (online, print, and perhaps others) which for me is equivalent to separating on the basis of measurement unit (ems for online, inches and pts for print).

To be continued…

Cheers & thanks 'gain,
Riley
SFO