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

[Ian Hickson]

On Mon, 18 Jul 2005, Dimitri Glazkov wrote:
>
> 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 markup?
> 
> 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 
> necessary.
> 
> 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.
> 
> Whaddayathink?

This sounds overly complicated, and quite similar to what XBL2 allows. I'm 
not sure it's something we would want in HTML5, though. In particular I'm 
not really sure what problem we're trying to solve here -- that printing 
is inconsistent when GreaseMonkey scripts are involved isn't really a 
high-priority problem as far as I can tell.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'