CSS Data Viewer Styling (Concept)

⚠	This article was migrated from an older version and has not been updated for the current version of Grooper. This tag will be removed upon article review and update.

This article is about the current version of Grooper.

Note that some content may still need to be updated.

2025

2023

CSS Data Viewer Styling refers to using CSS to custom style the Review activity's Data Viewer interface. This gives you a great deal of control over a data_table Data Model's appearance and layout during document review.

You may download and import the files below into your own Grooper environment (version 2023). The first contains a Project with several Content Models used as examples throughout this article. The second contains some example Batches of sample documents.

😎	BIS team member Steven Rotelli has created a custom "boilerplate" CSS file that is designed to be used for any Data Model. It is a robust example of what you can do with CSS styling. You can download this CSS file at the following GitHub repo: https://github.com/StevenRotelli/GrooperCSS

About

CSS is a style sheet language used to define how HTML elements appear visually. CSS style sheets are ubiquitous in the world of web design and development. Fonts, headers, and container elements can be styled to make a web page more visually appealing and easier to read. This content is separated and formatted on a web page using a CSS file.

In Grooper, you can style your Data Model with custom CSS, changing how it appears during the Review activity (and previewed in the Design page). If you are using the Web Client, elements in your Data Model (Data Fields, Data Sections, etc.) are all rendered as some combination of HTML elements themselves when viewed over a browser. You can style how these elements are presented using CSS. This gives you a great deal of control over what you and your reviewers see in the Data Viewer during the Review activity.

FYI

The Review activity allows users to review various aspects of Grooper's automated document processing. What users review and how document content is presented is controlled by whichever Review Viewer UI the user is using.

Extracted document data is always reviewed using the Data Viewer interface.
All CSS styling done to your Data Model will be reflected to the user in the Data Viewer and only in the Data Viewer.
Because CSS styling only pertains to the Data Viewer, this article may use the terms Review Viewer and Data Viewer interchangeably.

Example Data View with no CSS

Example Data View with custom CSS

Data Elements are styled by editing a CSS file found on the Data Model.

First select the Data Model you wish to style.
You can then edit a CSS file using the Style Sheet property.
- Press the ellipsis button at the end of the property to bring up the Style Sheet editor.

Using the Style Sheet editor, you can enter as many CSS rules to style the Data Model as you need.
- When possible, a CSS code completion window will pop up as you type, allowing you to select from a list of available elements, classes, properties, and certain values.

CSS may also be edited at the Data Section and Data Table level.
You will find these Data Elements also have a Style Sheet property.

Editing CSS at the Data Section and Data Table level can be particularly helpful when dealing with larger Data Models with multiple nested levels in their hierarchy. We will discuss this further in the Global Element Styling VS Local Element Styling section of this article.

CSS Basics

CSS styles webpage elements by defining a series of rules. Each rule defines how an HTML element looks: its text, its colors, its margins on the page, its alignment with other elements, and more.

In our case, the HTML elements we're working with correspond to our Data Model's Data Elements. The Data Fields, Data Sections, and Data Tables in the Data Model are rendered in a browser by a combination of HTML elements and their sub-elements. Each kind of Data Element has a corresponding customizable CSS class.

For example, when a user operates the Data Viewer in the Review activity and looks at a Data Field, they're really seeing three total HTML elements.

A parent div element, with a DataField class.
A child label element, corresponding to the Data Field's text label.
A child input element, corresponding to the editable text box that holds the Data Fields extracted and/or user entered data.

Each CSS rule consists of two parts:

A selector.
- This points to the HTML element you want to style.
A declaration block.
- This defines one or more style declarations, the specific ways you want the element to look.
- Declaration blocks are surrounded by curly braces.
- Multiple declarations are separated with semicolons.

Remember, a Data Field is represented in HTML as an element with two child elements:

A "label" element, representing the field's label.
An "input" element representing the entry value textbox.

When styling Data Fields, it's important to understand which HTML element you want to style.

Do you want to style the Data Field's label? You'd use label as your selector.
Do you want to style the Data Field's input box? You'd use input as your selector.
Do you want to style the larger element housing both the Data Field's label and input box? You'd use .DataField as your selector.

With no CSS applied, Data Models look pretty basic in the Review application. This is our blank canvas we start with. Using CSS, we can customize the look and feel of this user interface.

For example, say we want to change the font color and size of the Data Fields in our Data Model. We can do that with CSS. If we added the following CSS rule to our Data Model's Style Sheet, this would be the result:

label {
  color: rgb(248,148,32);
  font-size: 18px;
}

The selector label defines what element we want to style.

All label elements in the Data Viewer review panel.

The declaration block defines how we want to style the element.

color: rgb(248,148,32) changes the font color to "Grooper orange", using the RGB color value.
font-size: 18px changes the font's size to 18 pixels high.
Each declaration is separated from the next by placing a semicolon (;) at the end.

Notice the CSS rule only applied to what we told it to apply to: the Data Fields' labels.

No styling was applied to the:

Data Field's input box.
Data Section and Data Table caption text
- Such as this label for the "Address Info" Data Section
Data Table's Data Column header labels.

We would need to make separate CSS rules, selecting these corresponding HTML elements to style them as we wish.

FYI

Selector specificity is an important concept in CSS.

Technically, .DataField label is a more specific selector than just label. The selector .DataField label uses something called a "combinator" to select only child label elements under a parent HTML element with a DataField class. Therefore, it would prevent ambiguous selection of other label elements that are not children of DataField HTML elements.

However, due to how Grooper merges a Data Model's Style Sheet with the main Web Client's CSS file, you are generally safe simply using the label selector as a shortcut when you want to style all Data Field labels the same way.

For more information on selectors, combinators, scope and specificity, please visit the #Styling Scope: Selecting Data Elements portion of this article.

A Common Example: Increasing a Data Field's Label Width

By default, a Data Field's input box is jammed right up against its label in the Data Viewer's screen. Nearly all Grooper users are going to want to space things out a little better. This will make the Data Model more readable, ultimately making your reviewers' job easier.

It's not just about making things "look good".
If the Data Model is easier to read, it's easier to understand. This makes the Review experience more efficient, ultimately making the process quicker and even preventing costly data entry errors.

A common CSS rule added to the Style Sheet will be one that increases the width of all Data Field labels.

Here, we've changed the CSS to increase the width of all Data Field labels in the Data Model to 140 pixels wide, using the following rule:

label {
  width: 140px;
}

Now, the label widths for all Data Fields have been lengthened to 140 pixels. As a result, the Data Model is much easier to read and interact when operating the Data Viewer during a Review activity.

Styling Scope: Selecting Data Elements

In the previous examples, we styled Data Field labels in a "global" manner. The CSS rule was applied to all Data Field labels in the Data Model. Sometimes we want to be more specific. We may want to narrow a rule's scope so it is applied to some elements, but not others.

Narrowing down the styling scope is done using one (or both) of the following methods:

Selecting a specific Data Element using it's name.
- For example, selecting and styling a Data Field named "Employee Name" rather than all Data Fields.
Selecting a Data Element's children or sibling elements.
- For example, selecting and styling Data Fields in a Data Section rather than all Data Fields.
- This is done using what are called "combinators" in CSS.

Styling Named Elements

Imagine you have a specific Data Field you want to draw your users attention to. This may be a more "important" field according to some process if your organization that you really want them to pay attention to. One thing you could do is change the label's color to make it more distinct from the other fields in your Data Model.

To do this, you would select the specific element by name, rather than selecting all Data Fields.

Let's say "Employee Name" is a critical field for this Document Type's Data Model and we want to visually highlight that in some way during Review.

We're going to style just this Data Field with CSS. All we need to do is select the Data Field by name. Instead of using label as the selector, we will use the specific Data Field's name.

Specific data elements are selected simply by entering its name with any space characters replaced with underscores.

i.e. .Data_Element_Name

The following CSS rule makes only the "Employee Name" field's label appear orange.

.Employee_Name label {
  color: rgb(248,148,32);
}

Selector Specificity

Please note more specific rules always "win out". If multiple rules are written at larger or narrower scopes, the style rule with the narrowest scope will always be applied.

This rule has a larger scope, applying to all Data Fields' labels.
- The rule adjusts the label widths to 140 pixels wide and changes their color to "bisque".

label {
  width: 140px;
  color: Bisque;
}

This rule has a narrower scope, applying only to the "Employee Name" Data Field.
- The rule adjusts the label's color to orange.

.Employee_Name label {
  color: rgb(248,148,32);
}

Since .Employee_Name label is a more specific/narrower selector, its color styling is applied. The resulting text is orange and not bisque.

Also note the width declaration assigned using the larger scope label selector is still applied.

The .Employee_Name label declaration block said nothing about how to style the width.
Thus, the styling fell back on what was described by the label selector with the larger scope.

Selecting Multiple Elements

You can select and style multiple elements by creating a comma separated list of elements in the selector.

Let's say we wanted to make the "Employee Name", "Hire Date", and "Job Title" Data Fields' labels orange. We don't have to write out three separate CSS rules. Rather we can use a single rule, separating multiple selectors with a comma.

The CSS rule below will do the trick:

.Employee_Name label,
.Hire_Date label,
.Job_Title label {
  color: rgb(248,148,32);
}

You can also list elements horizontally, the two CSS rules below will operate identically.

Horizontal List

.Employee_Name label, .Hire_Date label, .Job_Title label {
  color: rgb(248,148,32);
}

Vertical List

.Employee_Name label,
.Hire_Date label,
.Job_Title label {
  color: rgb(248,148,32);
}
}

However, most would agree a vertical comma separated list of selectors is more readable.

Intro to Combinators

Styling child and sibling elements can be a great way to add more specificity to how you want to style various Data Elements in your Data Model. Child and sibling elements are selected in CSS using a "combinator".

A combinator explains the relationship between selectors. A combinator character is placed between selectors to define the relationship.

i.e. <element1><combinator><element2>

There are four combinators in CSS:

- All descendant children selector
> - Immediate children selector
+ - Adjacent (meaning "first immediately following") sibling selector
~ - General (meaning "all following") sibling selector

We've actually already used a combinator in this article (the descendant children selector) when styling Data Field labels.

