W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2005

[whatwg] [html5] window.print() undefined

From: Dimitri Glazkov <dimitri.glazkov@gmail.com>
Date: Mon, 18 Jul 2005 18:45:07 -0500
Message-ID: <fb15ac21050718164533afb23@mail.gmail.com>
What do you guys think about this -- and this is just theoresizing and
hypothizing :)

Print representation, if defined, should probably not be viewed as the
byproduct of the screen presentation.

For instance, if script modified DOM properties in the screen
presentation, these changes should not affect the print presentation,
and vise versa.

How is this accomplished? I've been thinking about "DOM sandboxing"
idea lately, and it seems interesting, but I haven't have time to cook
up anything delicious quite yet. So, here's the half-baked version:

DOM Sanboxing

Markup is serialized content that comes over the wire. DOM is an
object representation of markup. This representation can be (and
routinely is in Web apps) modified to something else.

This would've been perfectly hunky-dory if the modifier of the DOM was
the only player in the game. However, with the advent of the
"GreaseMonkey" era, the rules a-changing. Now, instead of one UA, you
have multiple UAs (let's call them UA-plets) of various degrees of
completeness and importance, custom to each client, all operating
inside of one big UA called the modern Web browser. This has certain
unexpected and hard-to-regulate effects. How do you make sure that the
semantics of DOM tree have not been messed with, so that a UA-plet
that relies on semantics could still get its turn at the original

So, here's proposition minimus: store the original DOM tree and make
it always accessible, regardless of what the final DOM tree will look
like. It is, after all, the purest representation of data. The
original DOM tree is read-only and can not be altered.

Now, a proposition maxiumus: allow access to the original DOM tree AND
provide facilities to create a mutable snapshot of it. This way, the
UA-plets can have the cake and eat it, too: they can view DOM
representation of the original markup, and also tweak it as they see

This implies, of course, that "printing" is a UA-plet: it simply gets
the original markup and either simply applies stylesheets to it or
tweaks it as necessary, then sends it off to the printer.

In effect, this allows the overarching UA environment (the browser) to
"sandbox" DOM manipulation for specific purposes of each UA-plet, be
that rendering for viewing, printing, or hCalendar data harvesting.


Received on Monday, 18 July 2005 16:45:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:41 UTC