Chapter Contents

Previous

Next
The TEMPLATE Procedure

Concepts


What Is a Template Store?

A template store is a specific kind of item store (a kind of SAS file) that stores the definitions that PROC TEMPLATE creates. Definitions that SAS Institute provides are in the template store SASHELP.TMPLMST. You can store your definitions in any template store that you can write to (see PATH Statement).

A template store can contain multiple levels (also referred to as directories). When you specify a template store in the ODS PATH statement, however, you specify a two-level name that includes a libref and the name of a template store in the SAS data library that the libref references.

To view the contents of a template store in the SAS windowing environment, complete the following steps:

  1. Select

    View
    [arrow]
    Results
    from the Explorer.

  2. In the Results window, select the Results folder. With your cursor on this folder, use your right mouse button to open the Templates window.

  3. Click on the plus sign that is next to an icon to view the contents of a template store or a directory in a template store. If there is no plus sign next to the icon, double click on the icon to view the contents of that directory.

You can also use the LIST statement to view the contents of one or more template stores (see LIST Statement).


What Is the Default Style Definition Like?

The default style definition for the HTML destination is stored in STYLES.DEFAULT in the template store SASHELP.TMPLMST. You can view the style definition from the TEMPLATE window, or you can submit this PROC TEMPLATE step to write the style definition to the SAS log:

proc template;
   source styles.default;
run;

Note:   The default style definition for the Printer destination is stored in STYLES.PRINTER in the template store SASHELP.TMPLMST. This style definition is similar to STYLES.DEFAULT. In fact, it inherits most of its attributes from STYLES.DEFAULT.  [cautionend]

You may want to alter parts of the default style definition, and Modifying the Default Style Definition for the HTML Destination shows you how to do so. When you try to modify the style definition for use at your site, it is helpful to know what each style element in the style definition is for. The following table lists all the style elements in the default style definition. The indention in the table indicates the relationship between the style elements. An element that is indented inherits from the element above it and to its left. The table also provides a brief description of the purpose of each style element. An abstract style element is one that is not used to render any style element but provides a basis for one or more style elements to inherit.

Style Elements that Are Available in the Default Style definition
Style Element Description
fonts Establishes a list of fonts.
color_list Establishes a list of color names and their RGB values.
colors Associates parts of SAS output with colors from color_list.
html Provides HTML for specific parts of the output.
text Provides text for specific parts of the output.
container Abstract: provides a basis for all containers.

index Abstract: provides a basis for the contents and page files.


indexprocname Renders the procedure name in the body file.



contentprocname Renders the procedure name in the contents file.




contentproclabel Renders the procedure label in the contents file.



pagesprocname Renders the procedure name in the page file.




pagesproclabel Renders the procedure label in the page file.


indexaction Abstract: determines what happens when the mouse is positioned over a folder or item.



folderaction Determines what happens when the mouse is positioned over a folder.



itemaction Determines what happens when the mouse is positioned over an item.



procnameaction Determines what happens when the mouse is positioned over the procedure name in the table of contents.



titleaction Determines what happens when the mouse is positioned over a SAS title.


indextitle Abstract: controls the title of the contents and page files.



contenttitle Renders the title in the contents file.



pagestitle Renders the title in the page file.

document Abstract: controls the various output files.


body Renders the body file.


frame Renders the frame file.


contents Renders the contents file.


pages Renders the page file.

date Abstract: controls the contents of date fields.


bodydate Renders the date field in the body file.


contentsdate Renders the date field in the contents file.


pagesdate Renders the date field in the page file.

indexitem Abstract: controls the items in the contents and page files.


contentfolder Controls the generic folder definition in the contents file.



bycontentfolder Controls the byline folder definition in the contents file.


contentitem Renders the lowest level of the hierarchy in a contents file.


pagestitem Renders the lowest level of the hierarchy in a page file.

systitleandfootercontainer Renders the container for system headers and footers (provided by TITLE and FOOTNOTE statements or by GTITLE and GFOOTNOTE statements in combination with the NOGTITLE and NOGFOOTNOTE options in the ODS HTML statement).