Remember, a Data Field is represented on webpages as an element that contains two child elements:

A "label" element
An "input" element

Earlier, we styled the color of the "Employee Name" Data Field's label using the following CSS rule:

.Employee_Name label {
  color: rgb(248,148,32);
}

The space character between .Employee_Name and label is the "descendant children selector". By selecting .Employee_Name label, we were selecting the child label elements of the Employee_Name element (i.e. the Data Field HTML element with the Employee_Name class).

This means two things:

Any styling we applied was done not to the parent Employee_Name element (representing the whole "Employee Name" Data Field), but instead all descendant children label elements (representing the "Employee Name" Data Field's label).
The only label elements selected were children of the Employee Name element. No other label elements were styled that way.

Combinators, like the descendant children selector, give us a variety of ways to craft highly specific selectors, leading to highly specific rules for a subset of elements.

FYI

While technically .DataField label selects all descendant label elements, .DataField elements only ever have one child label element.

Next, we'll look at other ways to use combinators.

Styling Descendant Child Elements

By far, the most common combinators you will likely use are the children combinators. This will allow you (among other things) to utilize Data Sections in ways to define styles for a particular collection of Data Elements distinct from the Data Model as a whole or Data Elements in other Data Sections.

The (a single space character) selects all descendant children.
The > selects only immediate children.

Imagine you have a collection of Data Fields and Data Sections in your Data Model. Some Data Fields are at the root of the Data Model. Others are children of a Data Section.

Furthermore, imagine you want to style only Data Fields in a specific Data Section. We can do this with the descendant children ( ) and/or the immediate children (>) combinator.

For example, let's say we want to style all the Data Field label elements in the "Address Info" Data Section. We could use the following selector:

.Address_Info label

This uses the descendant children combinator to select all child Data Field HTML elements nested under the "Address Info" Data Section's HTML element.

The space character is actually doing something! It's not just there to look pretty. A space between HTML elements or class names will select all children elements of the given type at any descendant level in the parent element's hierarchy.
- It doesn't matter if the child is at the first level below the parent, the second, the fifth or the fiftieth. For the descendant combinator , it will select them all.

Descendant Children Combinator

Say we want to recolor the labels for Data Fields in the "Address Info" Data Section. We can do that easily with the following CSS rule:

.Address_Info label {
	color: rgb(248,148,32);
}

See here, only the Data Fields in the "Address Info" Data Section had their label text colored orange.

The selector .Address_Info label, selected all child label elements in the .Address_Info element.

It is the space character ( ) between .Address_Info and label, dictating all descendant children should be selected.

Keep in mind, the descendant children combinator selects all children elements of the parent element. This may be what you want to do. It may not. It's important to realize what's going to happen, especially with larger Data Models with more complex Data Element hierarchies.

Let's say we want to style all Data Field labels in the "Personal Info" Data Section, including those in its child "Address Info" section.

The descendant children combinator ( ) is specifically designed for this situation.

The selector .Personal_Info label will travel down the HTML element hierarchy and select any label elements contained within the Personal_Info element.

The following rule colors all Data Field labels in the "Personal Info" Data Section orange.

.Personal_Info label {
  color: rgb(248,148,32);
}

Notice the "GUID" field and all fields in the "Previous Employment" Data Section are left unaffected. Why?

They are not children of the "Personal Info" Data Section.
Therefore, their HTML elements are not children of the Personal_Info class.
Therefore, their label elements are not selected by the selector (.Personal_Info label).

FYI

Due to how the descendant combinator works, the following selectors will behave identically.

.Personal_Info label
.Personal_Info .DataField label

Technically speaking, #2 is more specific.

It first selects all DataField elements that are children of the Personal_Info element.
Then, it selects all label elements that are children of the selected DataField elements.

In this case, the specificity is redundant. #1 functionally does the same thing.

It selects any child label elements in the Personal_Info element, including those that are children of DataField elements.

Styling Immediate Children Combinator

What if this isn't what you want to do? What if you don't want to select all descendant children, but only those that are at the root of an HTML element?

For example, what if you only want to style Data Field labels at the root of the "Personal Info" Data Section and leave any further descendant labels in the "Address Info" Data Section alone?
This is what the "immediate children" combinator (>) is for.

The immediate children combinator > selects a smaller scope of an element's children, namely only its immediate children.

We can use the immediate children combinator to select Data Fields that are immediate children of of the "Personal_Info" Data Section. Put another way, only Data Fields at the first level of the "Personal Info" Data Section will be styled.

The "Employee Name" Data Field is an immediate child. It will be styled.
- So are "DOB", "SSN", and "Hire Date". They will be styled too.
The "Hire Date" and "Marital Status" Data Fields are immediate children. They be styled.
- Just because they come after a Data Section sequentially doesn't mean they aren't immediate children. They are still in the first level of the "Personal Info" Data Section.

The fields in the "Address Info" Data Section ("Street Address" "City" "State" and "Zip") are descendant children further on down the object hierarchy. They will not be styled.
Fields outside the child scope, such as the siblings like the "GUID" Data Field and children of other elements such as the Data Fields in the "Previous Employment" Data Section, will also not be styled (just as they were not styled when using the descendant children selector).

Can we just swap combinators and use and use instead of >? In other words, will this rule work?

.Personal_Info > label {
	color: rgb(248,148,32);
}

NO. Not quite. At least not in this case. This CSS rule would select nothing.

Why? The label HTML element is not an immediate child of the Personal_Info HTML element.

The label elements are desendant grandchildren of the Personal_Info element.
The label elements are children of the DataField elements.
- This makes them descendant grandchildren of the Personal_Info element.
However, the DataField elements for Data Fields at the root of the "Personal Info" Data Section are immediate children.

We can use the following rule with the selector .Personal_Info > .DataField label to accomplish our goal:

.Personal_Info > .DataField label {
	color: rgb(248,148,32);
}

This rule will first select only immediate DataField children of the Personal_Info element. See this portion of the selector in bold below.

.Personal Info > .DataField label

Then, it will select all label children of DataField elements. See this portion of the selector in bold below.

Personal Info > .DataField label
- FYI: Since a DataField's label element is itself an immediate child, .DataField > label would work identically.

As a result, only Data Fields at the root of the "Personal Info" Data Section are selected and have their labels colored.

FYI

The spaces on either side of the > combinator are simply added to increase readability.

The following selectors would work identically:

.Address_Info > .DataField label
.Address_Info>.DataField label

⚠

A Data Section is fundamentally a container for other Data Elements. Thus, DataSection elements only have five meaningful types of immediate children:

A single h2 element with a caption class representing the Data Section's name.
A div element with a DataField class representing any Data Fields in the Data Section.
A div element with a DataTable class representing any Data Tables in the Data Section.
A div element with a DataSection class representing any single instance Data Sections in the Data Section.
A div element with a DataGridCollection class representing any multi-instance Data Sections in the Data Section.

Take extra care when styling elements in a Data Section and using the > combinator to ensure you select the correct immediate child first in your selector.

Styling Sibling Elements (Uncommon)

Less commonly, you may want to style sibling elements using the sibling combinators. This is a way of styling sibling Data Elements (existing in the same level of your Data Model's hierarchy) that come after a selected element.

The + selects "adjacent" siblings, selecting a single element after a specified element.
- Put another way, the first instance of an element after a specific element.
The ~ selects "general" siblings, selecting any and all elements after a specified element.
- Put another way, all instances of an element after a specific element.

For example, take the "Address Info" Data Section in the Data Model we've been using.

"Address Info" has a sibling relationship with all Data Elements at the same level in the Data Model.
"Address Info" has a parent-child relationship with every Data Element it contains.

There are two sibling Data Fields that follow the "Address Info" Data Section:

"Hire date"
"Marital Status"

The adjacent combinator + would allow us to select and style the first Date Field after the "Address Info" section. The general sibling combinator ~ would select and style all Data Fields after the "Address Info" section.

.Address_Info + .DataField will select only the first subsequent sibling DataField element.
- Only "Hire Date" would be selected.
.Address_Info ~ .DataField will select all subsequent sibling DataField elements.
- Both "Hire Date" and "Marital Status" would be selected.

For example, the following CSS rule uses the adjacent sibling selector.

.Address_Info + .DataField label {
	color: rgb(248,148,32);
}

Only the "Hire Date" Data Field's label is styled.

For example, the following CSS rule uses the general sibling selector.

.Address_Info ~ .DataField label {
	color: rgb(248,148,32);
}

Both the "Hire Date" and "Marital Status" Data Fields' labels are styled.

Styling Scope: Summary

For all cases below, you may presume an additional CSS rule has been added to adjust the label element widths to 140px.

Selection Type	CSS Rule	Selected Data Elements	Data Viewer Result
Generic element selection	label { color: rgb(248,148,32); } Selects every Data Field's label and colors it orange.
Named element selection	.Employee_Name label { color: rgb(248,148,32); } Selects only the "Employee Name" Data Field's label and colors it orange.
Descendant children selection combinator	.Personal_Info label { color: rgb(248,148,32); } Selects the Data Fields' labels for all children at every descendant level in the "Personal Info" Data Section and colors them orange.
Immediate children selection `>` combinator	.Personal_Info > .DataField label { color: rgb(248,148,32); } Selects the Data Fields' labels only for children in the first level in the "Address Info" Data Section and colors them orange.
Adjacent sibling selection `+` combinator	.Address_Info + .DataField label { color: rgb(248,148,32); } Selects the first sibling Data Field's label after the "Address Info" Data Section and colors it orange. "Sibling" means the Data Elements are in the same hierarchical level of the Data Model. "After" means following sequentially, in listed order from top to bottom.
General sibling selection `~` combinator	.Address_Info ~ .DataField label { color: rgb(248,148,32); } Selects all sibling Data Fields' labels after the "Address Info" Data Section and colors them orange. "Sibling" means the Data Elements are in the same hierarchical level of the Data Model. "After" means following sequentially, in listed order from top to bottom.

Selector Quick Reference

Selector	Data Element Selection Information
`.DataField`	Selects Data Fields
`.DataSection`	Selects single-instance Data Sections OR the elements representing the individual section instances of a multi-instance Data Section.
`.DataGridCollection`	Selects multi-instance Data Sections This is the parent element that houses one or more `DataSection` elements, one for each extracted section instance.
`.DataTable`	Selects Data Tables
`.DataColumn`	Selects Data Columns Be aware Data Tables are rendered in HTML using a variety of nested child HTML elements. The `.DataColumn` class is applied to multiple child elements, including the columns' name cells in the header row and the columns value cells in each row of data.
`.caption`	The `caption` class represents a Data Section or Data Table's caption label. This is the Data Section or Data Table object's name.
`label`	`label` is an HTML element used to represent a Data Field's label (its name in Grooper).
`th`	This is the easiest selector to select Data Column labels. Be aware `th.DataColumn` is a more specific selector as it matches only `th` elements with the `DataColumn` class. `th` is an HTML element representing each column's table header text in a table's header row. `DataColumn` is the CSS class representing Data Column Grooper objects.
`input`	`input` is an HTML element used to create an editable textbox to enter single-line Data Field and Data Column values. If you only want to style Data Field single-line textboxes use `.DataField input` as your selector. If you only want to style Data Column single-line textboxes (i.e. cells in an extracted Data Table) use `.DataColumn input` as your selector. Be aware for multi-instance Data Sections, the editable section number textbox in the navigation bar is also an `input` element. If you just use `input` as your selector you will style this element in multi-instance Data Sections as well.
`div[contenteditable="true"]`	Textboxes for multiline Data Fields are rendered as a content editable `div` element. This selector will style both multiline Data Field and Data Column values. If you only want to style Data Field multiline textboxes use `.DataField div` as your selector. If you only want to style Data Column multiline textboxes (i.e. cells in an extracted Data Table) use `.DataColumn div` as your selector.
`select`	`select` is an HTML element used to create dropdown selection lists Data Field and Data Column values. If you only want to style Data Field textboxes use `.DataField select` as your selector. If you only want to style Data Column textboxes (i.e. cells in an extracted Data Table) use `.DataColumn select` as your selector.
`.DataValue`	`DataValue` is a class attached to all types of editable textboxes (single-line, multiline, and dropdown selection lists). Use this selector if you want to style all input boxes of all types the same way.
`datalist`	The parent HTML element for the autocomplete list when a Data Field/Data Column's Auto Complete property is enabled. Not commonly styled
`option`	The child HTML elements for the autocomplete list when a 'Data Field/Data Column's Auto Complete property is enabled. These are the list items themselves. Not commonly styled

Types of Styling Available

There is A LOT you can do with CSS. There's far too much for us to cover completely. However, there are a few common types of styling you may want to apply to your Data Model.

In this section, we will detail some basic examples as they relate to the following categories:

Font and Text Styling
Margins, Borders, Padding, Height and Width Styling
Color Styling
Layout Styling

Font and Text Styling

Font and text formatting are some of most basic, but also most important, considerations when building a website. We will review a few of the standard CSS properties that can alter the text labels in a Data Model.

Keep your eye on the "Hire Date" field. Each of the CSS rules we demonstrate will affect its field label.

Font Style (Italics)

The font-style allows you to italicize text.

The CSS rule below italicizes the "Hire Date" field.

.Hire_Date label {
  font-style: italic;
}

The font-style property may be set to one of the following:

normal
italic
oblique

If no italic or oblique face for the font is available, the browser will attempt to mimic the sloping effect. If italic is selected, but there is no italic face for the selected font, the browser will attempt to use the oblique face before mimicking effect (and visa versa if oblique is selected).

FYI

What's the difference between italic and oblique? Good question. The short answer is "not much".

Officially, “Italic forms are generally cursive in nature while oblique faces are typically sloped versions of the regular face.”
For most fonts, there is little to no difference between italic and oblique faces.

Font Weight (Bolding Text)

The font-weight property allows you to bolden or lighten text (when available).

The CSS rule below bolds the "Hire Date" field.

.Hire_Date label {
  font-weight: bold;
}

The font-weight property may be set to one of the following:

normal
bold
bolder
lighter

If selected and the font being used has a "bold" or "normal" version, the browser will use that. If not, it will attempt to mimic a bold or normal version. The browser will not attempt to mimic a "lighter" or "bolder" version if none are found.

Font Variant (Small Caps)

The font-variant property allows you format your text in small caps.

The CSS rule below turns the "Hire Date" field to small caps.

.Hire_Date label {
  font-variant: small-caps;
}

The font-variant property may be set to either of the following:

normal
small-caps

Font Families

The font-family property sets what font family should be used to render the text.

The CSS rule below changes the "Hire Date" field from the default font (Open Sans) to Courier New.

.Hire_Date label {
  font-family: Courier New;
}

Be aware a font will only display if it is installed by the browser or on the device viewing the webpage. The following fonts are considered "web-safe". These are fonts universally installed by all browsers.

(Generally) Web-Safe Fonts

Arial (sans-serif)
Verdana (sans-serif)
Tahoma (sans-serif)
Trebuchet MS (sans-serif)
Times New Roman (serif)
Georgia (serif)
Garamond (serif)
Courier New (monospace)
Brush Script MT (cursive)

However, there are no 100% web safe fonts. While these are "universally" installed across "all" browsers, there's always a chance the font is not installed properly or is otherwise missing. That's why it's best practice to use a fallback font.

Fallback fonts are separated using a comma.
For example: font-family: Tahoma, Verdana, sans-serif;
- The browser would first attempt to use Tahoma.
- If that font cannot be found, it then attempts to use Veranda.
- If that font cannot be found it will use the generic system sans-serif font for the browser.

AT BARE MINIMUM, you should always include one of the following generic fallback fonts when declaring a font family:

sans-serif
serif
monospace
cursive
fantasy

Text Alignment

The text-align property allows you to set an alignment for text inside the element.

The CSS rule below right aligns the "Hire Date" field's text within its label element.

.Hire_Date label {
  text-align: right;
}

You may choose one of the following alignments:

left (This is the default, in most cases)
right
center
justify

Text Color

As we've seen in previous examples, the color property styles the element's text content's color.

Using the CSS rule below, we've adjusted text color for the "Hire Date" field's label, using the RGB color value for "Grooper orange".

.Hire_Date label {
  color: rgb(248,148,32);
}

Colors can help draw a user's attention and separate content in meaningful ways. There's also more to coloring a webpage than just coloring text. We'll talk more about color styling in the Color Styling section of this article.

Font and Text Styling Summary

Text Style	CSS Rule	Selected Data Elements	Data Viewer Result
Font size	.Hire_Date label { font-size: 21px; } Increases the "Hire Date" Data Field's font size to 21 pixels high.
Font style (italics)	.Hire_Date label { font-style: italic; } Italicizes the "Hire Date" Data Field's label.
Font weight (bolding text)	.Hire_Date label { font-weight: bold; } Bolds the "Hire Date" Data Field's label.
Font variant (small caps)	.Hire_Date label { font-variant: small-caps; } Turns the "Hire Date" Data Field's label to small caps.
Font families	.Hire_Date label { font-family: Courier New, monospace; } Changes the "Hire Date" Data Field from the default font (Open Sans) to Courier New. If Courier New cannot be rendered, the system monospace font will be used as a fallback font.
Text alignment	.Hire_Date label { text-align: right; } Right aligns the "Hire Date" Data Field's text within its `label` element.
Text color	.Hire_Date label { color: rgb(248,148,32); } Changes the "Hire Date" Data Field's label's text color to "Grooper orange", using the RGB color value.

FYI: Styling Data Section and Data Table Caption Labels

Styling Data Section and Data Table Caption Labels

A Data Section or Data Table's header caption is itself just another child element rendered on a webpage. All Data Section and Data Table HTML elements have a child element with a caption class styling their caption in the Review screen.

When it comes to styling Data Section and Data Table captions, you'll need to use the .caption selector. This will select any element with the caption class.

All captions will be styled if you simply use .caption for the CSS rule's selector, as in the rule below:

.caption {
  color: rgb(248,148,32);
  font-size: 1.5em;
  font-variant: small-caps;
}

FYI

For more specific caption styling, use more specific CSS selectors.

You can also remove a caption by using the display: none; declaration.

This can be useful if you need to place fields in a Data Section for data extraction or Batch processing purposes, but would confuse or distract users.

For example, adding the following CSS rule would remove the caption for the "Address Info" section.

.Address_Info .caption {
  display: none;
}

See here, the "Address Info" caption has been entirely removed in the Review viewer.

As far as the reviewer is concerned, there is no "Address Info" section. But, you the Grooper designer knows better!

Margins, Borders, Padding, Height and Width Styling

There's good reason why a div HTML element is named so. A div creates a division within a document, making it more distinct from other elements on the webpage. Margins, borders and padding help make the divisions between HTML elements visually more distinct by increasing the space between the elements (margins), outlining the elements (borders) and increasing the space within an element (padding).

Effective use of margins, borders and padding can increase the readability and accessibility of your Data Model when viewed in a Review viewer.

The Box Model

If you've spent any amount of time with CSS, you've probably seen the "Box Model".

This diagram is designed to help you better understand the different dimensions of an HTML element, including:

The content's width and height
The padding size
The border width
The margin size

When styling an element you can use the margin, border, padding, height, and width properties to better space out and define different elements.

As this pertains to styling Data Elements, this can help make your Data Model more readable and better help create logical section divisions in the Review viewer.

FYI

Adjusting the margin, border, and padding values will adjust these properties on all four sides (top, bottom, left and right) with the same measurement.

You can specifically adjust one side's value by adding -top, -bottom, -left, or -right to the property, depending on which side you want to adjust.

For example, margin-left would only adjust the left margin, leaving the top, bottom and right margins alone.

Margins

The margin properties adjust the space between HTML elements.

One practical use of margins is to effectively indent Data Elements to better define sections of fields in the Review viewer.

This CSS rule, indents all Data Sections by increasing the left margin value.

.DataSection {
  margin-left: 32px;
}

See here, the "Personal Info" Data Section is now indented.
- There is now 32 pixels of whitespace on the left boundary of the element.
The "Address Info" Data Section also has its left margin increased by 32 pixels.
- Note since this Data Section is a child of another Data Section, its HTML DataSection is contained within another DataSection element.
- Therefore, it is indented 32 pixels from within its parent container.
The section records within the multi-instance "Previous Employment" Data Section have their left margin increased by 32 pixels.
- Multi-instance Data Sections are represented as HTML elements with the DataGridCollection class. Each of its section record in a multi-instance Data Section is represented as a DataSection HTML element.
- Therefore, the section record is indented 32 pixels from within the parent DataGridCollection element.

FYI

Margin specifications are often used to center HTML elements. If you're trying to center an entire element (not the text within an element, but the element itself), try using the following two declarations:

margin-left: auto;
margin-right: auto;

Borders

The border property creates a stroked border around the HTML element. When defining the border property, you can control the border's width, style (e.g. "solid" or "dashed"), and color.

Borders are another way of visually separating content. When used to style Data Sections and Data Tables, this can better divide out the Data Elements within your Data Model.

Borders are always are always defined by specifying at least the border's width and style. Most typically, you will also specify the border's color.

For example, the CSS rule below draws a solid white border around all Data Tables.

.DataTable {
  border: 1px solid rgb(255,255,255);
}

The border property definitions determine how the border looks.

1px - This makes a border 1 pixels in width.
solid - This makes a solid border (as opposed to a dotted or dashed one).
rgb(255,255,255) - This colors the border white, using its RGB color value.

Once you start adding borders to elements in your Data Model, the margin, padding, height and width properties become even more important. This is particularly the case when adding borders to Data Section elements.

Using the CSS rule below, we've added a solid 1 pixel border around all Data Sections.

.DataSection {
  border: 1px solid rgb(255,255,255);
}

As it stands, having a border around Data Sections doesn't visually improve the Data Model. This doesn't really do anything to improve the users experience in Review and is actually a little confusing to look at. Why does it look the way it does? There is effectively no padding specified here.

Next, we will add some padding to these elements to vastly improve the Data Sections' styling.

FYI

Single instance Data Sections are rendered in HTML as a div container with a DataSection class.

The single DataSection element contains any child Data Elements as child HTML elements.
"Personal Info" and "Address Info" are single instance Data Sections in this image.

Multi instance Data Sections are rendered in HTML as a div container with a DataGridCollection class.

The single DataGridCollection element contains one or more DataSection child HTML elements, one for each section instance produced.
These multiple DataSection HTML elements then contain any of the Data Section's child Data Elements as child HTML elements.
"Previous Employment" is a multi-instance Data Sections in this image.

Padding

The padding properties adjust the space around the HTML element, between the element and any defined border. Another way of thinking about padding is it extends the height and/or width of the element.

Padding is almost always specified when adding a border to an element. Without any padding, the border butts right up to the boundaries of the element's content. This can be visually jarring and confusing. The extra padding helps increase readability by adding some "breathing room" between the element's content and its border.

By adding just a little padding around our Data Section elements, we can start to see the benefits of adding a border.

Below, the CSS rule adds a 1 pixel border around Data Sections and increases their padding by 12 pixels on all sides.

.DataSection {
  border: 1px solid rgb(255,255,255);
  padding: 12px;
}

See here, the space between the element and the border are better spaced out. 12 pixels have been added to the top, bottom, left and right edges to the element, between the 1 pixel wide solid border.

FYI

Single instance Data Sections are rendered in HTML as a div container with a DataSection class.

The single DataSection element contains any child Data Elements as child HTML elements.

Multi instance Data Sections are rendered in HTML as a div container with a DataGridCollection class.

The single DataGridCollection element contains one or more DataSection child HTML elements, one for each section instance produced.
These multiple DataSection HTML elements then contain any of the Data Section's child Data Elements as child HTML elements.

Bonus! Border Radius

If you prefer the look of rounded boxes, you should use the border-radius property.

This is the same CSS rule with a border-radius declaration added. This rounds out the border's corners using a 4 pixel radius.

.DataSection {
  border: 1px solid rgb(255,255,255);
  padding: 12px;
  border-radius:4px;
}

Next, we're going to visit the height and width properties to further style the look of our Data Sections.

Height and Width

Aside from adjusting margins and padding to space out an element, it can be beneficial to adjust the element's actual width and height. This can be done with height and width properties (as well as min-height/max-height and min-width/max-width).

Width and height specifications are often adjusted to better adjust a webpage's layout by adjusting the dimensions of the HTML elements that make up that webpage. For example, Grooper users will commonly adjust the Data Field label elements' width (See above for illustration).

Once you start using CSS to customize the layout of Data Elements in the Data Viewer, you may find you need to adjust the widths and heights of Data Elements, such as your Data Sections. By default, Data Field, Data Section, and Data Table HTML elements take up the entire width of available horizonal space in the Data Viewer. With borders clearly marking the boundary of an element, this is a lot more noticeable.

The CSS rule below adjusts the maximum width of all Data Sections. It specifies Data Sections can only be at maximum 400 pixels wide by adding a max-width specification.

.DataSection {
  border: 1px solid rgb(255,255,255);
  padding: 12px;
  border-radius: 4px;
  max-width: 340px;
}

Why did we use the max-width property instead of the width property? The width property sets a literal width. The max-width property is more dynamic. Elements' widths will be adjusted up to a maximum value.

In our case, one of our Data Sections is a child of another data section. If we used the CSS rule below, using the width property, the result would be less ideal in this case.

.DataSection {
  border: 1px solid rgb(255,255,255);
  padding: 12px;
  border-radius: 4px;
  width: 340px;
}

There are plenty of circumstances in which the literal width specification would be appropriate. It just was not as appropriate here.

Given one Data Section element is a sub-element of another Data Section, using the max-width property allows the child Data Section to be dynamically resized to fit within the parent Data Section.

A Width You Can't Adjust With CSS

There is one element width you cannot adjust with CSS, an input element's width.

To adjust the width of a Data Field or Data Column's input box, you must use the Display Width property in the object's property grid.

Select the Data Field or Data Column whose input box you wish to adjust.
Enter the width (in pixels) in the Display Width property.
The input box's width will be adjusted to the entered value.

Margins, Borders, Padding, Height and Width Summary

Style Description	CSS Rule	Selected Data Elements	Data Viewer Result
Margins	.DataSection { margin-left: 32px; } Adds 32 pixels to all Data Sections' left margin. Effectively, this left indents all Data Section elements 32 pixels. Note the "Address Info" Data Section is a child of the "Personal Info" Data Section, and thus a sub-element of the `Personal_Info` HTML element. Therefore, the "Address Info" section is indented 32 pixels from inside the "Personal Info" section. Note only the Data Fields were indented 32 pixels for the "Previous Employment" Data Section (not, for example, the "Previous Employment" caption). This is because "Previous Employment" is a multi-instance Data Section. For multi-instance Data Sections, each section instance is represented by a `DataSection` element housed in a parent `DataGridCollection` element.
Borders	.DataSection { border: 1px solid rgb(255,255,255); } Outlines all Data Sections with a white 1-pixel wide border.
Padding	.DataSection { border: 1px solid rgb(255,255,255); padding: 12px; } Outlines all Data Sections with a white 1 pixel wide border. Adds 12 pixels of padding between the element's content and the border.
Border Radius	.DataSection { border: 1px solid rgb(255,255,255); padding: 12px; border-radius: 4px; } Outlines all Data Sections with a 1 pixel wide border. Adds 12 pixels of padding between the element's content and the border. Rounds the corners on the borders.
Width	.DataSection { border: 1px solid rgb(255,255,255); padding: 12px; border-radius: 4px; width: 400px; } Outlines all Data Sections with a white 1 pixel wide rounded border. Adds 12 pixels of padding between the element's content and the border. Sets the literal width of all Data Section elements to 400 pixels wide.
Max Width	.DataSection { border: 1px solid rgb(255,255,255); padding: 12px; border-radius: 4px; max-width: 400px; } Outlines all Data Sections with a white 1 pixel wide rounded border. Adds 12 pixels of padding between the element's content and the border. Sets the maximum width of all Data Section elements to 400 pixels wide.

Color Styling

Colors are useful in a variety of different ways. They don't just "look pretty". They're used to call attention to different portions of a document, divide sections on a document, or distinguish between portions of a document.

There are a lot of ways you could style elements' colors in HTML (and therefore Data Elements in Grooper's Data Viewer). We're going to focus on the three most common ways colors are styled:

Text colors
Border colors
Background colors

First, how do you pick a color? How do you define whether something is red or blue or hot pink? There are a few different ways to define a color value in CSS.

Specifying Colors

You can specify colors in CSS in the following ways:

#FFF8DC	Hexadecimal colors Ex: `#FFF8DC` is the color known as "cornsilk".
#FFF8DC50	Hexadecimal colors with transparency Ex: `#FFF8DC50` is cornsilk with a 50% transparency. The last two numbers (e.g. `#FFF8DC50`) set the transparency transparency value on a scale from 00 to FF. 00 indicates full transparency. FF indicates full opacity. Anything from 01 to 99 is a percentage value in between.
rgb(255, 239, 213)	RGB colors Ex: `rgb(255, 239, 213)` is the color known as "papaya whip". Colors in the RGB color model are defined by their intensity values (from 0 to 255) of red, green and blue light.
rgba(255, 239, 213, .5)	RGBA colors Ex: `rgba(255, 239, 213, .5)` is papaya whip with a 50% transparency. RGBA colors use the RGB color model with an additional alpha channel. The alpha channel (e.g. `rgba(255, 239, 213, .5)`) sets the color's transparency/opacity. This sets the opacity value on a scale from 0 (fully transparent) to 1 (fully opaque).
hsl(36, 100%, 84%)	HSL colors Ex: `hsl(36, 100%, 84%)` is the color known as "Navajo white". The HSL color model is an alternative to the RGB color model designed by computer graphics researchers in the 1970s to more closely correlate color values to how the human eye perceives color. It represents colors based on their hue, saturation and brightness values.
hsla(36, 100%, 84%, .5)	HSLA colors Ex: `hsla(36, 100%, 84%, .5)` is Navajo white with a 50% transparency. HSLA colors use the HSL color model with an additional alpha channel. The alpha channel (e.g. `hsla(36, 100%, 84%, .5)`) sets the color's transparency/opacity. This sets the opacity value on a scale from 0 (fully transparent) to 1 (fully opaque).
BurlyWood	Predefined color names used across browsers Ex: `BurlyWood` is the color known as "burlywood". You can find a list of color names supported across browsers here.

FYI

Which color space should you use? Generally speaking it's up to you.

In this article, you will find we most often use the RGB and RGBA color spaces.

We use RGB for literal color definitions when we know the exact color value we want something to be.
We use RGBA when we want to shade or tint an existing color, starting with black or white as our color value and adjusting the alpha channel transparency between 0 to 1 until we find the right color.
- This is often useful to keep colors consistent within a monochromatic or semi-monochromatic color scheme.

Text Color

We've already seen text color styling in this article, using the color property. The color property change the text's color within an element.

For example, this CSS rule will color the "Employee Name" Data Field's input box text yellow.

.Employee_Name input {
  color: rgb(255,255,50);
}

Something like this can be useful for a Data Field value that needs highlighting. If a user has a need to keep referencing an extracted value, this will more clearly call it out in the Review viewer.

Border Color

You can style a border's color using either the border-color or border property.

If the HTML element already has a border specification, you can use the border-color property to recolor the border.

This CSS rule recolors the border around the "Employee Name" Data Field's input box.

.Employee_Name input {
  border-color: rgb(248,148,32);
}

Please note, if the element doesn't already have a border specified (either from an inherited class or in the CSS rule itself), the border-color property will do nothing. There is no border to color at that point.

You can use the border property as a shortcut to create a border, setting the width, style and color all with a single property.

The first description line in the following CSS rule creates the border, including coloring it orange with the RGB color rgb(248,148,3,)

.DataSection {
  border: 1px solid rgb(248,148,32);
  border-radius: 4px;
  padding: 12px;
  padding-top 8px;
  margin-top: 8px;
  margin-bottom: 8px;
}

Background Color

Text is considered the "foreground" of an HTML element. Whatever is behind it counts as "background". The background-color property (appropriately enough) colors an element's background. Coloring an element's background can be a great way of drawing attention to certain Data Elements or making visual breaking points between groups of Data Elements.

This CSS rule colors the background of the "Employee Name" Data Field's input box yellow. This is another way to make an important field stand out from others.

.Employee_Name input {
  background-color: rgb(255,255,50);
  color: rgb(0,0,0);
}

Notice we also changed the text color to black (color: rgb(0,0,0)). If we did not, the text would have been unreadable on a yellow background.

Be aware once you start styling background colors, you may need to style other colors (particularly text colors) in order to make your Data Model more readable in the Review viewer.

Background color styling is also a way to make your Data Sections distinct.

We're using the following CSS rule to style our Data Sections.

.DataSection {
  background-color: rgba(0,0,0,.25);
  border: 1px solid rgba(255,255,255,.5);
  border-radius: 4px;
  padding: 12px;
  padding-top 8px;
  margin-top: 8px;
  margin-bottom: 8px;
}

The first description (background-color: rgba(0,0,0,.25))colors the Data Sections' backgrounds.

We're also using RGBA alpha channel here.

The rule colors the background of all Data Sections black with a 25% transparency. Effectively this slightly shades Data Sections.
Because the "Address Info" Data Section is nested within the "Personal Info" Data Section it is extra shaded! Its black transparency is overlaid on top of the already darkened background behind it.

The combination of borders, padding and color shading really separates these Data Sections from the rest of the Data Model.

FYI

Please be aware any padding in an element is considered part of the element's background. Margins are space outside the element and are not part of the element's background.

Space specified by padding will be colored by a background-color specification.
Space specified by margins will not be colored by a background-color specification.

Layout Styling

Without CSS, you'd have no control over how Data Elements are laid out in the Data Viewer. They would appear on the screen essentially as a list, with each Data Field occupying a single line. However, CSS rules give you a great deal of flexibility in terms of laying out the various elements that make up the Data Elements in your Data Model.

With a few simple adjustments to properties like margins, borders, and an element's display mode, you can re-order your Data Model's layout to make a better review experience.

Generic Layouts

In the Generic Layout Examples section of this article, you will find some generic layout examples that could be applied to any content model.

These include:

List Layout - Styles fields and sections as a simple list. Hierarchy in Data Elements is defined by indenting Data Elements in Data Sections.
Flow Layout - Lists fields horizontally rather than vertically, stacking labels on top of their input boxes. Fields will wrap to fit the Data Grid or Data Section they are contained within.
Card Layout - Relies on Data Sections and border styling to create distinct divisions between different kinds of fields on the document. Each Data Section becomes a "card" with a list of fields on it. The fields in each card can be styled with either a list or flow layout.

Mirrored Layout

One handy thing you can do with CSS is structure your Data Model in Review to mimic a document's layout. Keep in mind, this approach is most applicable for structured documents whose layout remains consistent from one document to the next. These are documents where you expect to find fields, sections and tables at the same physical location with the same physical dimensions.

Using Data Sections to better group and organize sections of Data Fields and CSS rules to style those Data Sections and Fields, you can get pretty close to the same layout in the Data Viewer screen in Review as you have on the page.

This can be a tremendous boon to document reviewers. If the entry fields are laid out like are on the actual document, they don't have to do nearly as much searching for what they're trying to enter. Ultimately, this saves time on data entry and can reduce error rates as well.

We describe this kind of Data Model styling as a "Mirrored Layout". The Data Model is styled to mirrors how fields, sections and tables are laid out on the physical document itself.

Going from the basic "List & Card Layout" to a "Mirrored Layout" is all about styling where and how HTML elements appear next to one another in the browser.

As you can see from the "List & Card Layout" image, some styling has already been done to this Data Model. The Data Field label widths are increased, and the Data Sections and Data Table have some border and background color styling.

This will be our "starting point".
You can click the "List & Card Layout CSS" tab above for the full text CSS.

With just a few key adjustments, we will end up with a Mirrored Layout Data Model. Where and how the Data Fields and elements are lined up more closely match where and how they're lined up on the source document.

You could spend a great deal of time pouring over the CSS getting everything to line up just right, but the basics can be boiled down to three concepts:

Using Data Sections to act as parent HTML elements for more simplified styling.
When to use inline vs block elements.
Effectively using width and other spatial dimensions.

Use Data Sections to Your Advantage

Before even touching CSS, you should think about organizing your Data Model to better lay out Data Elements in the Review Viewer. Data Sections can be extraordinarily beneficial to this end.

A Data Section can act as a simple bucket to hold other Data Elements to better organize your Data Model. They will also act as a parent HTML element holding the Data Elements. You can use CSS to style Data Sections in the following ways to mirror a document's layout:

To physically constrain the Data Section's child elements in the browser, separating sets of Data Fields from others.
To order fields within a Data Section, laying them out vertically or horizontally next to each other.
To order Data Sections themselves, laying them out vertically or horizontally next to each other.
To use children selectors to style just the elements within a specific Data Section, distinct from the typical styling for the rest of the Data Model and other Data Sections.

Just looking at the document, you should mentally break up collections of elements base on how they are grouped on the page and similarities in layout. These mental divisions of fields will be candidates for their own Data Sections in our Data Model.

This could be considered a section.
- All the fields have the same label/value orientation with the label on top of its value. Each field is laid out horizontally, rather than vertically.
- We will call this the "Personal Info" section.
This is extremely similar to the section before it. It could be its own section, or not.
- The fields have the same label/value orientation as the "Personal Info" and will need to be styled more or less identically.
  - Option A: Use a single Data Section to style both sets of fields the same.
  - Option B: Use two Data Sections styled the same way.
- Ultimately, we'll go with "Option B". Why?
  - These fields are grouped together spatially on the document. Placing it in a Data Section allows us to create a border division around the section and separate it spatially from other Data Sections and fields in the Data Viewer.
  - Also, these fields are logically of the same "kind" if nothing else. Even if placing them in a Data Section is not required for CSS styling, it's often helpful to reviewers to group related elements together in a Data Section anyway.
  - Lastly, these fields are contained in a Data Section named "Address Info" currently anyway.
This will absolutely need to be its own section.
- These fields are laid out differently from the rest of the document. The fields have a left to right label/value orientation and are stacked on top of each other. We can use a Data Section to style these fields differently from how we will end up styling the rest of the Data Fields in the Data Model.
- We will call this the "Other Info" section.
Tables could go in Data Sections but often do not need to.
- A Data Table is a kind of parent container itself with Data Columns as its children.
- There's no real reason for us to put the Data Table in a Data Section. All the styling it needs can be applied to the Data Table itself. It would be redundant or, at the least, overkill to place the Data Table in its own Data Section then style the Data Section.
These fields will need to be in a Data Section for data extraction purposes, but we can also use that to our advantage for CSS.
- These fields also have a layout more like the "Hire Date" and "Marital Status" fields and will need to be styled appropriately.

We have adjusted our Data Model to reflect these divisions by adding some Data Sections.

The first four Data Fields are fine as is. They will stay in the "Personal Info" Data Section.
- We will make no change here.
The "Address Info" Data Section will be moved to the root of the Data Model to better create a division for this group of fields.
These Data Fields have been placed into a new Data Section named "Other Info" and moved to the root of the Data Model.
The "Dependents" Data Table does not need to be placed into a Data Section. The table occupies the full width of the page on the document.
- We will make no change here.
The "Previous Employment" fields are already in a Data Section.
- We will make no change here.

⚠

Please be aware we're using Data Sections as an organizational tool not as an extraction tool (subdividing a document into one or more section instances). As such we've adjusted the following properties for our Data Sections:

Scope is set to SingleInstance.
Miss Disposition is set to Default to Parent.

This will ensure a single-instance Data Section is rendered instead of a multi-instance Data Section, and the Data Fields extractors will collect data from the parent instance, which in this case is the full document.

Block VS Inline Elements

To understand how HTML elements are laid out on a webpage, you need to have a concept of "inline" and "block" elements (as well as a special type of inline element called "inline-block").

Block elements always start on a new line.

Put another way, they take up as much width on the screen as possible.
- If the element is at the top of HTML hierarchy it would be as wide as the computer monitor.
- If is contained in a parent HTML element, it would be as wide as the parent element allows).
Browsers will automatically add some left and right margins to block elements.
By default, Data Fields are rendered as block elements.

