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

Mike Emmel mike.emmel at gmail.com
Sun Oct 8 13:32:55 PDT 2006


On 10/8/06, Rob Burns <robburns1 at mac.com> wrote:
>
> On Oct 7, 2006, at 8:01 PM, Mike Emmel wrote:
>
> > On 10/7/06, Rob Burns <robburns1 at mac.com> wrote:
> >> > I disagree this has nothing to do with webkit:  Is the webkit team
> >> > aware that when printing half of all the web pages out there the
> >> > output looks like doodoo?
> >> >
> >> > Whatever the CSS, having the pages print out in a totally ugly way
> >> > is just plain silly.    Surely using the "screen" stylesheet for
> >> > printing is better than no stylesheet at all?
> >> >
> >> > I propose  that WebKit use the "screen" stylesheet for printing if
> >> > there is no "print" stylesheet present in the source document.
> >>
> >> I think half of all web pages out there is probably an exaggeration.
> >> I think most authors use "all" for the media type unless they are
> >> specifically targeting the screen. The Surfin' Safari blog had
> >> discussed a common mistake of using device dependent units when using
> >> the "all" media type, but I guess WebKit already adjusts for that. I
> >> could imagine a site targeting the screen with a design really only
> >> meant for the screen. Printing using that CSS would be worst than
> >> falling back on the default stylesheet.
> >>
> >> take care,
> >> Rob
> >
> > Since the case of a screen only css style sheet can be detected does
> > it not make sense to make using it an option of the print dialogue. In
> > fact a more general ability to pick a alternative style sheet when
> > printing might have other uses.
> > Or this could be a user option in the browser turned on by default.
> > Or it could cause a  warning or alert and let the use choose.
> >
> > The chance of no style sheet vs screen only being correct  in the real
> > world is probably close to zero.
>
>
> As I said before, I think this is a discussion not too related to
> WebKit, but more to the application developers who may use WebKit or
> any other engine to create a user-agent. My understanding is that
> WebKit already has the needed methods to handle this at the
> application level.
>
> However, let me just add that CSS is designed to give authors rich
> capabillities in terms of presentation and when an author selects
> "screen" instead of "all" as the media they're targeting  for their
> stylesheet, that says something. And it's something that user-agents
> and users themselves should take seriously. Could it be a little
> mistake with large consequences? Yes. But it couls also be the
> authors intent. And building user-agents that gloss over those
> mistakes just make the mistakes more prevalent. So if many authors
> use a WebKit based application to test their designs and that
> application makes "screen" seem like "all" then such mustakes will
> proliferate. That's a concern that application developers should keep
> in mind.
>
> take care,
> Rob
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>

Leaving it unset does not tell us if the author made a mistake that
should be handled
gracefully or if it was the authors intent.

I think if you want no style sheet the css author needs to set print to empty

<STYLE type="text/css" media="print">
 </STYLE>


Assuming no value was intentional is not correct IMHO.

Since the author can  easily make his intention clear if its important.

Humans make mistakes software that can recover gracefully should.

Allowing the end user to change the default decision if its not
correct is also important.
Notifying them that a potential error condition is occurring
makes sense.

Not considering using the screen css in this case is not correct since
you can't differentiate between a human mistake and intention.

And I do agree not not directly related too the webkit code.
But a bit of documentation on style sheets and media types would
be useful for people embedding webkit. They can decide how to treat
this case but it does not hurt to point it out.



More information about the webkit-dev mailing list