titleandnotecontainer Renders the container for titles and notes that the procedure provides.

titlesandfooters Abstract: controls the text of the system titles and footers.


systemtitle Renders the text of system titles.


systemfooter Renders the text of system footers.


pageno Renders the text of the page number.


byline Renders the text of the byline.


proctitle Renders the text of titles that the procedure provides.



proctitlefixed Renders the text of titles that the procedure provides with a fixed font.

bylinecontainer Renders the container for the byline.

output Abstract: controls basic presentation of the output.


table Renders output that is a table.


batch Renders output (like lineprinter plots and calendars) that requires a fixed font.

note Abstract: controls the container for the text that precedes notes, warning, and errors from SAS.


notebanner Renders the text that precedes the contents of a note.


notecontent Renders the contents of a note.



notecontentfixed Renders the contents of a note with a fixed font.


warnbanner Renders the text that precedes the contents of a warning.


warncontent Renders the contents of a warning.



warncontentfixed Renders the contents of a warning with a fixed font.


errorbanner Renders the text that precedes the contents of an error.


errorcontent Renders the contents of an error.



errorcontentfixed Renders the contents of an error with a fixed font.


fatalbanner Renders the text that precedes the contents of a fatal error.


fatalcontent Renders the contents of a fatal error.



fatalcontentfixed Renders the contents of a fatal error with a fixed font.

cell Abstract: controls table cells.


data Renders the data in table cells.



datafixed Renders the data in table cells with a fixed font.



dataempty Renders empty table cells.



dataemphasis Renders data in table cells with emphasis.




dataemphasisfixed Renders data in table cells with emphasis and a fixed font.



datastrong Renders data in cells with more emphasis than dataemphasis.




datastrongfixed Renders data in table cells with more emphasis than dataemphasis and with a fixed font.


headersandfooters Abstract: controls table headers and footers.



header Renders the headers of a table.




headerfixed Renders the headers of a table with a fixed font.




headerempty Renders empty table headers.




headeremphasis Renders the headers of a table with emphasis.





headeremphasisfixed Renders the headers of a table with emphasis and with a fixed font.




headerstrong Renders the headers of a table with more emphasis than headeremphasis.





headerstrongfixed Renders the headers of a table with more emphasis than headeremphasis and with a fixed font.




rowheader Renders row headers.





rowheaderfixed Renders row headers with a fixed font.





rowheaderempty Renders empty row headers.





rowheaderemphasis Renders row headers with emphasis.






rowheaderemphasisfixed Renders row headers with emphasis and with a fixed font.





rowheaderstrong Renders row headers with more emphasis than rowheaderemphasis.






rowheaderstrongfixed Renders row headers with more emphasis than rowheaderemphasis and with a fixed font.



footer Renders the footers of a table.




footerfixed Renders the footers of a table with a fixed font.




footerempty Renders empty table footers.




footeremphasis Renders the footers of a table with emphasis.





footeremphasisfixed Renders the footers of a table with emphasis and with a fixed font.




footerstrong Renders the footers of a table with more emphasis than footeremphasis.





footerstrongfixed Renders the footers of a table with more emphasis than footeremphasis and with a fixed font.




rowfooter Renders row footers.





rowfooterfixed Renders row footers with a fixed font.





rowfooterempty Renders empty row footers.





rowfooteremphasis Renders row footers with emphasis.






rowfooteremphasisfixed Renders row footers with emphasis and with a fixed font.





rowfooterstrong Renders row footers with more emphasis than rowfooteremphasis.






rowfooterstrongfixed Renders row footers with more emphasis than rowfooteremphasis and with a fixed font.



caption Abstract: controls the caption field in PROC TABULATE.




beforecaption Renders captions that precede the table.




aftercaption Renders captions that follow the table.










How Are Values in Table Columns Justified?