Inline elements do not start on a new line.

They only take up as much width as necessary.
- Multiple inline elements in a row will be placed from left to right on a single line.
- If the edge of the screen or parent HTML element is encountered, an element will wrap to the next line (if wrapping is enabled) or the viewer will need to use a horizontal scroll bar to view the element.
By default, a Data Field's label and input elements are a type of inline element.

Specifically, label and input elements are "inline-block" elements.

Inline-block elements do not start on a new line, but you can adjust the width and height of the element.

A true inline element's width and height is calculated automatically, only taking as much space as necessary to render the element.
Inline-block elements allow you to adjust the element's width and height properties in a CSS rule.

In general, when styling elements in a Data Model it is preferable to use the inline-block mode over the inline mode. Adjusting the widths and heights of elements is often critical to get your Data Model laid out the way you want in the Data Viewer.

Getting our Data Model to look more like the document's layout has a lot to do with manipulating the inline and block modes using the display property.

On our document, several of the fields' labels are stacked vertically on top of the value. We can replicate this layout by simply changing our Data Fields' label and input elements from inline-block elements to block elements.

The rule below will accomplish this goal:

.DataField * {
  display: block;
}

FYI

The * character in the selector selects all child elements. In this case, that's the Data Field's label and input elements.

Next, we need to change the layout of the Data Fields themselves (as the parent element containing the label and input elements).

