[whatwg] several messages

[Ian Hickson]

On Sun, 17 Jul 2005, Dean Edwards wrote:
>
> Anne van Kesteren wrote:
> > Shouldn't the print method on the window DOM interface be defined as well?
> > 
> > Example: <button onclick=window.print()>print</button>
> 
> IE has some nice onbeforeprint/onafterprint events. Can we add these 
> too?

Defined both.


On Mon, 18 Jul 2005, Olav Junker Kjær wrote:
> 
> Arent these event mostly used to transform the view before printing it? 
> I think this is better handled by a print-specific style-sheet today.

There are some things for which CSS just doesn't work, sadly.


On Tue, 19 Jul 2005, Greg Kilwein wrote:
> > DG wrote: 
> >
> > a) my invoice format requires a timestamp that says something like 
> > this: printed by [person] on [timestamp].
> > 
> > b) To capture the essence of the browsing session, I would like to 
> > build a breadcrumb at the bottom of the printed page, displaying 
> > titles and urls of pages the user have visited on the site during this 
> > visit.

This is now possible.


> I'll add another case: the onafterprint event could be used in a 
> "wizard"-style application where printing some document is step 3 of 10, 
> for example.  The application could proceed to the next step (not 
> necessarily a different document) automatically without requiring a 
> button that says "click here when done printing".  That's a case that a 
> media-specific stylesheet cannot handle.  Automating tasks and reducing 
> clicks are both high priorities in my development of web applications.

Good use case!


> If the ability to set printer settings such as portrait/landscape is 
> available, an "onbeforeprint" event could be used to prompt the user 
> whether they'd like to automatically switch their paper orientation to 
> portrait or landscape before printing.  (The same can be said for 
> margins and headers/footers.)  This can be done in the print dialog, but 
> if it is truly important to how the page prints, a separate step that 
> highlights the importance of the print setting to the user would be 
> helpful in reducing calls to my company's tech support line.

As specified, you could indeed use showModalDialog() for this.


[snip other use cases]

On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>    Once again, I don't understand why you can't simply provide the user 
> with a button on the web page that either calls up a printable version 
> or clones the document so that the clone can be used for printing. 
> (Granted, there probably isn't support for the latter, but it makes more 
> sense to standardize that than to add onbeforeprint and onafterprint, 
> especially when you consider the fact that a clone of the document can 
> be held in memory for repeated printing or dumped.)

I don't see why we shouldn't have both; after all, people are using 
onbeforeprint today, and it doesn't seem to have caused a disaster or 
anything.


>    As far as I can tell, no part of WF2 or WA1 encourages malicious 
> behavior on the part of the webmaster against the users. In fact, part 
> of the problem I had with <dataentry> was that it could, in theory, be 
> use in a hostile way towards legacy user agents. Therefore, I doubt this 
> will ever make it into a WHATWG spec, especially when it can interfere 
> with simple things like printing selected text, et cetera.

This hasn't happened much, but certainly a user agent could disable 
scripts while it is printing.


>    Now you've completely lost me, use-case-wise. On an intranet, why is 
> a printable version of the document not an acceptable workaround?

Well it's not as nice, is it. I mean, it's not the same experience really. 
Look at printing in Google Maps, for instance, where it brings up another 
page -- it's not as seamless as just printing the current page.


>    Here's a question for you to chew on: What happens if you want to 
> print and the webmaster screwed up something in the onbeforeprint or 
> onafterprint event? Will it effectively disable printing? Will the 
> document be restored once printing is finished? What if it's an AJAX 
> application and the UI of the app is hidden for printing but never 
> restored?

This can all happen without printing too.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>    I think there's good enough reason to disallow a feature when you 
> have the following:
> 
> 1) The feature can be abused.
> 
> 2) It alters the standard behavior of the browser.
> 
> 3) It can be easily disabled with a modified open source browser or 
> browser extension.

