KHTML Paged Media - Status Report

Bert Bos bert at
Wed Aug 24 20:48:30 CEST 2005

Thanks for that report, Allan! Some comments below.

On Saturday 20 August 2005 12:31, Allan Sandfeld Jensen wrote:

> Page-breaking inline children is in the simple form done much similar
> except that lines are always assumed not to break themselves, and
> always cleared if crossing page-breaks. Handling the CSS orphans and
> widows turned out to make it harder though. Violating orphans is
> simple just don't break and let the parent move the block across the
> page-break. Violation of widows is much harder. Since we layout one
> line at a time, it is impossible to know if we will later violate
> widows when we encounter a page-break. The solution so far have been
> to postpone the widows check until all lines have been layouted. If
> there is a violation I then set a hint to what line _should_ have
> been broken, and redo the layout.

Not only for widows and orphans, but also for higher-quality line breaks 
(in a future version of the browser...), it would be good to consider 
text a paragraph at a time. If the spaces in one line are compressed in 
order to break at a good point, then you don't want the spaces in the 
next line to be expanded too much. The lines will look too different.

(A "paragraph" in this case is something like all the text between two 
forced line breaks.)

Even harder is to avoid "rivers," i.e., spaces that occur almost exactly 
above each other in two or more successive lines, because they make the 
text look as if it has two columns.

Trying different line breaking points in order to find the best one may 
be too slow for interactive display, but for a printed page that isn't 
a problem.

> The last ironic standard problem are websites importing their
> style-sheets with a "screen" media selector. This means the
> style-sheet doesn't apply for "print" media, basically producing an
> unstyled webpage. It appears to support broken web-sites a "screen"
> media selector should be treated as "all".

Please don't do that. By trying to fix some people's errors now, you 
break style sheets for other people, now and in the future.

Extensibility is a very important but also a very fragile thing. If you 
break conformance, you often break extensibility as well. Adding new 
media or new Media Queries to the browser later will not be possible 

It is OK if you want to provide a feature with which people can print a 
screendump, but then please call it "screendump." (And note that in 
that case, any page-break properties have to be ignored, because they 
don't apply to 'screen' media.)

> I've decided to expand CSS 2.1 as well. For presentations and other
> non-print paged media it just not good enough to use a "@media print"
> selector. I am experimenting with adding media-groups as valid
> selectors making "@media paged" and "@media static" possible.

If you do that, call them @media -kde-paged and @media -kde-static.

But are you sure you need those? What is the difference between 'paged' 
and 'embossed, print, projection, tv'?

If you think they have a role, why don't you write up what they mean and 
propose them to the CSS WG?

And a question, since you mention @media: do you support Media 


  Bert Bos                                ( W 3 C )                               W3C/ERCIM
  bert at                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

More information about the Kde-soc mailing list