The process of justifying the values in columns in Listing output involves the variable's format and the values of two attributes: JUST= and JUSTIFY=. It is a three-step process:

  1. ODS puts the value into the format for the column. Character variables are left justified within their format fields; numeric variables are right justified.

  2. ODS justifies the entire format field within the column width according to the value of the JUST= attribute for the column, or, if that attribute is not set, JUST= for the table. For example, if you right justify the column, the format field is placed as far to the right as possible. However, the placement of the individual numbers and characters within the field does not change. Thus, decimal points remain aligned. If the column and the format field have the same width, JUST= has no apparent affect because the format field occupies the entire column.

  3. If you specify JUSTIFY=ON for the column or the table, ODS justifies the values within the column without regard to the format field. By default, JUSTIFY=OFF.

Consider this set of values:

123.45
234.5
.
987.654

If the values are formatted with a 6.2 format and displayed in a column with a width of 6, they look like this regardless of the value of JUST= (asterisks indicate the width of the column):

******
123.45
234.50
   .
987.65

If the width of the column increases to 8, the value of JUST= does affect the placement of the values because the format field has room to move within the column.

just=left                 just=center                 just=right

********                  ********                    ********
123.45                     123.45                       123.45
234.50                     234.50                       234.50
   .                          .                            .
987.65                     987.65                       987.65
Notice that the decimal points remain aligned but that the numbers shift in relation to the column width. Now, if you add JUSTIFY=ON, the values are formatted within the column without regard to the format width. The results are as follows:
justify=on                justify=on                  justify=on
just=left                 just=center                 just=right

********                  ********                    ********
123.45                     123.45                       123.45
234.50                     234.50                       234.50
.                            .                               .
987.65                     987.65                       987.65

The HTML and Printer destinations always justify the values in columns as if JUSTIFY=ON.


How Do Style-Definition Inheritance and Style-Element Inheritance Work?

When you use PROC TEMPLATE to create style definitions, it is important to understand inheritance. There are two types of inheritance: style-definition inheritance and style-element inheritance. Recall that a style definition is composed of style elements (see Overview). A style definition is created with the DEFINE STYLE statement and its substatements and attributes. Style elements are created with the STYLE and REPLACE statements and their attributes.

The PARENT= attribute, used with the DEFINE STYLE statement, controls style-definition inheritance. When you specify a parent for a style definition, all the style elements and attributes and statements that are specified in the parent's definition are used in the new definition unless the new definition overrides them.

The STYLE and REPLACE statements, used with the DEFINE STYLE statement, control style-element inheritance. They augment or override the attributes of a particular style element. You can use the STYLE statement in either a style definition that has no parent or a style definition that has a parent. However, you can use the REPLACE statement only in a style definition that has a parent.

This section explains style-definition inheritance and style-element inheritance, beginning with the simpler case of style-element inheritance in a style definition that has no parent and progressing to more complicated cases. The focus here is on PROC TEMPLATE and the DEFINE STYLE statement, so only the PROC TEMPLATE code that creates the style definitions appears in the text. However, in order to produce the HTML output that is shown here, it is necessary to create a customized table (with the DEFINE TABLE statement in PROC TEMPLATE) and to bind that table to a data set (with the TEST statement in PROC TEMPLATE). The complete code that produces each piece of output is in Programs that Illustrate Inheritance.

Style Element Inheritance in a Style Definition with No Parent

When you create a style definition, you use a STYLE statement to create each style element in the definition. For instance, the following PROC TEMPLATE step creates a style definition, concepts.style1, that contains one style element, celldatasimple. This style element uses the Arial font face, a light blue background, and a white foreground:

Creating a Style Definition with One Style Element
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue foreground=white; end; run;

The style element celldatasimple does not inherit any attributes from any other element. It is simply created with these three attributes. All other attributes are set by the browser when a table is rendered in HTML with this style definition. The following HTML output uses this style definition:

Using a Style Definition with One Style Element
The style definition that this HTML output uses contains only one style element: celldatasimple. All three columns use this style element. celldatasimple uses these attributes:
FONT_FACE=arial
BACKGROUND=very light vivid blue
FOREGROUND=white.
[HTML Output]

Now, suppose that you want an additional style element for cells. This style element emphasizes the data by using an italic font. It uses the same font face and background color as celldatasimple, but it uses blue instead of white for the foreground color. You can create the new style element completely on its own:


Creating a Second Style Element Independently
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue; foreground=white style celldataemphasis / font_face=arial background=very light vivid blue foreground=blue font_style=italic; end; run;
Alternatively, you can create celldataemphasis from celldatasimple:

Creating a Second Style Element from the Existing Style Element
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=blue font_style=italic; end; run;

The PROC TEMPLATE steps in Creating a Second Style Element Independently and Creating a Second Style Element from the Existing Style Element produce identical results. In both cases, celldatasimple contains these attributes:

celldataemphasis has these attributes:

The following HTML output uses this style definition:

A Style Definition with Two Style Elements
The style definition that this HTML output uses contains two style elements: celldatasimple and celldataemphasis. The columns for Country and Kilotons use celldatasimple. The column for grain uses celldataemphasis. [HTML Output]

Although the PROC TEMPLATE steps in Creating a Second Style Element Independently and Creating a Second Style Element from the Existing Style Element produce identical HTML output, there is an important difference between them. In the Example 5.8, the program does not use style-element inheritance. celldataemphasis is created independently of celldatasimple, so a change to celldatasimple does not affect celldataemphasis. For example, if you change the STYLE statement that creates celldatasimple so that the font face is Times, Creating a Second Style Element Independently creates celldataemphasis with Arial as the font face.

Changing the Font Face in Only One Style Element
proc template; define style concepts.style1; style celldatasimple 'The change to FONT_FACE= does not affect celldataemphasis.' / font_face=times background=very light vivid blue foreground=white; style celldataemphasis / font_face=arial background=very light vivid blue foreground=blue font_style=italic; end;

The following HTML output uses this style definition:

Changing the Font Face in Only One Style Element
Here, the font face in the style element celldatasimple, which is used for the first and third columns in the HTML output, has changed from Arial to Times. However, celldataemphasis, which is used for the second column, still uses the Arial font face because it does not inherit any attributes from celldatasimple. [HTML Output]

On the other hand, if you change the font face for celldatasimple from Arial to Times in Creating a Second Style Element from the Existing Style Element, celldataemphasis does use the Times font face because in this PROC TEMPLATE step, celldataemphasis inherits all the attributes from celldatasimple.

Changing the Font Face in the Parent and Child Style Elements
proc template; define style concepts.style1; style celldatasimple 'The change to FONT_FACE= is passed to celldataemphasis, which inherits all the attributes of celldatasimple.' / font_face=times background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=blue font_style=italic; end; run;

The following HTML output uses this style definition:

Inheriting a Change to a Style Element
In this case, the change to the Times font face in celldatasimple is inherited by celldataemphasis. Both style elements use the Times font face.The only attributes that differ between the two style elements are ones that were explicitly redefined in the definition of celldataemphasis (the FOREGROUND= attribute, which was changed, and the FONT_STYLE= attribute, which was added). The columns for Country and Kilotons use celldatasimple. The column for Grain uses celldataemphasis. [HTML Output]

Let's add a third style element to the style definition. This style element further emphasizes the data by using a large, bold, italic font. Again, you can create the new style element from scratch, or you can derive it from either of the other style elements. The following program creates celldatalarge from celldataemphasis:

Creating the Style Element celldatalarge
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=blue font_style=italic; style celldatalarge from celldataemphasis / font_weight=bold font_size=5; end; run;

HTML output that uses the new style definition appears in Adding the Style Element celldatalarge. The style elements celldatasimple and celldataemphasis have not changed. celldatasimple has these attributes:

celldataemphasis has these attributes:

The new style element, celldatalarge, has these attributes:

Adding the Style Element celldatalarge
The style definition that this HTML output uses contains three style elements: celldatasimple, celldataemphasis, and celldatalarge. The column for Country uses celldatasimple. The column for Grain uses celldataemphasis. The column for Kilotons uses celldatalarge. [HTML Output]

In this case, celldatalarge inherits style attributes from celldataemphasis, and celldataemphasis inherits from celldatasimple. If you change the font face in celldatasimple, the font face in both other style elements changes. If you change the font style or foreground color in celldataemphasis, the font style or foreground color in celldatalarge also changes. Changes to celldatalarge affect only celldatalarge because no style element inherits from it.

