Re: Microsoft has now joined the HTML Working Group

Chris Wilson wrote:
> Matthew Raymond [mailto:mattraymond@earthlink.net] wrote:
>>   Interesting, but why wouldn't the underlying plug-in architecture
>> handle the rendering of plug-ins in different rendering contexts, such
>> as printing? Why have an event specifically for a single media if this
>> issue might exist for other medias? Can you give a use case where a
>> plug-in needs to be informed of printing via a scripted event in HTML?
> 
> Possibly.  You raise an interesting point, but perhaps the reason is
> because we don't ever "switch media" to anything else (though of course
> a UA could do that - for example, when you switch to "projection") - but
> I'd point out that print is kinda special, at least the way we implement
> it today - because print is non-interactive, and must capture a single
> instant in time.

   I think we need to expand our definition of that a "print" media
might be. At this very moment, people are doing research on flexible
displays, about the size of a sheet of paper and not much thicker, that
users can interact with. In the future, "paper" may be just another type
of computer display. Or it may be that we still use traditional paper,
but the DOM and other data may be encoded into a printed document in a
way the human eye can't see. This data could then be scanned from the
page, and the exact state of the HTML document at the time of print can
be retrieved. Traditional concepts of print may not serve us well in ten
to twenty years.

> I'd have to do a deeper thought exercise to think of a
> particular case for you.

   I would very much appreciate that. All use cases need to be carefully
evaluated.

>>   With the potential for abuse (crazy DRM schemes and malicious
>> alteration of the document to prevent printing of content), bugs (the
>> page doesn't have the correct print presentation or the changes to the
>> document aren't undone after printing) and circumvention (turning of
>> Javascript temporarily or using a script to remove the attributes), why
>> isn't having a separate printable version of a document not a better
>> method of addressing this issue? Couldn't you use link to point a <link>
>> to an alternative print version of the document and have the user agent
>> prompt to use this version when the user hits the browser print button?
> 
> Maintenance.  No one wants to maintain separate print versions of their
> pages.

   This is a poor argument. 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.

> If they do, they typically have a PDF version today anyway.

   I do believe that PDF will be less dominant as CSS improves (and user
agent support thereof). However, I also think that at this happens, the
demand for |onbeforeprint| and |onafterprint| will also diminish.

>>   Also, as an alternative, why can't a "print" button in the HTML
>> trigger a script that copies the document object, alters the copy,
>> prints it then disposes of it without ever touching the original
>> document? (I've heard that there may be memory issues with this, but
>> there's no obvious reason to restrict this for smaller documents.)
> 
> Because "print" as a verb is integrated into the UA.  I hate having to
> hunt around to find a "print" button on the page - as a user, I like
> being able to hit control-P, or hit the print button.

   Point taken, although I still see a lot of print buttons in markup,
and some people don't know the keyboard shortcut and don't have a print
button on their toolbar. That doesn't really cover my <link> suggestion,
though.

   One thing I forgot to ask about in my earlier post is the printing of
selections. Should |onbeforeprint| and |onafterprint| fire if I try to
print a selection? For instance, there's the disturbing idea of a script
triggered by |onbeforeprint| inserting adds into the selection if you
try to select and print only the part of a page without adds.

Received on Monday, 9 April 2007 03:03:43 UTC