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

Converting HTML Tags to XPage Tags

As xPages becomes a common platform for other modern web frameworks, you may find yourself writing a lot of standard HTML (such as Twitter Boostrap markup) in your Domino Designer source panel.  Here is a convenient reminder that most HTML tags can be converted to xPage tags by adding the xp: prefix.

So,

<div>...</div>

becomes

 

 <xp:div>...</xp:div>

Now it may not be immediately obvious why this would be a useful pattern but xPage tags have with them all the API hooks that are available for the standard xPages controls.  One use case could be to leverage server side logic to selectively render certain parts of your code.   For example you might have some mark up that resembles this:

<div id="show-when-editable" class="row">
<div class="col-md-2">...</div>
<div class="col-md-4">...</div>
<div class="col-md-6">...</div>
</div>
<div id="hide-when-editable" class="row">
<div class="col-md-2">...</div>
<div class="col-md-4">...</div>
<div class="col-md-6">...</div>
</div>

If you want to show the first div in edit mode and the second otherwise you could convert the above to the following:

<xp:div styleClass="row">
<xp:this.rendered><![CDATA[#{javascript:document.isEditable()==true}]]></xp:this.rendered>
<div class="col-md-2">...</div>
<div class="col-md-4">...</div>
<div class="col-md-6">...</div>
</xp:div>
<xp:div styleClass="row">
<xp:this.rendered><![CDATA[#{javascript:document.isEditable()==false}]]></xp:this.rendered>
<div class="col-md-2">...</div>
<div class="col-md-4">...</div>
<div class="col-md-6">...</div>
</xp:div>

A couple things to note about this type of tag conversion:

–  <xp:div> tags don’t respect normal HTML attributes.  For this reason, you need to also convert class="class-name" to styleClass="class-name"

– To use other attributes you can add an attribute block.  For example, code to add a data-title="My Title" to your tag would look like this:

<xp:this.attrs>
<xp:attr name="data-title">
<xp:this.value><![CDATA[#{javascript:'My Title'}]]></xp:this.value>
</xp:attr>
</xp:this.attrs>

– I haven’t tested this with all legal HTML tags, so there may be some incompatibilities but it does work well with most of the standard building block tags used for construction Boostrap grids and tables.  If you know of other limitations, please feel free to share.