The following points summarize style-element inheritance in a style definition that does not have a parent:


Style-Definition Inheritance

If you use the PARENT= attribute in a style definition, the new style definition inherits the entire style definition. You can then add new style elements or modify style elements that are inherited from the parent.

Let's continue with concepts.style1, which was created in Style Element Inheritance in a Style Definition with No Parent. The following program creates a new style definition, concepts.style2, which inherits the entire style definition from its parent, concepts.style1. At this point, the two style definitions are identical:

Using Style-Definition Inheritance to Create a New Style Definition
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=blue font_style=italic; style celldatalarge from celldataemphasis / font_weight=bold font_size=5; end; run; proc template; define style concepts.style2; parent=concepts.style1; end; run;

For this new style definition to be useful, it should differ from its parent. There are several ways to change the new style definition. The following section explains style-element inheritance in a style definition that has a parent.

Style-Element Inheritance in a Style Definition with a Parent

Let's start by adding a new style element to concepts.style2. The following program adds celldatasmall, a style element that does not exist in the parent style definition. Its definition is not based on any other style element.


Creating a Style Element Independently in a Style Definition with a Parent
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=blue font_style=italic; style celldatalarge from celldataemphasis / font_weight=bold font_size=5; end; run; proc template; define style concepts.style2; parent=concepts.style1; style celldatasmall / font_face=arial background=very light vivid blue foreground=blue font_style=italic font_weight=bold font_size=2; end; run;

If you look at the attributes for celldatasmall, you can see that they match the attributes for celldatalarge in the parent style definition except for FONT_SIZE=. Another way to create this new style element, then, is to create it from celldatalarge. You do this just as you did when you created a style element in a style definition that didn't have a parent:


Creating a New Style Element from a Style Element in the Parent Style Definition
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=blue font_style=italic; style celldatalarge from celldataemphasis / font_weight=bold font_size=5; end; run; proc template; define style concepts.style2; parent=concepts.style1; style celldatasmall from celldatalarge / font_size=2; end; run;
When you specify FROM in the STYLE statement in a style definition with a parent, PROC TEMPLATE first looks for the style element that you specify in the child style definition. If no such style element exists, it looks in the parent (and continues looking up through parents as far as is necessary or possible). In this case, because no style element called celldatalarge exists in concepts.style2, PROC TEMPLATE uses the style element from the parent style definition.

The style definition concepts.style2 that is produced in Creating a Style Element Independently in a Style Definition with a Parent is identical to the one that is produced in Creating a New Style Element from a Style Element in the Parent Style Definition. In both cases, the style element celldatasmall has these attributes:

The following HTML output uses concepts.style2:

Creating a New Style Element from a Style Element in the Parent Style Definition
The style definition concepts.style2 contains four style elements. The style definition inherits celldatasimple, celldataemphasis, and celldatalarge from the parent style definition, concepts.style1. The column for Country uses celldatasimple. The column for grain uses celldataemphasis. The first column for Kilotons uses celldatalarge. The fourth style element in the new style definition is celldatasmall. This style element is created in concepts.style2. It inherits from celldatalarge in concepts.style1. The fourth column, which repeats the values for Kilotons, uses celldatasmall. [HTML Output]

Although Creating a Style Element Independently in a Style Definition with a Parent and Creating a New Style Element from a Style Element in the Parent Style Definition produce the same style definition for concepts.style2, they will produce different style definitions if you change the definition of celldatalarge in the parent (or the definition of any of the style elements that celldatalarge inherits from). In Creating a Style Element Independently in a Style Definition with a Parent, changes to celldatalarge do not affect celldatasmall because celldatasmall is created independently in the new style definition. It does not inherit from any style element in the parent style definition.

On the other hand, in Creating a New Style Element from a Style Element in the Parent Style Definition , changes to celldatalarge in the parent style definition do affect celldatasmall because celldatasmall inherits (and adds to) the attributes of celldatalarge. Similarly, changes to other style elements in the parent style definition do not affect celldatasmall in the Creating a Style Element Independently in a Style Definition with a Parent, but they do in the Creating a New Style Element from a Style Element in the Parent Style Definition.

