subject:"Re\: \[Whatwg\] Request for HTML\-only print link"


Sander schreef:


Sander Tekelenburg schreef:

A lot of site owners just don't want to do that as it turns the focus on
the browser instead of their.



Well, tough :) Users matter more than authors. (See
.)
So when what authors want to do harms users, it is not a good idea to have
HTML cater for those authors.
  
But a lot of users just don't know their browser and they just don't 
really bother to learn. They want things the easiest way, which in 
this case would be that "print" does print when you click on it.
I agree that it would be best if users knew how to use their 
applications to the full extend, but that's just not reality for a 
large part of users. Perhaps you have geek parents. I don't and I know 
a lot of people like them who don't even know what a browser is 
although they use them every now and then or even quite regularly.


They don't have to know it is a browser. All major browsers follow 
certain interface conventions, one of them being that the print dialog 
is located under "File". The "average computer user" you are talking 
about, with little knowledge about browsers and the like, will probably 
assume that this program (the browser) also follows the convention and 
look for the print option where they expect it to be - "File", the place 
where it also is in their e-mail program, word processor, MS Paint, 
whatever. If the browser does not follow these conventions, then the 
average computer user is probably not using it. That a control is, in 
certain browsers, hidden in a menu somewhere is not a valid reason to 
make it directly accessible from HTML.


The browser's user interface however is not relevant at all here. For 
all you know your site is being viewed via a chromeless window - how is 
the user going to navigate forwards and backwards then? There are no 
buttons for those actions either. Just because not all user agents have 
the same functionality or interface features does not mean that HTML 
should make up for that. On the contrary - somehow enabling HTML to 
control printing would imply that a conforming UA is expected to support 
this, while it should be completely irrelevant whether the UA supports 
printing or not.


Anyway, as Anne pointed out earlier, the functionality you originally 
requested is already somewhat implemented.  would 
indicate to the UA that the document pointed to was meant for printing; 
this should be enough already. I can imagine an UA handling a link for 
media="print" would somehow indicate this to the user. I would agree 
that this could perhaps be defined more clearly in the spec. However 
having an attribute or technique specifically designed for printing out 
something is in my opinion, for the reasons I stated above and those 
which were mentioned by others, outside the scope of HTML and undesirable.


Regards,

Stijn

Re: [Whatwg] Request for HTML-only print link

Sander Tekelenburg schreef:

So if you'd really want to help those people, you would not
provide a print link. You'd let them figure out how to print, or you could
add a help page that explains how to print a web page (making sure that
you're clear about which specific browsing environment you''re talking
about).

A lot of site owners just don't want to do that as it turns the focus on
the browser instead of their.

Well, tough :) Users matter more than authors. (See
.)
So when what authors want to do harms users, it is not a good idea to have
HTML cater for those authors.

But a lot of users just don't know their browser and they just don't
really bother to learn. They want things the easiest way, which in this
case would be that "print" does print when you click on it.
I agree that it would be best if users knew how to use their
applications to the full extend, but that's just not reality for a large
part of users. Perhaps you have geek parents. I don't and I know a lot
of people like them who don't even know what a browser is although they
use them every now and then or even quite regularly.

Providing a print link on the spot where you
refer to printing doesn't force the visitor to think (which seems to be the
credo in usability land).

Actually, it does force users to think because they now have to determine the
difference between that particular print link and their UA's built-in print
function.

That may be the case for those who have visited this site of yours
(sorry ;-) ). I'm sure most won't even consider that there may be a
difference. And if there is a difference that should be made clear.

You're right. It was indeed a quick example. What I meant to say was that
providing a link that offers what you're talking about is better than 'just'
talking about it.

