[Whatwg] Request for HTML-only print link

[Křištof Želechovski]

href="print://www.whatwg.org/specs/web-apps/current-work/" is no good; it
asks the browser to find the resource using the print protocol.  But the
print protocol is for printing, not for finding resources; I imagine it
could be used for finding out some printer configuration parameters (similar
to the way printers with a network interface only can be configured) and to
submit documents for printing, nothing more.

How about 

<form 

action="print://host_name/printer_name/?

href=&quo;http://www.whatwg.org/specs/web-apps/current-work/&quo;&amp;

palette=mono&amp;

copies=3&amp;

mode=draft,booklet&amp;

stapled=top" method="post" ><input type="submit" value="Print me"></form >?
It feels better to me.  Of course, the arguments would be interpreted by the
browser, not by the printer, contrary to what the syntax suggests, but I
think this problem is much smaller and I can swallow it in spite of being a
purist.

The idea that a fragment can address a block element is quite interesting;
in the old days a reference to #name would usually correspond to an anchor
with the same name-and you cannot embrace a block-level element with an
anchor.  I think it is still common practice to put the named anchor around
the section header and not around the whole section, which would require a
division, not an anchor.

I did not want to say that printing is obsolete; I wanted to say that asking
the customer to print is obsolete.  Sorry for the misunderstanding.  Your
site should not lose functionality because your customer does not have a
printer.

Cheers

Chris

 

-----Original Message-----
From: Sander [mailto:html5 at zoid.nl] 
Sent: Saturday, July 28, 2007 7:43 PM
To: Křištof Želechovski; whatwg at whatwg.org
Subject: Re: [Whatwg] Request for HTML-only print link

 

Křištof Želechovski schreef: 

The acronym URL expands to "Uniform Resource *Locator*".  The string
"print:#" does not match this spec: it is not a locator, it is a processing
instruction.  BTW, the full form of the local URL "#" can be viewed as
"html:#" (whether it is allowed by the URL standard or not) which means that
you need a URL to access the resource you want to print; prefixing it with
"print:" would result in a double URL scheme, which is unacceptable.
Therefore it is better to use a special target, if any.

Would href="print://www.whatwg.org/specs/web-apps/current-work/" have been
better then?




Moreover, as has already been noted, the http URL scheme does not allow
specifying document fragments except in CGI arguments, which is an
absolutely server-side unspecified thing.

Well, you can of course link to a specified id within a document
(http://www.whatwg.org/specs/web-apps/current-work/#media12). Isn't that a
fragment, as in CSS (#media12 { })?




And the details like paper sort, size, texture and stationery, print mode
and quality, the order of pages and many other things I do not know about,
if they are essential, still have to be explained verbally to the viewer, so
the gain is minimal.  And if you tell me such things are never essential, I
shall respond that printing is an obsolete practice that is harmful to the
environment and should be deprecated and not recommended, except for the
cases were a written signature is needed, which is hopefully becoming
obsolete as well.

These are essential for printing and should be handled the way it is handled
now: through a print prompt. In a mailto:-link you don't provide from which
address to send it from, HTML-mail, plain text or both either.

My request was for a way to have in-page print links that don't require
client-side scripting, an HTML-alternative to javascript:print();

I don't agree with you that printing is an obsolete practice. Not yet at
least, as people not all have mobile access to the internet or in cases like
the example you came up with yourself.

cheers,
Sander



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070728/8f0bf9cf/attachment.htm>