On the document, fields are laid out horizontally next to each other, rather than being stacked vertically on top of each other. Because Data Fields are block elements by default, our Data Fields have more of a vertical layout. To get a more of a horizontal layout, we can simply change their display mode to inline-block. This will allow multiple Data Fields to be displayed across a single line.

Adding the rule below will accomplish this goal:

.DataField {
  display: inline-block;
}

What about this section of fields on the document?

Their layout is different from the rest of the document. The layout is actually more like the default Data Field styling. What can we do to fix this?

Lucky for us, we organized our Data Fields into sections! Both of these fields are in a Data Section named "Other Info". All we need to do is select the Data Fields within the "Other Info" and re-style them to more appropriately match their layout on the document.

Adding, the following CSS rules will suffice:

.Other_Info .DataField {
  display: block;
}

.Other_Info .DataField * {
  display: inline-block;
}

Furthermore, the fields in the "Previous Employment" sections share the same layout as the "Other Info" section. We can use the same set of rules for that Data Section styling as well.

All we need to do is include them in our selector, as seen below:

.Other_Info .DataField,
.Previous_Employment .DataField {
  display: block;
}

.Other_Info .DataField *,
.Previous_Employment .DataField * {
  display: inline-block;
}

Lastly, we need to evaluate our "GUID" Data Field. This Data Field is not actually found on the document, but generated with a Default Value expression. So its layout is really up to you.