Understood. I'm not sure I see how the comparison makes sense though. Are you
thinking of something like "We suggest you print this purchase confirmation"?
Because I'd disagree. You can compare that with "we suggest you listen to this exerpt of John Doe's speech." Note that it makes
no sense to mark that up as "we suggest you listen to
this exerpt of John Doe's speech." Similarly ""We suggest you print this purchase confirmation" wouldn't make sense.
(Something like this could make sense however: "We suggest you print this purchase confirmation", if it points to a document that
contains the purchase confirmation.)

What about "We suggest you print this purchase
confirmation" then?

There are some differences with your mp3 example compared to a print link:
The mp3-link always refers to a different file, whereas a print link
(mostly) refers to the current file. So, sticking to the given example,
you're probably already on the page with the purchase confirmation. And
linking to the page itself has no use in this case.
More important, the mp3-file has a different extension that can trigger
a media player to play the file or the browser downloading it. For print
there's no such thing. If there was, that should probably be enough.

cheers,
Sander

Re: [Whatwg] Request for HTML-only print link

2007-07-28 Thread Sander Tekelenburg

At 23:02 +0200 UTC, on 2007-07-28, Sander wrote:

> Sander Tekelenburg schreef:
>
>> Your main argument for a print links seemed to be that some people might not
>> know where to find their UA's print command (hard to believe -- even IE by
>> default presents a shiny print button always).
>>
> Well, Opera doesn't show a print button for instance.

That only tells you that Opera is aimed at users who wouldn't appreciate an
explicit print button. For users who "need" such  a button *and* cannot
figure out how to add that to Opera, Opera may not be the best choice of UA.
Not a problem. People have other UAs to choose from.

Equally so, for users who have no print needs, or for whom file->print, or
the keyboard equivalent, is already second nature, having valuable screen
space wasted on a print button would not be useful.

All Opera's lack of by default showing a print button tells us is that
different users have different neeeds/preferences. It confirms that there is
no single "right" UI or document presentation for all users.

>>  Giving them a "print link"
>> doesn't help them, because now they still don't know where their UA's print
>> command is.
>>
> That's not the point as it is not up to the author of a website to educate
>their visitors about their browser.

Exactly ;) It's up to users to learn to use their tools. (And good tools are
as much self-explanatory as possible. At the very least it is the user's
responsibility to pick the tool that is easiest to (learn to) use.)

[...]

>>  So if you'd really want to help those people, you would not
>> provide a print link. You'd let them figure out how to print, or you could
>> add a help page that explains how to print a web page (making sure that
>> you're clear about which specific browsing environment you''re talking
>>about).
>
> A lot of site owners just don't want to do that as it turns the focus on
>the browser instead of their.

Well, tough :) Users matter more than authors. (See
.)
So when what authors want to do harms users, it is not a good idea to have
HTML cater for those authors.

> Providing a print link on the spot where you
>refer to printing doesn't force the visitor to think (which seems to be the
>credo in usability land).

Actually, it does force users to think because they now have to determine the
difference between that particular print link and their UA's built-in print
function.

Look at  for example. Activating the UA's built-in print
function and activating the print link give different results (at least in
Firefox 2.0.0.5 under Mac OS x 10.4.9, printing to PDF). (Yes, I built that
site and yes I'm well aware of all that's wrong with it -- blame me for not
managing to convince the customer.)

>>> Compare it to the sentence "You can find our address on the contact page".
[...]
> You're right. It was indeed a quick example. What I meant to say was that
>providing a link that offers what you're talking about is better than 'just'
>talking about it.

Understood. I'm not sure I see how the comparison makes sense though. Are you
thinking of something like "We suggest you print this purchase confirmation"?
Because I'd disagree. You can compare that with "we suggest you listen to this exerpt of John Doe's speech." Note that it makes
no sense to mark that up as "we suggest you listen to
this exerpt of John Doe's speech." Similarly ""We suggest you print this purchase confirmation" wouldn't make sense.
(Something like this could make sense however: "We suggest you print this purchase confirmation", if it points to a document that
contains the purchase confirmation.)

[... differences between browsing environments]