For example, the following program is based on Creating a New Style Element from a Style Element in the Parent Style Definition. It changes the font face in celldatasimple from Arial to Times. All the other style elements, in both the parent and the child style definitions, inherit this change. The program also changes the foreground color of celldataemphasis to black. The style elements celldatalarge (in the parent style definition) and celldatasmall (in the new style definition) both inherit this foreground color.

Inheriting Changes from Style Elements in the Parent Style Definition
proc template; define style concepts.style1; style celldatasimple / font_face=times background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=black font_style=italic; style celldatalarge from celldataemphasis / font_weight=bold font_size=5; end; run; proc template; define style concepts.style2; parent=concepts.style1; style celldatasmall from celldatalarge / font_size=2; end; run;

The following HTML output uses this new style definition:

Inheriting Changes to the Parent Style Definition
Changes to the style elements in the parent style definition are passed to style elements that inherit from these elements in both the parent and the child style definitions. [HTML Output]

Creating a new style element in a style definition that has a parent is not very different from creating a new style element in a style definition that does not have a parent. The only difference is that the style element that you specify with FROM in the STYLE statement can be in either the parent or the child style definition.

When you create a new style definition from a parent definition you can, in addition to adding new style elements, modify existing style elements. There are two ways to do this. One way uses the STYLE statement to make the change only to the style element that you specify. The other way uses the REPLACE statement to make the change to the style element that you specify and to all the style elements that inherit from that element.

The following program uses the STYLE statement to redefine the style element celldataemphasis in concepts.style2. It changes the background color to white:

Redefining a Style Element with the STYLE Statement
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=blue font_style=italic; style celldatalarge from celldataemphasis / font_weight=bold font_size=5; end; run; proc template: define style concepts.style2; parent=concepts.style1; style celldataemphasis from celldataemphasis / background=white; style celldatasmall from celldatalarge / font_size=2; end; run;
In this case, celldataemphasis in concepts.style2 initially inherits all the attributes of celldataemphasis in concepts.style1 because it is created from this style element. The inherited attributes are

The STYLE statement that creates celldataemphasis in the new style definition changes the background color to white. The background color is the only difference between the celldataemphasis style elements in the parent and child style definitions.

But, what about celldatalarge? celldatalarge is not redefined in concepts.style2. It is defined only in the parent style definition, where it inherits all the attributes of celldataemphasis. So the question is, which celldataemphasis does it inherit from-- the one in the parent style definition or the one in the child style definition? Does it get the white background or not?

The answer is that it does not. You can envision the process this way. The STYLE statement that creates celldataemphasis in the new style definition, affects only those style elements that inherit from celldataemphasis and that are defined in the new style definition. Because celldatalarge is defined only in the parent style definition, it does not inherit the changes that are specified in the child. Similarly, celldatasmall does not inherit the white background because it inherits from celldatalarge. The following HTML output uses this version of concepts.style2:

Using the STYLE Statement to Alter an Existing Style Element in the Child Style Definition
A style element that is defined with the STYLE statement in the child style definition does not pass its attributes to style elements that inherit from the like-named style element in the parent style definition. In this case, the change of the background color for celldataemphasis is made in the child style definition. The new background color is not inherited by celldatalarge because although it inherits from celldataemphasis, it is defined in the parent style definition, not the child definition. Nor is the change inherited by celldatasmall, which inherits its attributes from celldatalarge and from the parents of celldatalarge, which include celldataemphasis (as defined in the parent style definition) and celldatasimple. [HTML Output]

But, suppose that you want to pass the white background from celldataemphasis on to celldatalarge even though it is defined only in the parent style definition? There are two ways to make this sort of change. The first is simply to redefine celldatalarge in the new style definition with a STYLE statement:

Redefining a Style Element without Inheritance
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=blue font_style=italic; style celldatalarge from celldataemphasis / font_weight=bold font_size=5; end; run; proc template: define style concepts.style2; parent=concepts.style1; style celldataemphasis from celldataemphasis / background=white; style celldatalarge from celldataemphasis / font_weight=bold font_size=5; style celldatasmall from celldatalarge / font_size=2; end; run;