Presuming you want to styling it with a "List Layout" like our "Other Info" and "Previous Employment" sections, you could easily add a selector to our same set of CSS rules. If you wanted to specifically style the "GUID" Data Field and only the "GUID" Data Field you could simply use .GUID for the selector.

However, if you wanted to more broadly style any Data Field at the root of the Data Model and only Data Fields at the root of the Data Model, you could use the following selector:

.DataModel > .DataField

The following changes to our CSS rules would give any Data Field at the root of the Data Model a List Layout (including the "GUID" field).

.Other_Info .DataField,
.Previous_Employment .DataField,
.DataModel > .DataField {
  display: block;
}

.Other_Info .DataField *,
.Previous_Employment .DataField *,
.DataModel > .DataField * {
  display: inline-block;
}

With these CSS rules in place, the Data Model is starting to mirror the document's layout more closely. But it could still use some work.

Next, we're going to talk about using spatial dimensions (specifically elements' widths) to better lay out the Data Elements in the Data Viewer.

FYI

We did two things to make our Data Model more closely mirror the document's layout:

Change the label/input orientation from horizontal to vertical.
Change the Data Fields order from a vertical list to a horizontal list of Data Fields.

To accomplish this we used two CSS rules:

.DataField * {
  display: block;
}

.DataField {
  display: inline-block;
}