>> So what? If every browsing environment would work and present the same,
>> there'd be no need for more than one browsing environment. [...]
>
> What I meant was that people are not always on the same environment.

Understod, but web publishers simply aren't in the position to help users
with that. Any attempt at that can only result in creating more problems. A
good example is suggesting font-size to be 90%, because it helps some users
who [A] use IE with its too large default font-size and [B] haven't bothered
to learn how to change that default font-size to something that serves their
needs.  All the web publisher will achieve is make things harder for every
other user. As web publishers our first responsibility is to know where our
domain starts and where it ends.

-- 
Sander Tekelenburg
The Web Repair Initiative:

Re: [Whatwg] Request for HTML-only print link

You need not configure the printer from the HTML if you do not want to; I
only wanted to show what is ultimately possible.  I think it could make
sense on corporate intranet.  You can strip my example to what you consider
essential if you like, but once we agree upon such a feature, it seems
unwise to forbid such constructs.

In short, your idea was not that wide, but this is its natural scope.  If
this scope is too wide for you, you should reconsider whether your initial
proposition is appropriate at all.

Cheers

Chris

 

-Original Message-
From: Sander [mailto:[EMAIL PROTECTED] 
Sent: Saturday, July 28, 2007 11:22 PM
To: Křištof Želechovski; [EMAIL PROTECTED]
Subject: Re: [Whatwg] Request for HTML-only print link

 


Křištof Želechovski schreef: 

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 

http://www.whatwg.org/specs/web-apps/current-work/
<http://www.whatwg.org/specs/web-apps/current-work/&quo;&;> &quo;&

palette=mono&

copies=3&

mode=draft,booklet&

stapled=top" method="post" >?
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 was not to dictate from HTML how the printer should behave (number
of copies, color, etc.). This should be up to the visitor, who can manage
that in the print prompt. The request was about an alternative to
javascript:print() where there would be no need for client-side scripting.
I probably gave this discussion a wrong turn by saying that a
print-pseudo-protocol would perhaps be a good solution. I guess i should not
have done so as my knowledge about such things is minimal.

Re: [Whatwg] Request for HTML-only print link


Sander schreef:


Sander Tekelenburg schreef:

Your main argument for a print links seemed to be that some people might not
know where to find their UA's print command (hard to believe -- even IE by
default presents a shiny print button always).

Well, Opera doesn't show a print button for instance.

It does however have a "File -> Print" option, which is the place where 
this option is in virtually all programs offering printing 
functionality, and therefore most probably the first place someone will 
look.


Regards,

Stijn

Re: [Whatwg] Request for HTML-only print link



Křištof Želechovski schreef:


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

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

palette=mono&

copies=3&

mode=draft,booklet&

stapled=top" method="post" >?  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 was not to dictate from HTML how the printer should behave 
(number of copies, color, etc.). This should be up to the visitor, who 
can manage that in the print prompt. The request was about an 
alternative to javascript:print() where there would be no need for 
client-side scripting.
I probably gave this discussion a wrong turn by saying that a 
print-pseudo-protocol would perhaps be a good solution. I guess i should 
not have done so as my knowledge about such things is minimal.


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 wasn't talking about an anchor, but about an id, which can be any kind 
of element, with any kind of content. This is how bookmarks work 
nowadays and it is quite similar to CSS id-selectors. As this "fragment 
printing" would be new I don't see any backwards compatibility issues.


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.


It would be the same as it is now. Even with unobtrusive JavaScript I 
can not check whether a printer is installed and connected.


cheers,
Sander

Re: [Whatwg] Request for HTML-only print link

Sander Tekelenburg schreef:

Your main argument for a print links seemed to be that some people might not
know where to find their UA's print command (hard to believe -- even IE by
default presents a shiny print button always).

Well, Opera doesn't show a print button for instance.

Giving them a "print link"
doesn't help them, because now they still don't know where their UA's print
command is.
That's not the point as it is not up to the author of a website to
educate their visitors about their browser. I agree that it is best if
people knew the applications they're using but that's just not always
the case.

