- From: Stijn Peeters <stijn.p@hccnet.nl>
- Date: Sun, 29 Jul 2007 04:30:29 +0200
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 >> <http://esw.w3.org/topic/HTML/ProposedDesignPrinciples#head-97abe59da6732ca0ab8a6d9d863b100bf1e51266>.) >> 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. <a media="print"> 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
Received on Saturday, 28 July 2007 19:30:29 UTC