Skip to Content

When one has been a web developer for as long as I have, one could find oneself getting set into one’s habits and not look further than one’s, in my case long, nose. For some aspects of web development I still think in specifications of the early days. Being an old-school developer has its advantages when it comes to cross-browser compatibility, but one can lag behind when it comes to fancy stuff. And with all due respect, all these code generating techniques and tools, like HTMLB and Web Dynpro don’t make it easier. First of all, they take over all control and secondly one can’t learn from the code that is generated. Have you ever tried looking at any such generated code? It’s a tangled ball of references, mostly put on one line, and not very appealing to learn something from.
It’s only after working together with young sports like Valery on things like SDN World that one realizes how outdated one is getting. His JavaScript quizzes are very interesting brain-teasers which made me both reconsider things and challenge me to find things out.
The following two little requirements that I was asked to implement recently are a perfect example.

Don’t print
I was asked the other day if it was possible to leave out some info – in this case some click buttons – on a printout of a web page, since these buttons serve no purpose at all on paper (for the obvious reason that one can’t click on them). In the old days I would have started creating a second page for printing purpose. The disadvantage of that is obviously the fact that I would then need to maintain two pages. That could be solved by using page fragments (in BSP) as much as possible or by parameterising the page. The problem with those solutions is that they are all server dependant and don’t work when the user just uses File->Print.
We needed to find a solution that works on the client side of life. One doesn’t need to look far when you know that mostly 3 things are involved on the client: HTML, Javascript and CSS. The latter brought us the solution. You might know that one can easily manipulate things enabling it to be either shown or not. I elaborated on this in an earlier article and it boils down to:

.notprinted { visibility: hidden; display: none }

Now we need all the things that we don’t want to see in e.g. a DIV

If you try this out, you will see that you won’t see anything. The info that you want to hide, doesn’t show on screen either. In order to solve this, we need to say that this CSS is only applicable for printing


 

Give me a break
Another classic is the need to put page breaks in a print out. My standard answer is that this isn’t possible, since HTML is a screen oriented language and doesn’t have any tags for controlling pages. That is indeed true, but CSS comes again to the rescue in a familiarly simple way.
There is namely a page-break-after property that sets the page-breaking behaviour after an element

page-break-after

before an element

page-break-before

or inside an element

page-break-inside

One can specify the behaviour of these page breaks

auto               insert a page break if needed
always             always insert a page break
avoid              avoid a page break
left               insert a page breaks until it reaches a blank left hand page
right              insert page breaks until it reaches a blank right hand page

The page-break-inside has only the auto and avoid values.

There are some limitations and advice within the CSS 2 specifications though:

  • Page breaks are not allowed in absolutely positioned elements.
  • It should occur as few times as possible.
  • It should be avoided inside tables, floated elements and block elements with borders.
  • Pages that are not forced to break should have approximately the same height.

If one wants to use all this information in a practice, it comes to this for example :

P.break
{
page-break-after: auto;
page-break-inside: avoid;
}

In our HTML we then put the block we want a page break after, but not inside the block itself, inside the

element

 

Conclusion
As you can see, things evolve and make the life of a web developer easier. It can sometimes be helpful to teach a (grumpy) old dog new tricks – as long as the dog is willing to learn.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply