• FlexDoc.XYZ
• Documentation
• Usage of CSS in generated HTML

FlexDoc.XYZ - Usage of CSS in generated HTML

1. HTML Generator Options for CSS
2. Generated CSS Rules
   • Anonymous Rules
   • Named Rules
     • CSS rules derived from template formatting styles
     • Where does CSS class name come from?
     • Multiple named rules with the same class selector
     • Named + anonymous rules
     • Named + named + anonymous rules
     • Other cases: Which template styles can produce named rules?
     • Controlling named rules
   • Default Rules
3. Generated Style Sheets
   • Local Style Sheet
   • Global Style Sheet
   • Multiple Style Sheets
   • Style Sheet Structure
4. Custom CSS Rules / CSS File
   • How to substitute generated CSS rules with custom ones?
     • Find which generated rules to substitute
     • Provide your own declarations
     • Custom default rules
     • Case of relative length units
     • Which license required?
   • CSS pattern file
5. Appendix
   • The problem with relative length units
   • Applying multiple CSS rules to the same HTML element

1. HTML Generator Options for CSS

2. Generated CSS Rules

When a template component is interpreted, it produces a piece of HTML output (which is typically represented by a certain HTML element). All formatting of that output comes in the form of CSS rules. The rules themselves are placed in the style sheet and the class selectors associated with them are specified in HTML tags.

The CSS rules generated by FlexDoc fall into three categories:

1. Anonymous Rules
2. Named Rules
3. Default Rules

Anonymous Rules

Example

font-family: "Arial", sans-serif; font-size: 130%; font-weight: bold; color: blue

<span style="font-family: "Arial", sans-serif; font-size: 130%; font-weight: bold; color: blue"> ... </span>

But, the same template component may generate another piece of output and many more. So, the same inline list of CSS properties will be repeating by every of them. That would potentially bloat the generated HTML file quite a lot. (Moreover, different template components may also produce equal CSS property sets.)