There are other display modes that would accomplish this same end and do so with only a single CSS rule. The rule below uses the inline-flex display mode with a flex direction of "column":

.DataField {
  display: inline-flex;
  flex-direction: column;
}

While there are certainly differences between these two approaches, for our purposes the result is nearly identical.

Using Widths and Other Spatial Dimensions - Part 1

Styling your Data Elements dimensions can be an effective way to help your Data Model mirror your document's layout. Sometimes this boils down to nothing more than adjusting the width of your Data Field's input elements.

Check out our "Employee Name" Data Field.

As a practical matter, the input box is too narrow. The reviewer can't see the whole name extracted.
But also, isn't the field a little wider on the document itself? At least compared to the "DOB" "SSN" and "Phone" fields?

We can kill two birds with one stone here. Widening the "Employee Name" Data Field's input label will both help our reviewer's see the full extracted value as well as mirroring the field's layout on the document a little better.

Remember, you cannot use CSS to style the width of input elements. You must adjust the width using the Data Field's Display Width property in Grooper.

In the Node Tree Panel, navigate to the Data Field whose input element you wish to adjust.
Select the Display Width property and enter the desired width, in pixels.
- We've entered 200 for our "Employee Name" Data Field's Display Width property.
This will increase the input element's width in the Data Viewer.

This will help but we have some work to do still.

Our "Employee Name" field is adjusted to a width that is more in line with the field's width on the document.
However, you should notice some inconsistencies in the spacing between Data Fields now.
This is because currently in our Style Sheet all Data Field label elements have a width of 140 pixels.

It doesn't really make sense for all our Data Fields' labels to be a set width now that most of them have a different layout orientation.

It's only those label elements that are still inline-block elements that need to retain this width of 140 pixels.

Currently, we're using the following CSS rule to globally style the width of all Data Field label elements.

label{
  width: 140px;
}

In reality, the only label elements we want to behave that way are those in the "Other Info" and "Previous Employment" section and the "GUID" field at the root of the Data Model. All we need to do is adjust the selector a little bit.

.Other_Info label,
.Previous_Employment label,
.DataModel > .DataField label {
  width: 140px;
}

The result is a cleaner looking Data Model. The spacing is more even and the "Employee Name" field more accurately reflects the field's width on the document.

Using Widths and Other Spatial Dimensions - Part 2

Next, we're going to take a look at the "Address Info" section of fields. Currently, all the fields are on a single line within the section. We need to a point where "Street Address" is on one line and the rest of the fields are on the next.

There's a number of ways we could get this to work out for us, but there are two very simple solutions:

Change the "Street Address" Data Field from an inline-block element to a block element.
Or, adjust the widths of one or more Data Fields and the width of the Data Section so fields wrap appropriately.

Option 1: Change "Street Address" to a Block Element

This may well be the simplest solution simply because the "Street Address" field is a single field that occupies the entire width of the document. What is a block element? It's an HTML element that occupies the entire width of whatever element its contained in. If the width of the document is analogous to the width of the Review screen, it sure seems like the "Street Address" field would be a good candidate for a block element.

All we need to do is add a CSS rule for the "Street Address" field, changing its display property to block.

.Street_Address {
  display: block;
}

Because "Street Address" is now a block element, it now takes up a whole line by itself. This is much more in line with what the document looks like.

Option 2: Adjust Input Widths and Let Elements Wrap Lines

Another option is to rely on line wrapping to get you what you want. There's only so much screen real estate for the Data Viewer to occupy. You can control how elements wrap to subsequent lines but adjusting their widths.

We can adjust the width of one or more Data Field's input elements such that the inline collection of elements in the "Address Info" wraps to two lines instead of one.

Here, we've changed the "Street Address" Data Field's Display Width property to 532 in Grooper.

532 pixels is quite a bit of screen to cover. The "City" "State" and "Zip" fields are forced to wrap to the next line.

There are a few plus sides to this approach:

You were probably going to increase the widths of these Data Fields' input box anyway.
- Why does the "Street Address" field take up so much space on the document? Street addresses can be pretty long.
- Your reviewers will also want a wider input box so they can capture the whole address without scrolling.
It more closely mirrors how the document looks.
- Remember, our goal here is to mirror the document's layout, making the Data Model look more like the document in the Review UI.
- If the "Street Address" field on the document takes up a whole line, why wouldn't you increase the width of the Data Field's input as much as possible?

Here, we've also increased the width of the "City" Data Field's input by adjusting its Display Width property to 310.

That field is also longer on the document. Not as wide as the "Street Address" field. But wider than the "State" or "Zip" fields. Increasing its size just makes the Data Model look that much more like the document.

There is a potential downside to this approach. Because it relies on wrapping, you have to be very aware of screen sizes and how wide the Data Model is in the Data Viewer.

If we were to widen the Data Model panel in the Data Viewer, you can see the fields layout no longer mirrors the document. Given more horizontal space, the wrapping is different.

One way to resolve this issue is to set a maximum width value for the parent Data Section. If we say our Data Sections can only be up to a certain width, it won't matter how wide the screen is. We can ensure the wrapping always works the way we want by dictating the width of the HTML element containing the Data Fields.

Here we've added the following CSS rule:

.DataSection {
  max-width: 580px;
}

Now our wrapping works as expected, regardless of the width of the Data Model panel and our Data Model's layout nearly perfectly mirror's the document's layout.

Full CSS with Comments

Below you will find the end-result style sheet for our "Mirrored Layout" Data Model. You can copy and paste this text into the Style Sheet property of any Data Model.

After reading this article, can you figure out what each of these rules is doing?

/*Rules adjusting Data Fields from a List Layout to a Flow Layout*/
.DataField  {
  display: inline-block;
}

.DataField * {
  display: block;
}

/*Data Section and Data Table border styling*/
.DataSection,
.DataGridCollection,
.DataTable {
  border: 1px solid rgba(255,255,255,.25);
  padding: 16px;
  padding-top: 8px;
  border-radius: 4px;
  margin-top: 8px;
  margin-bottom: 8px;
}

.DataGridCollection .DataSection {
  border: none;
  padding: 0px;
}

/*Adjusts the width of Data Tables to extend to the maximum width of the Data Model.*/
.DataTable {
  width: auto;
}

