Re: Microsoft has now joined the HTML Working Group

Dao Gottwald wrote:
> Matthew Raymond wrote:
>>> Maintenance.  No one wants to maintain separate print versions of their
>>> pages.
>>>     
>>    This is a poor argument.
> 
> It's not. Having to keep two versions of the same page in sync is 
> additional complexity that should be avoided where possible.

   You already have that scenario with |onbeforeprint| and
|onafterprint|. In fact, it's worse. Not only are you using a transform
to generate a new document for printing, but you're transforming it into
 a third document which may or may not be identical to the original. On
top of that, you're doing it on different user agents, so minor
differences or bugs in the user agents can cause the events to produce
different results, in some cases with catastrophic results.

>> The scripting in |onbeforeprint| is
>> performing a transform that can be just as easily done on the server. In
>> fact, it can be done with a higher reliability because the software and
>> hardware are always the same and under the complete control of the
>> webmaster, and the result can be cached to improve performance. If done
>> intelligently, maintenance isn't even required.
> 
> It scales horribly in terms of that you actually want to print the 
> current state of a potentially dynamic, ajaxified page.

   First of all, if all your state information is on the client, you've
designed a poor web application, AJAX or not.

   Second, there's no reason you couldn't simply AJAX-ify the print
version of the document. When the user clicks "print version", simply
run the same scripts you would have put into |onbeforeprint|, and when
they click "return to previous page", you run the script you would have
put into |onafterprint|. The buttons are easily hidden with CSS when you
print. This has the advantage of allowing the user to decide if they
want to print a "printable" version rather than forcing it down their
throats every time they want to print a couple of paragraphs.

   Remember, the user can override CSS, but they can't override markup.
Nor can they risk turning Javascript off when running an AJAX application.

> And it decreases
> both client- and server-side performance in all cases that I can think of.

   Performance is not an issue if the transform is an optional part of
the AJAX application's interface rather than an event hidden to the
user. The transform will take nearly an identical amount of time an
memory to perform, and the user has the option of just hitting the print
button instead, which is even faster than |onbeforeprint| and
|onafterprint| because no transforms are performed at all.

   If the content is essentially static for a given time period or set
of variables, the transform can be cached on the server and the
performance hit is only that of downloading the cached file. This has
the added benefit of quality control, as the user is always guaranteed
to receive the same print document for any given set of content.
Furthermore, this is totally compatible with legacy browser that don't
support |onbeforeprint| and |onafterprint| and browsers that have the
feature either turned off at the browser level or have scripts that
remove the events when the page loads.

   Of course, performance-wise, CSS beats everything hands down. ;)

Received on Wednesday, 11 April 2007 11:00:58 UTC