To avoid that repeating, each set of CSS properties is specified only once in the form of a CSS rule, which is placed in a style sheet under a certain class name (selector), like this (here 'aXXX' is the rule's class name):

<style>
  span.aXXX { font-family: "Arial", sans-serif; font-size: 130%; font-weight: bold; color: blue }
</style>


<span class="aXXX"> ... </span>

Such CSS rules, which are produced by the generator automatically in order to replace with them the inline CSS properties, we shall call anonymous rules. That's because the class names assigned to those CSS rules, besides being meaningless, have no constant relation with the particular lists of CSS properties they represent.

Exactly how such class names are generated depends on the data being processed. Another HTML document generated by the same template may contain similar anonymous CSS rules, but associated with different class names. Even when a global style sheet is maintained, the rule class names may be different when you generate another documentation for a different data source.

That problem has been solved with the introduction of named CSS rules.

Named Rules

Such CSS rules associated with constant class names that are specified in templates, we shall call named rules.

Here is how it works.

CSS rules derived from template formatting styles

Originally, template formatting styles were modeled on RTF styles. When RTF output is generated, a template formatting style would be rendered with a corresponding RTF style.

<style>
  span.highlight { color: #EE0000 }
</style>

<span class="highlight"> ... </span>

Where does CSS class name come from?

Multiple named rules with the same class selector

That means, some template styles cannot be expressed with a single CSS rule. Rather, they must be rendered with several CSS rules applied to different HTML elements nested in each other. Such multiple CSS rules (produced from the same template style) will still have the same class name (specified in the style). So, you can substitute all of them with your custom rules as well.

In fact, there are quite a few specific situations when multiple named rules with the same class selector are produced:

• Ambiguous formatting properties

  Some formatting properties specified in templates have no direct analogues in CSS. For example, there is no special CSS property for background color of text. Of course, CSS has 'background-color' property, but when it is applied to a particular HTML element, it will color the whole object described by that element. For instance, when that is a <div>, the entire strip on the page will be colored - not just the text contained in it!

  In the following flash movie it is explained in full details (click on the picture):

  

• Property conflicts caused by relative units

  Another problem arises, when relative units (for font sizes and lengths) are used. Then, the CSS rule like this (which might be generated from a template paragraph style 'heading'):

  div.heading {

  font-family: "Arial", sans-serif; font-size: 90%; font-weight: bold; text-decoration: none; color: black; margin-top: .58em; margin-bottom: .25em; white-space: nowrap; }

  would not produce the top and bottom margins as intended in the template, because the values for those margins specified in the rule would be interpreted not against the document base font size, but against a new font size (reduced to 90%), which comes from the rule itself.

  Of course, the margins may be corrected according to that local font size too. But such tricks would complicate everything enormously.

  To work around those problems, each template paragraph styles is rendered with two named CSS rules: one for paragraph properties and another one for text properties. For example:

  div.heading  {	margin-top: .58em; margin-bottom: .25em; white-space: nowrap; }
  span.heading {	font-family: "Arial", sans-serif; font-size: 90%; font-weight: bold; text-decoration: none; color: black; }

  and here is how those rules are applied:

  <div class="heading"><span class="heading">Heading Text</span></div>

  See also:
  • “Output | CSS | Units” option
  • Appendix | The problem with relative length units
  • How to substitute generated CSS rules with custom ones? | Case of relative length units
• Blended-in hyperlinks

  Some hyperlinks must not be too prominent. That is, they must look the same as the normal text, yet have something indicating the hyperlink (e.g. underlining). Another possibility is that the hyperlink must be hidden completely, so it appears as ordinary text all the time, yet reveals itself when the mouse cursor hovers over it. Both effects can be achieved by formatting the hyperlink as normal text and adding to it some extra-formatting (indicating the link either constantly or only during the mouse hovering).

  Formatting of a hyperlink as normal text means applying to the <a> element the same CSS properties as for the normal text and having those properties override any default hyperlink formatting.

  This is achieved by specifying that the CSS rule for text is also applicable for <a> elements. In the following example, two named CSS rules are produced from the same template formatting styles 'heading':

  /* CSS rule to format the heading paragraph */
  div.heading {	margin-top: .58em; margin-bottom: .25em; white-space: nowrap; }

  /* CSS rule for both normal text and hyperlinks blended into it */
  span.heading, a.heading {	font-family: "Arial", sans-serif; font-size: 90%; font-weight: bold; text-decoration: none; color: black; }

  /* CSS rule to indicate a hyperlink when mouse hovering */

  a:hover.link { text-decoration: underline; }

  Now, the HTML code for a blended-in hyperlink will look like this:

  <div class="heading">
    <a ref="..." class="heading link">Heading Text/Link</a>
  </div>
  

  In the following flash movie you can see how this is programmed in a real doc-generator (click on the picture):

  

Named + anonymous rules

But what will happen when, besides the style 'Highlighted Text', the component has other formatting properties directly specified on it? For example, the bold font:

<style>
  span.highlight { color: #EE0000 }
  span.aXXX { font-weight: bold }
</style>

<span class="highlight aXXX"> ... </span>

Named + named + anonymous rules

The following Area Section (shown on the screenshot) would generate a certain message. It is a paragraph filled with a bright color and surrounded by the border to highlight the whole message. The message text is formatted mostly with the same font and color, however, a part of it is highlighted with a different color and the bold font. The panel on the right actually shows what that message would look like:

<style>
  /*
   * Two named rules generated from 'Message' style
   * (see also: Multiple named rules with the same class selector)
   */
  div.msg  { background-color: #FFFFDD; border: solid 1px #FF0000; 
             margin-top: .4em; margin-bottom: .4em; padding-top: .1em; padding-bottom: .1em; }
  span.msg { font-family: "Verdana", sans-serif; font-size: 110%; color: #008000; }

  /* the named rule generated from 'Highlighted Text' style */
  span.highlight { color: #EE0000 }

  /* the anonymous rule generated by the direct settings on the control */
  span.aXXX { font-weight: bold }
</style>

<div class="msg">
	<span class="msg">A message with the normal and </span><span class="msg highlight aXXX">highlighted</span><span class="msg"> text.</span>
</div>

But you may notice also that both 'msg' and 'highlight' rules specify the color property. So, which color will be used for “highlighted” then? According to how CSS works, it will be the color from the latest defined CSS rule, that is from 'highlight'. That will be the same in any browser! See also: Applying multiple CSS rules to the same HTML element.

Other cases: Which template styles can produce named rules?

Now, you may assume that when even more formatting styles are used in a chain, that will lead to an HTML output like this:

<span class="style1 style2 ... styleN aXXX"> . . . </span>

There is one exception, however. It is hyperlink styles. Hyperlink styles are the character formatting styles assigned to the template controls that may generate hyperlinks. When a hyperlink is generated, the hyperlink formatting style will be applied to it, including in the form of a named rule. There are several methods of how hyperlinks are formatted. One of them is blended-in hyperlink (i.e. the hyperlink always looks the same as the ordinary text at the given location, however, with some extra feature indicating the hyperlink). In that case, when a paragraph, character and hyperlink styles are involved together and all provide some text formatting properties, all of them will be rendered into the corresponding named rules for the <a> tag, so that all the three rules are applied to the hyperlink.

That's because when even more template styles are tracked simultaneously to become named rules, the implementation of that becomes so complicated that it isn't worth it. Also, the formatting properties defined in those styles may override each other according to how the styles are ordered in the chain. Replicating the same behavior in CSS would require the equal ordering of the corresponding named rule definitions. But what if the same styles are applied somewhere else in a different order? In short, CSS simply doesn't support such things. The object model of CSS rules is too rudimentary for this.

Controlling named rules

Generation of named rules is controlled by the “Output | CSS | Generate named rules” option:

• When it is set "none", no named rules will be generated. Then, all formatting properties of a template component will be treated the same, irrelevant where they originate. That will produce only anonymous rules.
• When the option is set "all", all possible named rules will be generated.
• When the option is set "selected", only those named CSS rules will be generated, which are produced from template formatting styles with the selected "CSS | Allow named rule" property:

  

  This allows you to enable exactly those named CSS rules, which you are going to substitute.

Default Rules

<style>
  body { background: #FFEEDD; }
  a:link { color: #0066CC; }
  a:visited { color: #800080; }
  div { text-decoration: none; color: black; }
  ...
</style>

The default CSS rule for <div> tag:

div {

/* CSS properties produced from default paragraph style */ }

div.Normal { ... }

Note that a formatting styles defined in the main template will override any equally-named style found in subtemplates. This applies to the default paragraph style too!

3. Generated Style Sheets

Correspondingly, there are two types of style sheets:

1. Local Style Sheet
2. Global Style Sheet

Local Style Sheet

<html>
<head>
  ...
  <!-- local style sheet -->
  <style type="text/css">
    ...
  </style>
  ...
</head>
<body>
  ...
</body>
</html>

Global Style Sheet

Once the generation of all HTML files is finished, the global style sheet is printed as a separate CSS file placed in the output destination directory typically under the name 'stylesheet.css'. That CSS file is referenced from every HTML file via a <link> tag, e.g.:

<link rel="stylesheet" type="text/css" href="../../stylesheet.css">

Multiple Style Sheets

<html>
<head>
  ...
  <!-- link to the global style sheet -->
  <link rel="stylesheet" type="text/css" href="../../stylesheet.css">

  <!-- local style sheet -->
  <style type="text/css">
    ...
  </style>
  ...
</head>
<body>
  ...
</body>
</html>

Which CSS rules go where depends on the options controlling what's included in the global style sheet (i.e. CSS file). For instance, unselecting the option “Output | CSS | Generate style sheet file | Include anonymous rules” will cause all anonymous rules to be generated and stored locally by each HTML file where they are used.

By default, the global style sheet (CSS file) holds all CSS rules. That makes the generated HTML documentation most compact.

Style Sheet Structure

[Default Rules]
[Named Rules]
[Anonymous Rules]

Basically, it is because, in order to achieve the formatting effects specified in a template, several CSS rules may be applied together to the same HTML tag. At that, the properties specified in some of those rules must override the same properties specified in others. That can be achieved only by the specific ordering of the CSS rule definitions in the style sheet. See also: Appendix | Applying multiple CSS rules to the same HTML element.

The [Named Rules] section also has its own strict structure:

[Named Rules generated from Table Styles]
[Named Rules generated from Table Row Styles]
[Named Rules generated from Table Cell Styles]
[Named Rules generated from Horizontal Rule Styles]
[Named Rules generated from Paragraph Styles]
[Named Rules generated from Character Styles]
[Named Rules generated from Character Styles for hyperlinks]


4. Custom CSS Rules / CSS File

Since it is impossible to tell the HTML generator which CSS rules must be used at which output locations, the only way to apply custom CSS rules is to substitute with them those produced automatically by the generator itself. That can be done only for the rules with a constant (predictable) connection to the specific output structures, which they are applied to. That is, whenever a given template set is used, the same pieces/structures of the output will be formatted with the CSS rules associated with the same tag/class selectors. This applies only to named and default rules!

The anonymous rules, which have no predictable relationship with the output, must be preserved in any case to keep the overall formatting integrity.

Another complication is that in the style sheet named rules must be defined in a specific order, so that properties specified in one rules override properties specified in others (in case of collisions), and anonymous rules must be defined the last, because their properties must override anything else. See also: Style Sheet Structure.

Much easier is to let the generator produce the result CSS file by itself, at that, feed to it those custom rules that must substitute the generated ones. Lastly, if something extra is needed not coming from the generator at all, that can be added to the result CSS file via CSS pattern file.

How to substitute generated CSS rules with custom ones?

Find which generated rules to substitute

1. Make sure that “Output | CSS | Generate style sheet file” option is selected. That will direct all CSS rules into a single CSS file.
2. Set options:
   • Output | CSS | Generate name rules = "all"
   • Output | CSS | Generate name rules | Include descriptions = true
3. Run the generator.

/* FlexDoc styles; generated by FlexDoc SDK 1.x on Fri Jul 19 06:00:15 CEST 2013 */

/*===== NAMED RULES (generated from paragraph styles) =====*/

/*
 * Generated from style: "Derivation Tree Heading"
 * References: 220
 *
 * Formats the heading of Type Derivation Tree
 */
div.derivTreeHead { margin-bottom: .57em; }
span.derivTreeHead { font-size: 90%; font-weight: bold; color: #990000; }

...

/*===== NAMED RULES (generated from character styles) =====*/

/*
 * Generated from style: "XML Source"
 * References: 3327
 * 
 * The default font for the reproduced XML source.
 */
span.src, a.src { font-family: "Verdana", sans-serif; font-size: 83%; }

/*
 * Generated from style: "XML Source Attribute Name"
 * References: 3315
 * 
 * The font for the names of attributes in the reproduced XML source.
 */
span.srcAttrName { font-family: "Verdana", sans-serif; font-size: 83%; color: #990000; }

/*
 * Generated from style: "XML Source Attribute Name (Reserved)"
 * References: 8
 * 
 * The font for reserved attribute names in the reproduced XML source.
 * 
 * Reserved are namespace bindings (e.g. "xmlns:xs") and attributes from the XML
 * namespace (e.g. "xml:lang").
 */
span.srcAttrNameRes { font-family: "Verdana", sans-serif; font-size: 83%; color: #FF0000; }

/*
 * Generated from style: "XML Source Attribute Value"
 * References: 3307
 * 
 * The font for the values of attributes in the reproduced XML source.
 */
span.srcAttrVal, a.srcAttrVal { font-family: "Verdana", sans-serif; font-size: 70%; font-weight: bold; color: black; }

/*
 * Generated from style: "XML Source Attribute Value (Reserved)"
 * References: 8
 * 
 * The font for the values of reserved attributes in the reproduced XML source.
 * Reserved are namespace bindings (e.g. "xmlns:xs") and attributes from the XML
 * namespace (e.g. "xml:lang").
 */
span.srcAttrValRes { font-family: "Verdana", sans-serif; font-size: 70%; font-weight: bold; color: #FF0000; }

/*
 * Generated from style: "XML Source Comment"
 * References: 8
 * 
 * The font for XML source comments
 */
span.srcCom { font-family: "Courier New", monospace; font-size: 83%; color: #4D4D4D; }

/*
 * Generated from style: "XML Source Comment Markup"
 * References: 16
 * 
 * The font for XML comment markup ("<!--" and "-->") in the reproduced XML source
 */
span.srcComMrk { font-family: "Verdana", sans-serif; font-size: 83%; color: #0000FF; }

/*
 * Generated from style: "XML Source DOCTYPE"
 * References: 2
 * 
 * The font for <!DOCTYPE> declaration (except internal subset) in the reproduced
 * XML source
 */
span.srcDOCTYPE { font-family: "Verdana", sans-serif; font-size: 83%; color: #0000FF; }

/*
 * Generated from style: "XML Source Element Name"
 * References: 3963
 * 
 * The font for the names of elements in the reproduced XML source.
 */
span.srcElemName { font-family: "Verdana", sans-serif; font-size: 83%; color: #990000; }

/*
 * Generated from style: "XML Source Element Value"
 * References: 138
 * 
 * The font for the values of elements in the reproduced XML source.
 */
span.srcElemVal { font-family: "Verdana", sans-serif; font-size: 70%; font-weight: bold; }

/*
 * Generated from style: "XML Source Internal Subset"
 * References: 3
 * 
 * The font for Internal Subset (embedded in <!DOCTYPE> declaration) in the
 * reproduced XML source.
 */
span.srcIS { font-family: "Courier New", monospace; font-size: 83%; color: #0000FF; }

/*
 * Generated from style: "XML Source Markup"
 * References: 12512
 * 
 * The font for XML markup characters (such as angle brackets, quotes etc.)
 */
span.srcMrk { font-family: "Verdana", sans-serif; font-size: 83%; color: #0000FF; }

/*
 * Generated from style: "XML Source Processing Instruction"
 * References: 2
 * 
 * The font for Processing Instructions in the reproduced XML source.
 */
span.srcPI { font-family: "Verdana", sans-serif; font-size: 83%; color: #0000FF; }

...

/*===== NAMED RULES (generated from character styles for hyperlinks) =====*/

/*
 * Generated from style: "Hyperlink (blended in)"
 * References: 2370
 * 
 * Used to format hyperlinks blended into the text.
 */
a.link { text-decoration: underline; }

/*
 * Generated from style: "Hyperlink (blended in, hover)"
 * References: 28
 * 
 * Used to format completely blended-in (latent) hyperlinks.
 */
a:hover.link-hover { text-decoration: underline; }

...

/*===== ANONYMOUS RULES =====*/

div.a0, span.a0 { font-size: medium; }
div.a1 { margin-top: .67em; }
span.a2 { font-weight: bold; }
td.a3 { padding: .42em .25em .25em .25em; }
...

Provide your own declarations

As an example, suppose our goal is to change a little bit the style of XML schema documentation (generated by XSDDoc), namely the coloring scheme of:

• Reproduced XML source
• Normal hyperlinks

/* default rules for normal hyperlinks */

a:link { color: #0066CC; }
a:visited { color: #0066CC; }

/* named rules for XML source */

span.src, a.src { font-family: "Arial", sans-serif; font-size: 80%; }
span.srcMrk { font-family: "Arial", sans-serif; font-size: 80%; color: #000000; }

span.srcAttrName, span.srcAttrNameRes { font-family: "Arial", sans-serif; font-size: 80%; font-weight: bold; color: #000000; }
span.srcAttrVal, a.srcAttrVal, span.srcAttrValRes { font-family: "Arial", sans-serif; font-size: 80%; color: #0066CC; }

span.srcCom, span.srcComMrk { font-family: "Courier New", monospace; font-style: italic; font-size: 80%; color: #008800; }

span.srcElemName { font-family: "Arial", sans-serif; font-size: 80%; font-weight: bold; color: #800080; }
span.srcElemVal { font-family: "Arial", sans-serif; font-size: 80%; color: #000000; }

span.srcDOCTYPE, span.srcIS { font-family: "Courier New", monospace; font-size: 80%; font-style: italic; font-weight: bold; color: #FF0000; }
span.srcPI { font-family: "Courier New", monospace; font-size: 80%; font-style: italic; color: #CC66CC; }
span.srcCDATA, span.srcCDATAMrk { font-family: "Courier New", monospace; font-size: 80%; color: #CC0066; }

Custom default rules

html { ... }
body { ... }
a:link { ... }
a:visited { ... }
a:active { ... }
div { ... }

If you need to apply any other default CSS rules, you can do it via CSS pattern file.

Case of relative length units

• Currently, FlexDoc HTML generator uses only the following relative units:
  • percent (%) for font sizes
  • em for spacing, margins and paddings (and a few other things)
• Although, these relative units are context-dependent (that is, CSS computes property values specified in such units against the context font size inherited by the element where the property applied), that is incompatible with the most concepts, on which FlexDoc (template language) is based.

  Because of this, FlexDoc treats all CSS property values specified in relative units effectively against the document base font size. That requires periodic resetting of the context font size to the document base font size. For more details, please see: Appendix | The problem with relative length units.

  Another consequence is that the same CSS rule cannot specify both the font size and any other relative-unit properties. When it is actually needed (in the case of a named CSS rule produced from a paragraph style), such a CSS rule will be broken into two ones applied to nested HTML tags (one for paragraph and one for text). For more details, please see: Multiple named rules with the same class selector | Property conflicts caused by relative units.

• Because of the said above, make sure that when your custom CSS rule contains some length-unit properties, the generated CSS rule it substitutes also contained that kind of properties. (Note that this is specified in the corresponding template formatting style, from which the given rule was generated).

  For instance, you should avoid substituting a CSS rule without font size with the one that specifies the font size. That may result in unpredictable distortions of the entire document formatting!

Which license required?

• In case of FlexDoc/XML product line, it is the “FlexDoc/XML SDK” license.
• In case of FlexDoc/Javadoc product line, it is the “FlexDoc/Javadoc” license.

This is considered a deep customization of your generated documentation (i.e. of the doc-generator implemented by a FlexDoc template set you want to use). Moreover, if you plan to customize the generated style sheets, you will likely need also to change something in the templates themselves as well as require some special support about all that.

CSS pattern file

It may be useful when you need to add in the result style sheet some CSS rules not generated by FlexDoc at all (for instance, to format the HTML markup embedded in your descriptions/annotations).

Those CSS rule that are generated can also be substituted with your own ones using custom rule file.

...
...
/* flexdoc-styles */
...

The line '/* flexdoc-styles */' is important. All FlexDoc-generated CSS rules will be inserted in place of that comment. When it is absent, no automatically generated CSS rules will appear in the result CSS file.

This opens a possibility to use the CSS pattern file as a complete your CSS file. You just need to provide your definitions for all generated default and named CSS rules and exclude from the global style sheet all anonymous rules by unselecting the option: Output | CSS | Generate style sheet file | Include anonymous rules. See also: Style Sheet Structure.

The name of the result CSS file (generated by FlexDoc) will be the same as the name of your CSS pattern file. Thereby you can assign your own name to the result CSS file found in the generated documentation.

5. Appendix

The problem with relative length units

This creates a problem. When a CSS rule with the specified font size is applied to an HTML element, any values in relative units used within that element will be interpreted against that font size. This would make many of the generated CSS rules context-dependent, which breaks the whole idea of named rules (which are supposed to be independent of where they are used).

To work around that problem the context font size is reset to the document's base font size each time it was changed by applying a font-size-containing CSS rule and another font-size-dependent CSS rule needs to be applied within its scope. As a font size resetter, the following CSS rule is used:

div.a0 { font-size: medium; }

In a few cases, it is impossible to insert an intermediate tag with the font size resetting CSS rule. So, if some length-unit values are applied down there, they must be adjusted to the context font size.

• The item numbers must be of a certain font size.
• The list items must have a certain spacing between them.
• The content of each list item may be complex with own font sizes, spacings etc.

<html>
<head>
  ...
  <!-- style sheet -->
  <style type="text/css">
    /* the rule for the list item numbers */
    ol.list { font-family: "Verdana"; font-size: 80%; }

    /* the rule to make spacing between list items;
     we want the spacings to be exactly 1em (relative the base font size),
     but this rule will be applied in context of the 80% font size left from
     the 'list' rule (above), so the spacings are adjusted accordingly */
    li.item { margin-top: 1.25em; margin-bottom: 1.25em; }

    /* the rule for a text within the list item */
    span.text { font-family: "Arial"; font-size: 80%; }

    /* the rule for spacing between text paragraphs within the list item */
    div.spacing { margin-top: .5em; }

    /* the font size resetter rule (generated automatically) */
    div.a0 { font-size: medium; }
    ...
  </style>
</head>
<body>
  ...
  <!-- the list -->
  <ol class="list">
    <!-- a list item -->
    <li class="item">
      <!-- reset the context font size to the document's base one -->
      <div class="a0">
        <!-- first paragraph -->
        <span class="text">TEXT 1</span>
        <!-- spacing between paragraphs -->
        <div class="spacing"></div>
        <!-- second paragraph -->
        <span class="text">TEXT 2</span>
      </div>
    </li>
    ...
  </ol>
  ...
</body>
</html>

There is a new relative unit planned in CSS: the rem (for "root em"), which will be computed exactly against the document's base font size. That would save us the day! Unfortunately, that unit is not quite established yet and not supported by some browsers.

• “Output | CSS | Units” option
• Property conflicts caused by relative units
• How to substitute generated CSS rules with custom ones? | Case of relative length units

Applying multiple CSS rules to the same HTML element

The question is: When a CSS property is defined in several of those listed rules and has different values there, which of them will take effect? One could expect, it must be from the rule, whose class is listed the last. But that's wrong. Rather, that will be from the rule, which is defined the last!

For example, suppose you have two rules rule1 and rule2 defined in a style sheet like this:

<style>
  span.rule1 { color: red; }
  span.rule2 { color: blue; }
 ...
</style>

<span class="rule1 rule2"> text </span>

<span class="rule2 rule1"> text </span>