/*Effectively centers a Data Table's table content (every child HTML element except the Data Table's caption*/
.DataTable > *:not(.caption) {
  margin-left: auto;
  margin-right: auto;
}

/*Adjusts maximum width of Data Sections to wrap Data Fields appropriately*/
.DataSection {
  max-width: 580px;
}

/*Adjusts layout for the Other Info and Previous Employment sections and Data Fields at the root of the Data Model*/
.Other_Info .DataField,
.Previous_Employment .DataField,
.DataModel > .DataField {
  display: block;
}

.Other_Info .DataField *,
.Previous_Employment .DataField *,
.DataModel > .DataField * {
  display: inline-block;
}

.Other_Info label,
.Previous_Employment label,
.DataModel > .DataField label {
  width: 140px;
}

/*Hover and focus pseudo classes.  Changes border and drop shadow styling when hovering over and selecting Data Sections and Data Tables*/
.DataSection:hover,
.DataTable:hover,
.DataGridCollection:hover {
  border-color: rgba(255,255,255,.5);
}

.DataSection:focus-within,
.DataTable:focus-within,
.DataGridCollection:focus-within {
  border-color: rgba(255,255,255,.75);
  box-shadow: 1px 1px 12px rgb(0,0,0,.5), -1px 0px 8px rgb(0,0,0.5);
}

.DataGridCollection .DataSection:focus-within {
  box-shadow:none;
}

Tips and Best Practices

Two Approaches: Global Element Styling VS Local Element Styling

Be aware you can style a Data Model in two ways:

Globally - By editing the Data Model's Style Sheet.
Locally - By editing any children Data Sections' or Data Tables' Style Sheets.
- Styling a Data Section or Data Table's Style Sheet directly, simply limits the scope of accessible elements.

GLOBAL STYLING

(Data Model)

When configuring a Data Model's Style Sheet, you have global access to all Data Elements in the Data Model.

This means you can select any of them in a CSS rule.
Any style generically applied to a class (DataField for example), will be applied to all elements at any level in the Data Model's hierarchy.
You can style any specific Data Element by selecting it by name in the CSS rule.

LOCAL STYLING

(Data Sections & Data Tables)

When configuring a Data Section or Data Table's Style Sheet, you have local access to only its child Data Elements.

