As a .Net developer, I have naturally gravitated toward Asp.Net for building web applications. However, the past few years I have eschewed web forms for the modern ajax style of development, especially the SPA. One reason I do still create .aspx pages is to build reports with tools like Telerik reporting or Microsoft .rdlc. I couldn’t find a good way to make reports without a server-side technology and The Google lead me down many sub-optimal paths. Finally, I have figured it out, and it was easy. I am embarrassed to announce that I didn’t know this before, but maybe some of you are as dumb as I am and this blog post could help.
- Display reports in the browser.
- Make them display well on different screen sizes (viewable on mobile, but not too concerned with most reports being mobile friendly).
- No dependency on 3rd party frameworks like Bootstrap or JQuery.
- Make them printable, meaning they fit well on the printed page and (usually) page break at appropriate locations.
- Show date of report and page x of y on each page.
I have mocked up a sample report designed as an Invoice. The source code as a gist is here
This is what it looks like:
Not bad, right? The layout is completely CSS. Styles like display: table and display: table-cell are what make the invoice lines layout in a table-like structure. Of course you can use the good old <table> and that is fine for such things. Just don’t layout your pages with tables or the HTML5 police will bust you. For more complicated reports you will want to use <table> elements to support column and row spanning since the css styles do not support those features.
For simplicity,I intentionally left out the dynamic aspect of HTML-only reporting. Of course you will want to combine this technique with templating and data binding to generate actually useful reports. In a future blog post I intend to make a simple example of this with AngularJS.
Now, the printing.
To keep things simple and to demonstrate how to make a printable web page, I simply copied my existing styles, put them in a separate style element with media=”print“, and changed all the pixel (px) sizes to points (pt). Using points as sizes is the key to printing. If you are like me, you may have found people recommending certain font sizes and certain max screen widths in pixels. Forget about it. Each point is 1/72 of an inch. Therefore 72 points is one inch and that is exactly how it would print. Pixels on screen do not translate well to the printer for various reasons. Use percentages and pt sizes to make sure you stay in the page bounds.
Here is what the Print Preview looks like in IE11. Notice how the “Page x of y” is displayed, the file name, the date, the URL and even a custom message. All of these items can be shown or hidden by the page Setup dialog and all modern browsers have access to these fields.
Something else you will notice is how the invoice lines do not run onto another page. This is achieved by the page-break-inside: avoid; style. Chrome browser does not honor this which is too bad. From Chrome you can export to PDF which is a great argument for HTML-only reports. But it doesn’t avoid page breaks like IE does.
So here I have demonstrated how simple a screen and print report can be. Obviously there are advantages to the 3rd party reporting tools. But I would argue not so many. If you can satisfy your requirements with this technique then you will be better off for it. Have you ever upgraded your Microsoft or Telerik reports to a new version and had hours of clean-up to do? Re-compile and re-deploy dlls? That could be a thing of the past and now, for me, it is just that.