A lot of site owners just don't want to do that as it turns the focus on
the browser instead of their. Providing a print link on the spot where
you refer to printing doesn't force the visitor to think (which seems to
be the credo in usability land).

Compare it to the sentence "You can find our address on the contact page".

>From a usability point of view it is advisable to make "contact page" a link

Actually, no, that would be close to "click here". "You can find our address on the contact
page" would be the more usable markup. (Or alternatively, the entire sentence
can be the link.) (Btw, this in turn shows that the sentence was not written
for the Web. I understand that this was just a quick example. But it's the
sort of text that makes sense in print, but not on the Web. Unfortunately
many authors still throw text that was written for print on the Web.)

You're right. It was indeed a quick example. What I meant to say was
that providing a link that offers what you're talking about is better
than 'just' talking about it. Especially because it is the web we're
talking about. Compare it with these annoying URLs and email addresses
that are not actual links.

So what? If every browsing environment would work and present the same,
there'd be no need for more than one browsing environment. The very fact that
different people have different needs and preferences is why we have
different UAs, why we have separation of content and presentation and why
different UAs work differently. It is what makes the Web work.

The only thing that's important, if you're talking about usability, is that
things work the same for a given user across sites. And per definition, only
UAs can provide that experience.

What I meant was that people are not always on the same environment.

cheers,
Sander

Re: [Whatwg] Request for HTML-only print link

Of course, both the host name and the printer name can be empty, which means
the browser should let the user select the printer taking into account the
capabilities required and the local policies.  The browser can give the user
a hint about the best matches.
Cheers
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stijn Peeters
Sent: Saturday, July 28, 2007 9:54 PM
To: Křištof Želechovski
Cc: WHATWG
Subject: Re: [Whatwg] Request for HTML-only print link

Křištof Želechovski schreef:
>
> 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
>
> 
> action="print://host_name/printer_name/?
>
> href=&quo;http://www.whatwg.org/specs/web-apps/current-work/&quo;&;
>
> palette=mono&
>
> copies=3&
>
> mode=draft,booklet&
>
> stapled=top" method="post" >? 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
>
A link of the format print://host_name/printer_name would never be 
feasible because on the server side it can not be properly guessed what 
the name of the printer and the server it is on (if any) on the client 
side would be. A theoretical solution would be somehow finding the 
printer's location via Javascript (though this is fundamentally 
impossible, as far as I know), in which case you could as well use 
javascript:print().

Besides, no such protocol exists, and defining it is as I pointed out 
earlier not in the scope of the specs the WHATWG is working on.

Regards,

Stijn

Re: [Whatwg] Request for HTML-only print link


Křištof Želechovski schreef:


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

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

palette=mono&

copies=3&

mode=draft,booklet&

stapled=top" method="post" >? 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

A link of the format print://host_name/printer_name would never be 
feasible because on the server side it can not be properly guessed what 
the name of the printer and the server it is on (if any) on the client 
side would be. A theoretical solution would be somehow finding the 
printer's location via Javascript (though this is fundamentally 
impossible, as far as I know), in which case you could as well use 
javascript:print().


Besides, no such protocol exists, and defining it is as I pointed out 
earlier not in the scope of the specs the WHATWG is working on.


Regards,

Stijn

Re: [Whatwg] Request for HTML-only print link

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 

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

palette=mono&

copies=3&

mode=draft,booklet&

stapled=top" method="post" >?
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:[EMAIL PROTECTED] 
Sent: Saturday, July 28, 2007 7:43 PM
To: Křištof Želechovski; [EMAIL PROTECTED]
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

Re: [Whatwg] Request for HTML-only print link

2007-07-28 Thread Sander Tekelenburg

At 20:02 +0200 UTC, on 2007-07-28, Sander wrote:

> Sander Tekelenburg schreef:
>
>> At 07:12 +0200 UTC, on 2007-07-28, Sander wrote:

[...]

>> incosistency makes things harder to use. A print method that works the same
>> across web sites is much more usable.
>
> I don't think it's confusing as the browser's own print button is still
>there. So, people who prefer to use that one still can.

Your main argument for a print links seemed to be that some people might not
know where to find their UA's print command (hard to believe -- even IE by
default presents a shiny print button always). Giving them a "print link"
doesn't help them, because now they still don't know where their UA's print
command is. So if you'd really want to help those people, you would not
provide a print link. You'd let them figure out how to print, or you could
add a help page that explains how to print a web page (making sure that
you're clear about which specific browsing environment you''re talking about).

Btw, compare with authors providing a "back" link. I thought there's pretty
widespread consensus by now that that's a bad idea. I don't see how a print
link is any different.

[...]

> Compare it to the sentence "You can find our address on the contact page".
>From a usability point of view it is advisable to make "contact page" a link

Actually, no, that would be close to "click here". "You can find our address on the contact
page" would be the more usable markup. (Or alternatively, the entire sentence
can be the link.) (Btw, this in turn shows that the sentence was not written
for the Web. I understand that this was just a quick example. But it's the
sort of text that makes sense in print, but not on the Web. Unfortunately
many authors still throw text that was written for print on the Web.)

[...]

> But if you leave it all up to the UA, then it's not all the same for all
>users, in all cases.

So what? If every browsing environment would work and present the same,
there'd be no need for more than one browsing environment. The very fact that
different people have different needs and preferences is why we have
different UAs, why we have separation of content and presentation and why
different UAs work differently. It is what makes the Web work.

The only thing that's important, if you're talking about usability, is that
things work the same for a given user  across sites. And per definition, only
UAs can provide that experience.

-- 
Sander Tekelenburg
The Web Repair Initiative:

Re: [Whatwg] Request for HTML-only print link


Sander schreef:


Stijn Peeters schreef:

Sander schreef:

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?
I think new URI schemes are outside the scope of the WHATWG work. See 
also http://rfc.net/std0066.html#s3.1. and http://rfc.net/rfc2718.html


My initial request was not about a specific technique, but about a 
functionality. If a pseudo-protocol is not an option, maybe there's 
another solution.


cheers,
Sander
Certainly, just wanted to point out that in the case you'd consider a 
URI scheme the best option, this was not the appropriate place to 
discuss it further.


As for the request itself, I think I agree with Lachlan: I do not see a 
real reason to implement something that is already perfectly covered by 
javascript:print(). It is indeed basic funtionality of most browsers but 
I think this is also a reason _not_ to implement a specific attribute or 
element for this, as it would be redundant. Javascript has traditionally 
been used as a means of accessing the browser's functionality (back, 
forward, refresh, input prompts, confirmation dialogs...) and printing 
fits well in there.


Regards,

Stijn

Re: [Whatwg] Request for HTML-only print link

2007-07-28 Thread Kornel Lesinski


On Sat, 28 Jul 2007 19:02:46 +0100, Sander <[EMAIL PROTECTED]> wrote:


I don't see how that is good usability. Quite the contrary, because this
approach means things work different on each website. That's confusing;
incosistency makes things harder to use. A print method that works the  
same across web sites is much more usable.


I don't think it's confusing as the browser's own print button is still  
there.


If page provides it's own print button, user won't be sure if there was a  
real technical reason for doing this (and browser's print button won't  
work properly) or if just author felt it's nice having more buttons on his  
page.


"A man with a watch knows what time it is. A man with two watches is never  
sure."


--
regards, Kornel Lesiński

Re: [Whatwg] Request for HTML-only print link



Stijn Peeters schreef:

Sander schreef:

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?
I think new URI schemes are outside the scope of the WHATWG work. See 
also http://rfc.net/std0066.html#s3.1. and http://rfc.net/rfc2718.html