In this case, when PROC TEMPLATE processes the STYLE statement that creates celldatalarge, it looks for a style element named celldataemphasis to inherit from. Because there is such a style element in the child style definition, PROC TEMPLATE uses that style element. (If there were no such element in the new style definition, PROC TEMPLATE would look for one in the parent and use that one.) Therefore, celldatalarge inherits the new definition of celldataemphasis, which includes the white background. Similarly celldatasmall, which now inherits from celldatalarge in the child style definition, inherits the white background.

This method works fine for a few style elements. However, if a large number of style elements are inherited from celldataemphasis, it would be time-consuming to redefine all of them in the child style element.

Fortunately, there is a way to redefine celldataemphasis so that the changes are passed on to style elements that inherit from it. PROC TEMPLATE's flexibility allows you to choose whether you want to pass the new style attributes on to descendants or not.

If you want to make a change that "ripples" through to the style elements that are defined in the parent and that inherit from the style element that you redefine in the child style definition, use the REPLACE statement. You can only use the REPLACE statement if you have specified a parent style definition. The following program changes the background color of celldataemphasis with a REPLACE statement. You can think of this REPLACE statement as replacing the statement that defines the like-named style element in the parent style definition. The REPLACE statement doesn't actually change the parent style definition, but PROC TEMPLATE builds the child style definition as if it had changed the parent.

Redefining a Style Element with the REPLACE Statement
proc template; define style concepts.style1; style celldatasimple / font_face=arial background=very light vivid blue foreground=white; style celldataemphasis from celldatasimple / foreground=blue font_style=italic; style celldatalarge from celldataemphasis / font_weight=bold font_size=5; end; run; proc template: define style concepts.style2; parent=concepts.style1; replace celldataemphasis from celldatasimple / foreground=blue font_style=italic background=white; style celldatasmall from celldatalarge / font_size=2; end; run;

This is how PROC TEMPLATE constructs concepts.style2:

  1. The PARENT= option makes concepts.style1 the basis of the new style definition. The new style definition contains all the style elements that the parent contains: celldatasimple, celldataemphasis, and celldatalarge.

  2. The new style definition does nothing to celldatasimple. Therefore, in concepts.style2, celldatasimple is the same as it is in concepts.style1.

  3. The REPLACE statement essentially replaces the definition of celldataemphasis in concepts.style1 while concepts.style2 is being created. (It does not really alter concepts.style1, but concepts.style2 is created as if it had.) Thus, not only does celldataemphasis now exist in concepts.style2, but also every style element that concepts.style2 inherits from concepts.style1 is based on the replaced definition.

A description of each style element in concepts.style2 follows:
celldatasimple
is not redefined in concepts.style2. Nor does it inherit from any other style element. Therefore, it has the same attributes as celldatasimple in concepts.style1 does:

celldataemphasis
is defined in concepts.style2. It inherits from celldatasimple, so initially it has these attributes:

However, the REPLACE statement that creates celldataemphasis specifies a foreground color, a background color, and a font style. The foreground and background color specifications override the inherited attributes. Therefore, the final list of attributes for celldataemphasis is

celldatalarge
is not redefined in concepts.style2. Therefore, concepts.style2 uses the same definition as concepts.style1 uses. The definition of celldatalarge is from celldataemphasis. Because celldataemphasis was created in concepts.style2 with a REPLACE statement, celldatalarge inherits the following attributes from the replaced definition of celldataemphasis:

The definition of celldatalarge adds these attributes:

celldatasmall
exists only in concepts.style2. It is created from celldatalarge. PROC TEMPLATE first looks for celldatalarge in concepts.style2, but because it doesn't exist, it uses the definition in the parent style definition. celldatasmall is, therefore, just like celldatalarge except that the font size of 2 replaces the font size of 5.

The following HTML output uses this new style definition:

Using the REPLACE Statement to Alter a Style Element and Its Children
[HTML Output]

The following points summarize style-element inheritance in a style definition that has a parent:


Chapter Contents

Previous

Next

Top of Page

Copyright 1999 by SAS Institute Inc., Cary, NC, USA. All rights reserved.