- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 6 Jun 2008 00:11:45 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 5 June 2008 17:11:45 UTC