My initial request was not about a specific technique, but about a 
functionality. If a pseudo-protocol is not an option, maybe there's 
another solution.


cheers,
Sander

Re: [Whatwg] Request for HTML-only print link


Sander schreef:

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?
I think new URI schemes are outside the scope of the WHATWG work. See 
also http://rfc.net/std0066.html#s3.1. and http://rfc.net/rfc2718.html


Regards,

Stijn

Re: [Whatwg] Request for HTML-only print link



Sander Tekelenburg schreef:

At 07:12 +0200 UTC, on 2007-07-28, Sander wrote:
  

Well, it can be usefull from a usability point of view to offer this
function from within the web page, for instance: "you may want to print
this confirmation", where print is a link that actually prints the page.



I don't see how that is good usability. Quite the contrary, because this
approach means things work different on each website. That's confusing;
incosistency makes things harder to use. A print method that works the same
across web sites is much more usable.
  
I don't think it's confusing as the browser's own print button is still 
there. So, people who prefer to use that one still can. For those who 
are not so familiar with the interface of the browser it can be much 
easier having the word "print" being an actual print link.
Compare it to the sentence "You can find our address on the contact 
page". From a usability point of view it is advisable to make "contact 
page" a link to that page instead of having people to look where they 
can find that page.



Well, they'll just have to learn. AFAIK on most OSs the print command/button
is/looks the same in every app. So all they need to learn is that. Having to
learn how to print on each differen web site is much more likely to fail.
  
Again, a print link does not disable the default print function of the 
browser. It's an extra that can make it easier for the user.



Btw, consider the surprise of all those users clicking the link without
realising that it triggers their printer into wasting paper.
  
It's the responsibility of the author to make clear that it is a print 
link. Just as with mailto-links.
Then again, I believe there's always a print promt before the printing 
really starts (or there should be).



Or maybe
you want to offer people the option to print different parts of the page
seperately.



Yeah, that'd be useful. But it should be left up to the UA to provide users
with that. (As I understand it, iPhone's Safari more or less already does --
provided the document in question is well structured it allows users to
'grab' specific sections of a web page to interact with that section. Perhaps
it already does let users  print that selected section?)
  
But if you leave it all up to the UA, then it's not all the same for all 
users, in all cases.


cheers,
Sander

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

Re: [Whatwg] Request for HTML-only print link



Anne van Kesteren schreef:
I'd like to see an extension of the hyperlink to give it an HTML-only 
print function. Nowadays making a print link available from within a 
website

always involves client-side scripting. This dependency should not be
necessary for something like printing as it is basic functionality in 
most browsers (not sure about mobile devices though).


 * 
 * 
 * 

... cover this.
Does this do the same as javascript:print()? To me it looks like they 
provide a link to a document that is optimized for print, but does it 
also trigger the print function?


cheers,
Sander

Re: [Whatwg] Request for HTML-only print link

2007-07-28 Thread Lachlan Hunt


fantasai wrote:

Sander wrote:
I'd like to see an extension of the hyperlink to give it an HTML-only 
print function.


Websites shouldn't need to have a print link, they should provide a print
style sheet with . UAs 
should be automatically applying the print style sheet when printing.


Actually, the request seems to be for a declarative version of href="javascript:print();">, not a way to to provide an alternative 
printable format.


IMHO, I think the existing, widely used javascript solution is perfectly 
fine for those sites that want to use it, although I think that such 
links are completely redundant anyway.


--
Lachlan Hunt
http://lachy.id.au/

Re: [Whatwg] Request for HTML-only print link

2007-07-28 Thread Anne van Kesteren

I'd like to see an extension of the hyperlink to give it an HTML-only  
print function. Nowadays making a print link available from within a  
website

always involves client-side scripting. This dependency should not be
necessary for something like printing as it is basic functionality in  
most browsers (not sure about mobile devices though).


 * 
 * 
 * 

... cover this.


--
Anne van Kesteren

Re: [Whatwg] Request for HTML-only print link