...or the browser can just allow it to be overriden. Point 3 basically 
counteracts the first two, imho.


> 4) Its use cases are partially covered by CSS.

CSS is just as susceptible to 1 and 2, why isn't that a problem?


> 5) There are existing workarounds.

Workarounds are just that. Not solutions.


> 6) An alternative has been proposed that has less potential for abuse, 
> is more powerful, and doesn't change basic browser functionality.

I don't see how it has less potential for abuse, really. I also am not 
sure it's really more powerful.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
> Since CSS is not required for HTML compliance, let's look at how a 
> non-CSS browser would be effected by onbeforeprint/onafterprint. Without 
> these events, the printout of the page would always match what you have 
> on screen (barring the user agent deliberately making it look 
> different).

JS is also optional, so this is equivalent.


> Therefore, while using this browser, if I see something that says the 
> following...
>
> | Matthew is a great guy.
> 
> ...and I print it, I would expect the printer to print out this:
> 
> | Matthew is a great guy.
> 
>    By contrast, I would not expect the printer to give me the following:
> 
> | Matthew is a complete luzor!!!
> 
>    That's what these events enable, and that's a fundamental alteration 
> of the expected behavior of a user agent's printing function.

CSS and JS both allow this. Both are optional.


>    So it's useless for keeping people from printing stuff without paying 
> if the people in question really want to print something.

We're not trying to address that use case.


On Wed, 20 Jul 2005, James Graham wrote:
>
> Just to muddy the waters a bit - it is quite likely that Gecko 1.9 will allow
> pages to be 'exported' to a variety of formats (in a manner analogous to
> http://gecko.dynalivery.com/ ). Clearly I have no idea what the UI for this
> functionality will be but lets pretend that it's not through the standard
> print dialog (this isn't strictly important). Should any function that
> transforms html -> non-html fire hypothetical onprint events?

As defined, no, it's just for getting a physical form or a representation 
of a physical form. What that means is someone a judgement call for the UA 
implementor, I guess.


On Wed, 20 Jul 2005, Dean Edwards wrote:
> 
> The big problem for me on this whole onbeforeprint/onafterprint argument 
> is that I only have partial control of the DOM using JavaScript.
> 
> What do I mean by this?
> 
> I can create content using the window's load event:
> 
> onload = function() {
>  // create content for screen
> }
> 
> This content, which is not suitable for print, needs to be removed when 
> the document is printed. I can even invoke the print method myself:
> 
> window.print();
> 
> I'm told I must use another language to remove the content. CSS you say. 
> Doesn't that seem wrong? Why can't I do it with script? I created the 
> content with script. Why can't I remove it the same way?

Both are now possible.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>    The one I've been pushing for the last few days: allow scripting to 
> create a copy of the document, manipulate the copy, and print from the 
> copy. That way, the app will just have a button that says "Print High 
> Quality Version" or something, and a script clones the document, makes 
> the appropriate changes, and prints it. When you press the button again 
> (because you forgot you wanted two copies), the script can detect that 
> no changes have been made and simply use the last cloned document 
> object:
> 
> | if (documentchanged) {
> |   printClone = document.clone();
> |   prepareForPrinting(printClone);
> | }
> |
> | printClone.print();
> 
>    Hmm, that prints from the document object instead of the window, 
> though. Is there a better way to implement this?
> 
>    The general idea, though, is that when I print a web page, I want to 
> print a web page, not some altered version of the web page a webmaster 
> sees fit to allow me to print. Specific print version should be handled 
> by UI in the page itself. (Or perhaps with a <link> element.)

You can basically do this, just print an iframe or some such. The events 
don't preclude doing this.


On Wed, 20 Jul 2005, Dean Edwards wrote:
> 
> I quite like the idea of a DOMModified event. Does this exist? Can we 
> have it please?

Mutation events are out of scope for HTML5, but do handle this kind of 
thing. They need work, though.

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