[webkit-dev] a question on printing: whither WSIWYG?

Mike Fischer mf_software at mac.com
Sun Oct 8 09:21:31 PDT 2006

Am 08.10.2006 um 17:09 schrieb Mike Emmel:

> On 10/8/06, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
>> All this boils down to is two different ideas of printing really:
>> 1. Print as specified in CSS. This typically produces better  
>> output in pages
>> that have been designed for printing.
>> 2. Print screenshot. This produces an exact print of what is seen  
>> on the
>> screen. This produces worse results in some cases due to page- 
>> breaking
>> problems etc.
>> 1 is nice for printing papers, but 2 is what most users expect.
>> A choice like this "should" be available in a print dialog.
> Add
> 3.) Print with a user specified css stylesheet.

I've never understood what user defined stylesheets are good for  
apart from a few situations where people with visual impairments  
might benefit from certain general adjustments. But that's just me I  
guess. I generally think that the stylesheet and the markup are too  
closely intertwined for user defined stylesheets to be useful in all  
but the most simple cases.

> Default choices would be the screen style sheet and  the style sheet
> for printing defined by the page author.

As long as I can permanently change the default choice back to what  
the author intended (the way it currently works) I'd accept that as  
an option. I'd hate to have to do this each time I print a web page.

> A user specifed style sheet when printing  allows you to get it  
> just right tm.
> The default setting in the print dialog should be to use the screen
> css if no print css is specified. This has nothing to do with
> standards. At worst a warining about this situation could be
> displayed. The logic is that if it needs a style sheet for the screen
> the chance of not needing one for printing is slim.

This might be the case sometimes but I see no reason for it being  
this way in the majority of cases. Got any further evidence? Take the  
example that started this thread. The result of not using the screen  
stylesheet (and not having a print stylesheet) works out quite nicely  
I think. Sure it could be polished using a print stylesheet but the  
result without it is easier to print and read than the screen version.

I think the basic problem here is expectations. Some people seem to  
expect the printout to look exactly like what they see on screen.  
Even if that means it's unreadable or with nonsensical page breaks  
etc. The feature of having different stylesheets tied to different  
media types seems to somehow be too good because it results not only  
in better but in different rendering than on the screen. Mind you I  
don't see it this way at all but it's the only reason I can see that  
we're discussing this here.

If this is the core of the problem then any option to allow printing  
WYSIWYG would solve the problem. Though I use WYSIWYG loosely here  
because it is unlikely that the window size matches the printed page  
size. This will lead to different layout even with the same  
stylesheet thus not really WYSIWYG.

> The choice of style sheet would be by default
> 1.) User defined
> 2.) Print css
> 3.) Screen css
> 4.) No css ( system css)

5.) CSS as specified by the author of the web page. Please, this  
option must be possible and IMHO should be the default.

> Preferences can be used to change the order.

Huh? This implies that your method is incapable of printing a page  
the way the author intended unless the author includes a print  
stylesheet. That doesn't strike me as a good solution.

If any changes are made I still vote for an option that lets the user  
print and/or display a page with a specific media type. That would  
solve the problems with differing expectations, be useful for  
developers and allow the authors choice to prevail in the standard case.

Mike Fischer         Softwareentwicklung, EDV-Beratung
                                     Schulung, Vertrieb
Web: <http://homepage.mac.com/mike_fischer/index.html>

More information about the webkit-dev mailing list