This means you can only select the child Data Elements in a CSS rule.
Any style generically applied to a class (DataField for example), will be applied only to child elements at the Data Section and Data Table's hierarchy.
- Please note this means you cannot style the Data Section itself by editing its Style Sheet. You are only able to style children of the Data Section (or child HTML elements of the Data Section's HTML element).
You can style only specific children Data Elements by selecting them by name in the CSS rule.

Put another way, when you configure a Data Section or Data Table's Style Sheet, their name is prepended to the selectors you enter behind the scenes.

Question: Given a Data Section named "Header Details", what's the difference between the following two selectors?

Entered in the Data Model's Style Sheet: .Header_Details .DataField
Entered in the "Header Details" Data Section's Style Sheet: .DataField

Answer: Absolutely nothing!

The selectors would select the same HTML elements in both cases.
Behind the scenes, Grooper merges the CSS rule written to the "Header Details" Data Section with the main CSS file by prepending the section's class name to the selector.
- So, the selector .DataField actually becomes .Header_Details .DataField when the Data Section's CSS is merged with the main CSS.

So, why do one or the other? Let's look at the pros and cons.

GLOBAL STYLING
Pros	Cons
All CSS rules are managed in a single style sheet. Only have to go to one place in the node tree to edit your CSS. Easiest way to globally apply styling to all elements of a certain type.	Style sheets can be lengthy and disorganized. Particularly if you have a large Data Model with several Data Sections and Data Tables, each one needing more specific custom styling rather than a general style applied to all of them.

LOCAL STYLING
Pros	Cons
Can be used as an organizational tool. Buckets all CSS rules applied to children of a given Data Section, creating a series of smaller style sheets instead of one big one. This can be particularly helpful for larger Data Models with several Data Sections and Data Tables, all needing more specific custom styling rather than a general style applied to all of them.	CSS rules are managed across multiple style sheets. Must go to multiple places in the node tree to edit your CSS. Can be confusing to keep track of which HTML elements are accessible. Only children, not self. Can be confusing if styling both the Data Model and Data Section/Data Table style sheets. Data Section and Data Table style sheets will always "win out". If you're expecting a CSS rule from the Data Model's style sheet to be applied but the Data Section's CSS rule says something different, the Data Section's rule is always going to be applied.

Styling Flat Data Models VS Hierarchical Data Models

Generally speaking, there are two types of Data Models:

Flat Data Models

All Document Types share a single Data Model at the root of the Content Model.

Flat Data Models are intended to accommodate use cases where all Document Types share the same set of of data.
For example, you may have multiple Document Types for multiple vendors in an invoice processing model, but each Document Type's Data Model will collect the same set of information (invoice number, line item details, balance due, etc).

Hierarchical Data Models

Each Document Type executes its own unique Data Model formed by a hierarchy of inherited and children Data Elements.

Hierarchical Data Models are intended to accommodate situations where each Document Type has a unique or semi-unique set of data.
For example, a human resource document processing model may process a variety of documents (government forms like a W-4 form, internal forms, various benefits forms, etc).
- Each may have their own unique set of information you want to collect (configured using the Document Type's Data Model) . But, they may share some information as well, such as an employee's name, date of birth or other identifying information (collected by a shared Data Model in the hierarchy, such as the Content Model's Data Model and merged with the fields in the Document Type's Data Model).

Thus far in this article, we've focused on flat Data Models to keep things simpler. Once you start working with more hierarchical models, you need to be careful about where you're editing the CSS. Each Data Model in the hierarchy has a Style Sheet property. Much like the Data Elements from each Data Model are ultimately merged to form a Document Type's Data Model the CSS rules from each style sheet is merged into a single one as well.

There may be some confusion when multiple Data Models attempt to style a specific property for an element using different values. You need to keep in mind two things:

The most specific selector will always be applied.
- If the Content Model's Data Model CSS has a more specific selector, its rule will be applied.
- On the other hand, if the Document Type's Data Model CSS has a more specific selector, its rule will be applied.
In cases where the specificity is ambiguous, the lowest level Data Model's style sheet will be applied.
- In other words, A Document Type's Data Model is more specific than a Content Model's Data Model. Therefore, the Document Type's CSS rule would win out.

Creating and Using CSS Classes

Classes in CSS are a great way of tagging certain kinds of HTML elements for styling. For example, classes are how we distinguish between the HTML elements representing Data Fields and Data Sections. They're both div elements, but Data Fields are div elements with a DataField class where Data Sections have a DataSection class.

You can also create your custom CSS classes and assign them to any Data Element (Data Fields, Data Sections, Data Tables and Data Columns) using their CSS Class property.

To create a CSS class, all you need to do is create a CSS rule in the Data Model's' Style Sheet.
- Create the class by simply selecting its name like you would any other class, entering a period then the class name.
- Here, we've added a class named example_class and styled it to give the HTML element an orange border. See below for the full CSS rule.

.example_class {
	border: 1px solid rgb(248,148,32);
	padding: 8px;
	border-radius: 4px;
}

⚠

There are the following naming restrictions for CSS classes.

The letters must be alphanumeric, an underscore, or a hyphen (i.e. "a-z" "A-Z" "0-9" "_" or "-").
The name cannot start with a digit.
The name cannot start with two hyphens.
The name cannot start with a hyphen followed by a number.
Class names are case sensitive.

To assign the class, select any Data Element in the Data Model.
- Here, we've selected the "Employee Name" Data Field.
In the CSS Class property, enter the name of the CSS class.
- FYI: Multiple classes can be assigned by listing each one separated by a space.
  - i.e. class_name1 Class_name2 class_name3 etc.
The style declarations in the CSS will be applied to the Data Element's HTML.

The class can be assigned to any Data Element you wish. Use classes to reuse CSS for multiple Data Elements in your Data Model.

Here, we've added the class to three Data Elements.

The "Personal Info" Data Section
The "Employee Name" Data Field
The "Dependents" Data Table

Example Classes

Highlight Class

This class was designed to quickly highlight certain fields. It turns a Data Field's label blue and its input text bold yellow.

See the CSS for the rule below:

.highlight label {
	color: DeepSkyBlue;
	font-weight: bold;
}
.highlight input {
	color: Yellow;
	font-weight: bold;
}

Note we needed two CSS rules to accomplish this, both declaring the highlight class. The first styles child label HTML for any Data Element using the highlight class. The second styles child input HTML.

Blur Class

This is an example of a potentially beneficial CSS class we've called "blur".

What it does is simple. When assigned to a Data Section or Data Table's CSS Class property, it blurs everything except the Data Section or Data Table's caption if the user is not focused inside the section or table. Effectively, all fields will be blurred out except those in the section you're actively editing.

This could be used to protect PII or other sensitive data, only keeping it visible on the screen while the user is actively editing the sensitive data.
This could also be used to protect against eye strain. There's less noise for the user to focus on if only what they're actively editing is literally in focus.

The following CSS class would be added to your Data Model's Style Sheet text.

.blur:not(:focus-within) > *:not(.caption) {
  filter: blur(4px);
}

In the image here, we've added the blur class to each Data Section and Data Table in the Data Model.

FYI

This CSS rule uses the focus-within pseudo-class.

More information on pseudo-classes can be found at W3Schools.

Examples

In this section, we will post various Data Model Style Sheet examples. Use them to get ideas for what you may be able to incorporate into your own Data Models.

Comments are included in some of these style sheets to document various CSS rules. See below for an example of a comment.

/*This is a comment*/

Editor's Note: Consider all the following CSS examples a "work in progress". These styles have not been extensively tested using real-world Content Models.

Generic Layout Examples

FYI

The Content Model and Data Model used to demonstrate these layouts can be found in the Grooper importable ZIP file found in the About section of this article.

List Layout

The List Layout styles fields as a simple list. This type of layout will often use margins and horizontal widths to better space out a list of fields and sections of fields. Left margins are often employed to indent Data Sections to make them more visually distinct from fields at the root of the Data Model and other sections of fields.

Below is an example of a generic List Layout style sheet.

CSS

"Info Sheet" Dummy Document Example

Sample Invoice Model Example

label {
  width: 140px;
}

.DataSection .DataField,
.DataSection .DataSection,
.DataTable table {
  margin-left: 32px;
}

.DataSection,
.DataTable,
.DataGridCollection {
  margin-top: 8px;
  margin-bottom: 8px;
}

Flow Layout

The Flow Layout stacks labels on top of their input boxes and lists them horizontally, wrapping fields to the next line when reaching the end of the screen (or containing HTML element). This layout can pack several fields into a relatively small space, conserving screen real estate. Label widths are typically less important to specify uses this layout. Instead Data Field horizontal margins and input widths are utilized to space out fields.

Below is a generic Flow Layout style sheet.

CSS	"Info Sheet" Dummy Document Example	Sample Invoice Model Example
.DataField { display: inline-flex; flex-direction: column; } .DataSection, .DataTable, .DataGridCollection { margin-top: 8px; margin-bottom: 8px; }

Card Layout

The Card Layout relies heavily on Data Sections and borders to create distinct divisions between different kinds of fields on the document. Each section (or card) in the Card Layout will generally implore either a List Layout or Flow Layout within the boundaries of the card itself.

Below is a generic Card Layout style sheet.

This style sheet also uses the hover and focus-within pseudo-classes to lighten the borders around the card upon hovering your cursor and clicking inside the Data Section (focusing within it).
The focus-within pseudo-class was also used to add a drop shadow behind selected Data Sections and Data Tables.
- More information on pseudo-classes can be found at w3Schools.

No background color was added to each card/section. However, that is often included in this style approach.

Because the fields in each card (i.e. the Data Fields in each Data Section) have a List Layout, you could call this a "List & Card Layout"
- However, you could easily use a "Flow Layout" approach instead to create a "Flow & Card Layout". Simply remove the label rule and replace it with one that makes DataField elements some kind of inline element (such as the display: inline-flex; flex-direction: column declaration in the previous tab)

CSS

"Info Sheet" Dummy Document Example

Sample Invoice Model Example

label{
  width: 140px;
}

.DataSection,
.DataGridCollection,
.DataTable {
  border: 1px solid rgba(255,255,255,.25);
  padding: 16px;
  padding-top: 8px;
  border-radius: 4px;
  margin-top: 8px;
  margin-bottom: 8px;
  margin-right: 12px;
}

.DataGridCollection .DataSection {
  border: none;
  padding: 0px;
}

.DataSection:hover,
.DataTable:hover,
.DataGridCollection:hover {
  border-color: rgba(255,255,255,.5);
}

.DataSection:focus-within,
.DataTable:focus-within,
.DataGridCollection:focus-within {
  border-color: rgba(255,255,255,.75);
  box-shadow: 2px 2px 8px rgb(0,0,0,.5)
}

.DataGridCollection .DataSection:focus-within {
  box-shadow:none;
}

Simple Invoice Model Examples

These are a couple different Style Sheet examples for a PO-based invoice model.

Style 1 - Mixed Layout and New Caption Style

For a lot of document cases, you can't perfectly mirror a document's layout because you are processing a lot of different versions of the same kind of document.

Invoices are a good example of this. While you're always collecting (roughly) the same data from invoices (invoice number, invoice date, balance due, etc.), each different vendor is going to have a different format.

This Style Sheet attempts a "mixed layout" approach where the "Header Details" Data Section uses the "Flow Layout" and the "Amounts" Data Section uses a "List Layout".
This mixed approach styles the model to look at least more like an invoice than a flat list of fields.
This Style Sheet also styles the Data Section and Data Table captions differently (just for fun).

Full CSS

Data Model Preview

/*Generic Data Model styling*/

.DataSection {
  vertical-align: top;
  margin: 4px;
  height: 224px;
}

.DataField label {
  width: 120px;
}

.caption {
  text-align: center;
  border: solid rgba(255, 255, 255, .2);
  border-width: 1px 0px;
  margin-top: 16px;
  margin-bottom: 8px;
  padding: 4px 0px;
}

/*Header Details Data Section styling*/

.Header_Details {
  max-width: 416px;
  width: fit-content;	
}	
		
  .Header_Details .DataField {
    display: inline-flex;
    flex-direction: column;
  }

/*Amounts Data Section styling*/

.Amounts {
  max-width: 252px;
  text-align: right;
  margin-left: auto;
  margin-right: 24px;
}

  .Amounts .DataField label {
    margin-right: 8px;
  }

Style 2 - Inline-Block Data Sections and No Captions

This Style Sheet renders Data Sections as inline-block elements.

See the difference in the two Data Model preview images where the "Amounts" Data Section is moved to come before the "Line Items" Data Table'.
This Style Sheet also removes all Data Section and Data Table captions to give you a look at what that looks like.

Full CSS

Data Element Order

Data Model Preview

/*Generic Data Model styling*/

.DataField label {
  width: 120px;
}

.caption {
  display: none;
}
	
.DataSection {
  border: 1px solid rgba(255,255,255,.1);
  border-radius: 5px;
  padding: 8px;
  display: inline-block;
  vertical-align: top;
  margin: 4px;
  max-height: 216px;
}

/*Header Details Data Section Styling*/

.Header_Details {
  max-width: 420px;
  width: fit-content;
}

  .Header_Details .DataField {
    display: inline-flex;
    flex-direction: column;
}

Another Mirrored Layout Example

This is another example of a "mirrored layout" styled Data Model. It aims to more closely mirror the layout of the Application For Cow Ownership document, which is a much more data dense document than our example in the Layout Styling section of this article.

Click Me to Show the Full CSSClick Me to Show the Full CSS

/*Establishes "highlight" CSS class*/

.highlight input {
	color: Yellow;
	font-weight: bold;
}

.highlight label {
	color: DeepSkyBlue;
}

/*Establishes the "blur" CSS class*/

.blur:not(:focus-within) > *:not(.caption) {
  filter: blur(4px);
}

/*Establishes basic styling for Data Sections and Data Tables*/

.DataSection, 
.DataTable,
.DataGridCollection {
	max-width: 876px;
	border: 1px solid rgba(255,255,255,0.25);
	border-radius: 5px;
	margin-top: 8px;
	margin-bottom: 8px;
	padding: 16px;
	padding-top: 8px;
}
	
	/*Colors borders around Data Sections and Data Tables when hovering your cursor over
	them (soft white) and entering fields (bright white).*/

	.DataSection:hover, 
	.DataTable:hover, 
	.DataGridCollection:hover {
		border-color: rgba(255,255,255,.5);
	}
	
	.DataSection:focus-within, 
	.DataTable:focus-within, 
	.DataGridCollection:focus-within {
		border-color: rgba(255,255,255,.75);
  	    box-shadow: 1px 1px 12px rgb(0,0,0,.5), -1px 0px 8px rgb(0,0,0.5);
	}

	.DataGridCollection .DataSection:focus-within {
		box-shadow: none;
	}
	
/*Purely aesthetic rule to extend the background of a Data Table to the width of the
widest Data Section*/

.DataTable {
	width: auto;
}
	
/*Establishes styling ONLY for Data Fields at the first level of the Data Model's 
hierarchy (That is to say any Data Field NOT in a Data Section).*/

.DataModel > .DataField {
	display: inline-block;
	margin-right: 32px;
	margin-top: 16px;
}

/*Aligns Data Field labels vertically on top of their input boxes for any Data Field in
a Data Section and the "Comments" Data Field.*/

.DataSection .DataField, 
.Comments {
	display: inline-flex;
	flex-direction: column;
}

/*Styles the Education section and its elements. Mostly, syling is done to produce two 
inline Data Tables inline beside the single Data Field in the section.*/

/*.Education {
	white-space: nowrap;
}*/

.Education .DataTable {
	display: inline-table;
	padding-left: 0px;
	padding-right: 0px;
	background-color: rgba(255,255,255,0.05);
}

.Education .DataTable .caption {
	text-align: center;
}
	
.Education .DataField {
  text-align: center;
  margin-top: 16px;
}

/*Styles Data Fields in the Signatures Data Section*/

.Signatures .DataField {
	display: grid;
  grid-template-columns: 250px auto;
}

.Signatures .Approval_Signature, 
.Signatures .Signature_Date {
  display: inline-grid;
}

About

CSS Basics

A Common Example: Increasing a Data Field's Label Width

Styling Scope: Selecting Data Elements

Styling Named Elements

Selector Specificity

Selecting Multiple Elements

Intro to Combinators

Styling Descendant Child Elements

Descendant Children Combinator

Styling Immediate Children Combinator

Styling Sibling Elements (Uncommon)

Styling Scope: Summary

Selector Quick Reference

Types of Styling Available

Font and Text Styling

Font Size

Font Style (Italics)

Font Weight (Bolding Text)

Font Variant (Small Caps)

Font Families

Text Alignment

Text Color

Font and Text Styling Summary

FYI: Styling Data Section and Data Table Caption Labels

Styling Data Section and Data Table Caption Labels

Margins, Borders, Padding, Height and Width Styling

The Box Model

Margins

Borders

Padding

Bonus! Border Radius

Height and Width

A Width You Can't Adjust With CSS

Margins, Borders, Padding, Height and Width Summary

Color Styling

Specifying Colors

Text Color

Border Color

Background Color

Layout Styling

Generic Layouts

Mirrored Layout

Use Data Sections to Your Advantage

Block VS Inline Elements

Using Widths and Other Spatial Dimensions - Part 1

Using Widths and Other Spatial Dimensions - Part 2

Option 1: Change "Street Address" to a Block Element

Option 2: Adjust Input Widths and Let Elements Wrap Lines

Full CSS with Comments

Tips and Best Practices

Two Approaches: Global Element Styling VS Local Element Styling

Styling Flat Data Models VS Hierarchical Data Models

Creating and Using CSS Classes

Example Classes

Highlight Class

Blur Class

Examples

Generic Layout Examples

List Layout

Flow Layout

Card Layout

Simple Invoice Model Examples

Style 1 - Mixed Layout and New Caption Style

Style 2 - Inline-Block Data Sections and No Captions

Another Mirrored Layout Example