When ‘font-weight: bold’ Is Not Quite Right

Lately I’ve been doing a lot of front-end UI work and in doing so there have been situations where I want to call attention to a piece of text.  Sometimes displaying the text in a BOLD font-weight is just right, but other times that feels more like cracking a nut with a sledge hammer.  CSS has supported a more granular approach to the font-weight attribute for some time but it’s a feature that can be easily forgotten.  In addition to normal, bold, and italics designations, you can use relative terms like “lighter” or “bolder” which apply the weight relative to the parent element. Perhaps more useful is the numeric designations available.  CSS supports font-weight’s of 100 to 900 in even increments of 100.   The catch is that the font you are using needs to support that level of granularity.

I had planned to code out a whole series of examples but I found an article that has already done this so no need to go through that exercise.  Read here to see examples of what this looks like and more details on how it’s applied to fonts that only support the normal and bold font-weights.

CSS Tricks: Font-Weight

Hacking the xPages Data View CSS to Enhance Display

A few weeks ago I was tasked with creating a new printable version of our corporate directory for use in production areas where phones were not located near workstations.  Until this point this list had been maintained manually.

After looking around at a few options I settled on the Data View control from the xPages Extension Library.  This control allows one to easily set the number of columns, which in my case was important because they wanted specifically a four column display.

Our corporate directory has three data types in play here:  location documents, individual person documents and documents for all other non-individual phone numbers.  First I set up the source view categorized first by location and secondly by the phone category.   It looked something like this (the data below has been changed for privacy).

Source View in Notes

Source View

Connecting that data source up to the data view control yielded initially a display that was far from what I was seeking.

Unformatted Data View

With some CSS overrides and jQuery DOM manipulation I was able to convert that to this:

Data View Formatted

Ahhh, much better.  Below is the custom CSS that I used.  The first six are just custom classes I used to style the site headers, category headers as well as the detail sections.  Basic stuff.   Then I used two classes that were already included in the xPages extension library theme I was using.  Adding them to my custom CSS allowed me to override some margins and spacing. Finally the last two classes are used by the jQuery code to enhance the breaks between locations.

/* Custom Classes */
.catSite {
font-family: Calibri, Candara, Segoe, "Segoe UI", Optima, Arial, sans-serif;
font-size: 18px;
color: #365F91;
.catCategory {
font-family: Calibri, Candara, Segoe, "Segoe UI", Optima, Arial, sans-serif;
font-weight: Bold;
font-size: 14px;
color: #365F91;
padding-top: 8px;
.siteDetail {
font-family: Calibri, Candara, Segoe, "Segoe UI", Optima, Arial, sans-serif;
font-size: 12px;
color: #365F91;
.nbrDetail {
font-family: Calibri, Candara, Segoe, "Segoe UI", Optima, Arial, sans-serif;
font-size: 12px;
.nameCell {
width: 165px;
border-bottom: 1px solid #ddd;
.nbrCell {
width: 40px;
border-bottom: 1px solid #ddd;
text-align: center;
/* Overrides to Existing Classes */
.lotusTable td {
padding: 0px;
border-top: 0px;
.lotusTable th {
padding-top: 0px;
border-top: 0px;
/* Type Selector Formatting */
h2 {
font-family: Calibri, Candara, Segoe, "Segoe UI", Optima, Arial, sans-serif;
font-size: 24px;
padding-left: 10px;
hr {
background: #8C8C8C;
clear: both;
float: none;
width: 100%;
height: 1px;
margin: 0 0 0.6em;
border: none;

The jQuery code I used is run from the onPageLoad event.

//jQuery magic to enhance formatting by manipulating DOM
//Removes some extra white space at the top of the page
//Remove Top Level Categorization
//Replace + with horizontal rule for each site
//this sets each site off from the previous
var s1 = $(".catSite");
$.each(s1, function( index, value ) {
  var s2 = $(this).text()
//remove the nameCell and nbrCell class from the site class elements to eliminate extra underline
//replace the address delimiter tilde from view data with break tag to start a new line for each address data
var d1 = $(".siteDetail");
var d2 = d1.parent()
$.each(d1, function( index, value ) {
  var d3 = $(this).text()
//add horizontal rule at the end of the list

Really not very much code to achieve a nice result.   Of course, there is still the overhead of the extension library code and the CSS that is loaded there is large and cumbersome to override in places.  If you wish for more styling flexibility there are other options.   In my next post (hopefully next week) I will demonstrate how to use a JSON feed from a Notes view to write out the same data without using the Data View control (hint: it also involves jQuery and a special jQuery plugin).