HTML 5 - I wish they'd rethink printers.

[Michael Morris]

I wish they'd rethink how printers work. Sometimes you have to make a hard copy, but browsers and printing is a pain. Random thoughts of an idiot.

HTML

• PN element: Displays a page number. Has class and id attributes, but also has an "of" attribute that takes the id of another element as an argument (just as label's for attribute does) and causes the PN tag to give the page number of the element specified. There is no closing tag of PN, and it is an inline element.
• PT: Displays the total pages of the document.
• PAGEHEAD The header of printouts. By default it is position fixed top 0, left 0 (see CSS below) and only displays in the print media, being display: none; in screen media.
• PAGEFOOT As above, but the footer.

CSS
Implemenation of CSS 2's 5 print attributes would be a GREAT start!! These attributes are in addition

• :nth-page, first-page, last-page These psuedo-selectors works on pages the way nth-child works.
• position: pagefixed An element that is pagefixed appears on all pages.
• background: If called out within the context of media: print the background will be printed. An unspecified media background or a screen background will continue to not be printed.
• background-grayscale: A substitute for grayscale printing. So background-grayscale-color: #ee will set the background to 999 on a black & white printout. Unlike other color arguments, graysacle only accepts one or two hex numbers as giving it a full 24-bit hex argument is non-sensical.
• grayscale: Again, a substitute for grayscale printing, this time replacing the color attribute if the printer is set to print in black & white.

Anything else that could be done to make HTML / CSS printing less of a chore?

[xhtmlcoder]

You have to remember the web is not Print. Printer does not necessarily mean a powerful processor with all the trimming; buffering and printer-specific drivers like you would buy in your local computer shop for home use.

The print layout should be jointly controlled by both the user-agent and CSS not markup.

[Michael Morris]

Well, at the moment, it's controlled so badly I'd rather use postscript. Indeed, I have on my last two jobs despite needing separate templates for the print views (course the last two jobs the server was on a corporate intranet and so hooking it straight to the printer with cups and bypassing the browser was trivial).

Also, the web isn't video games either, but HTML 5 seems to be marching down that lane.

[Stevie D]

I don't see any need for the <pn> and <pt> elements - most browsers will print "Page x of y" on every page by default, or at least can be configured to do so if that's what people want. Likewise, they usually print the <title> and URL in the header/footer.

I can certainly see merit of having :first-page, :last-page, :odd-page and :even-page properties. I'm less convinced by the need for position:pagefixed, but I can imagine situations when it would be useful. The background properties I am not so keen on - I don't want to give authors the option to waste my printer ink, whether they think it is a good idea or not.

Poes - I don't think there's any harm in extending the CSS capabilities for print. Sure, a lot of printing is done on home printers on low-tech equipment, but these features would all be dealt with by the browser before sending the file to the printer.

[Michael Morris]

I don't see any need for the <pn> and <pt> elements - most browsers will print "Page x of y" on every page by default, or at least can be configured to do so if that's what people want. Likewise, they usually print the <title> and URL in the header/footer.

<sarcasm>Yes, I really want the title of the document to be printed out on the receipt printer, along with the URL of document and the page numbering. I thoroughly enjoy seeing professional receipt layouts ruined by the browser's default headers and footers that get pasted to EVERYTHING.</sarcasm>.

Sarcasm aside, what if I don't want Page X of Y, I just want Page X?? What if I want to use Roman numerals? Or even better, since html 5 has the section tag, what if I want the page numbering to restart with each section? Why should print layouts be shackled to browser defaults? They shouldn't.

But can you suggest another way to deal with page numbers?

I can certainly see merit of having :first-page, :last-page, dd-page and :even-page properties. I'm less convinced by the need for positionagefixed, but I can imagine situations when it would be useful.

pagefixed is primarily for those pagination headers and footers, or potentially for a watermark. It allows them to be styled as wanted.

The background properties I am not so keen on - I don't want to give authors the option to waste my printer ink, whether they think it is a good idea or not.

Your personal preferences on ink use aside, it's a major PITA when designing an application that needs to print reports where striping the tables with #eee would be a GREAT help on appearance, just to name one. I can see understand disabling background printing with screen media - this behavior predates CSS, but if a print stylesheet was prepared than presumably that was taken into account in the design.

So if a printer stylesheet has been prepared it should be used. If you don't like the ink usage then prepare a user stylesheet to override or copy & paste to word. I could live with browsers turning background printing off as an option per page, but for print stylesheets it shouldn't be the default.

[Stevie D]

<sarcasm>Yes, I really want the title of the document to be printed out on the receipt printer, along with the URL of document and the page numbering. I thoroughly enjoy seeing professional receipt layouts ruined by the browser's default headers and footers that get pasted to EVERYTHING.</sarcasm>.

Sarcasm aside, what if I don't want Page X of Y, I just want Page X?? What if I want to use Roman numerals? Or even better, since html 5 has the section tag, what if I want the page numbering to restart with each section? Why should print layouts be shackled to browser defaults? They shouldn't.

If you're that precious about having a perfect print layout, set up a PDF version of each page where you can have that level of control.

Your personal preferences on ink use aside, it's a major PITA when designing an application that needs to print reports where striping the tables with #eee would be a GREAT help on appearance, just to name one.

No, no good. You can set a border on relevant <tr>s to give a horizontal rule between alternate lines, which is fine for making it easier to read the table. That is nowhere near a good enough excuse for giving designers free rein to abuse my printer ink. There's a very good reason why browsers don't print backgrounds by default, and that's the way it should be.

And "my personal preferences on ink use" ... it's my ink and I'll decide whether I want to use it. I'm the one who's looking at the website, I'm the one who wants to print it, if you think your precious design is more important than my ink, you can pay for it. And while you're at it, you can buy me a better printer, because the one I've got - which is perfectly good enough for what I want it for - doesn't print text on background shading clearly. If I want to print background colours and shading then I can enable that option in my browser. You do not have the right to dictate to me how I use my browser or my printer.

[Michael Morris]

You do not have the right to dictate to me how I use my browser or my printer.

You don't have to print a page off one of my sites either

Seriously though, PDF is fine for what it is, but ever try to distill HTML into PDF? It's not much better than delegating the printing entirely to the printer. More often than not I've ended up having to build two sets of templates for the same view which is inefficient.

PS - being adverse to backgrounds on HTML then suggesting PDF as an alternative to preserve backgrounds is a rather pathetic rejoinder. It's not like a PDF with an image background is going to magically take less in than HTML printing the same image in an img tag. I mean, you make a huge deal out of a designer having control of a documents appearance and that control being a violation of your rights or something, then you turn around and suggest a format which does exactly what you demonize...

I'm still sitting here thinking, "what the Hell??"

[noonnope]

that's why pdf and xml make a good choice. or why rtf and xml make a good choice. or odf and xml. usually something with xml.

when it comes to printing, i agree that css should provide a little more. but not html. xml. maybe it's the same thing?

a web page should not be used for printing. a web page is an interface. you don't "print screen" on classic desktop interfaces, you design a report.

that's why xml is good to me. you could have a template in any of the pdf, rtf, odf, doc etcetera and then merge the template with xml data.

or css/xls should provide decent control on how to target printing formatting and features for xml data.

(css style for) printing html is a "quicky". it doesn't have to be complex or rigorous. for serious printing you need serious reporting.

[Stomme poes]

Poes - I don't think there's any harm in extending the CSS capabilities for print. Sure, a lot of printing is done on home printers on low-tech equipment, but these features would all be dealt with by the browser before sending the file to the printer.

I wasn't here, I swear! : )

[xhtmlcoder]

Off Topic:

Maybe his scrying ability is a little off but predicted the cat would appear due to the title having 5 in it.

Some say that Odin himself created this ancient crystal ball, although others argue that Loki created it and forged Odin's signature on the bottom. In any case, it is a powerful artifact.

Though still it's not the job of HTML markup although you could place a LINK and rel to an alternative media document.

[Michael Morris]

Who are you to decide what html's job is and is not?

I'm not asking for perfect printouts - just adequate ones. We don't really have even that now. Switching to PDF isn't a good answer - it requires maintaining separate view files for that mode of output, which is a pain.

[xhtmlcoder]

Markup should describe a document's structure and other attributes, rather than specify the processing to be performed on it.

[Michael Morris]

Markup should describe a document's structure and other attributes, rather than specify the processing to be performed on it.

Ok, let us reform HTML to religiously follow your example. No more script tags. No more onThis attributes (Actually, I'd like that). No more link tags - they aren't about the document's structure or attributes, they're about it's relation to other documents and that stuff should be in the header. I can go on.

Point is, HTML already disobeys this rule of yours. Even if this were not the case, the PN and PT tags are expressions of the document's structure. On screen they are both simply set to 1. You do have an argument based on this against pageheader and pagefooter, but the semantic meaning of these tags is no more or less valid than the incoming section, nav, aside and other tags for HTML 5. They are suggested to be ignored by the screen - that doesn't mean they have to be. And again, there are ALREADY tags in the spec that have special behavior in printing - Do a long table and put a thead element in, then watch as the thead is repeated on EVERY PAGE.

So no, you're wrong on this.

[xhtmlcoder]

To be honest I don't really follow the non-normative HTML5 stuff so cannot comment on their new tag "inventions" or redefinitions of already defined normative elements. So I am mainly approaching it from a HTML 4.01 perspective with regards to element names. So this is my last post in this thread as I have too little interest in HTML5 itself.

Scripts should only be linked within the HEAD but we have legacy... Obviously user agents must not evaluate script data as HTML markup but instead must pass it on as data to a script engine.

Regarding the TABLE:

User agents may exploit the head/body/foot division to support scrolling of body sections independently of the head and foot sections. When long tables are printed, the head and foot information may be repeated on each page that contains table data.

Though that is only a 'MAY' suggestion and to explicitly link those values to the TABLE itself not really printing as that's not dealt with by the markup.

The markup doesn't really have a concept of its media type it could as easily be a voice browser reading the TABLE markup.

Media types are about the only place that deals with printing with HTML 4.01, e.g. the LINK.

It is the same with OL LI the HTML doesn't generate the numbers either hence why things like the 'start' attribute got 'deprecated' for a very good reason.

If you really wanted those four elements why don't you write XML then as the tools are already available to include those elements in your documents?

The sentence above is a honest question; I aren't being sarcastic.

[Chroniclemaster1]

I don't want to give authors the option to waste my printer ink, whether they think it is a good idea or not.

Ditto!

Poes - I don't think there's any harm in extending the CSS capabilities for print. Sure, a lot of printing is done on home printers on low-tech equipment, but these features would all be dealt with by the browser before sending the file to the printer.

Hell, I would settle for the available CSS 2.1 printer settings to work right. The cross-browser incompatibilities in all media except screen are nothing short of appalling.

[Chroniclemaster1]

onThis attributes (Actually, I'd like that).

I would too. Part of the evolution of HTML 5 and it's supposed goal of "moving forward" should have been to eliminate support for idiotic patches like this which have now been irrevocably replaced (at least in best practices) with greatly superior techniques. Doing that would not have broken a single page on the internet because they're written in HTML 4 (or 3.2). I understand they wanted to get into video with 5, but all things considered I find HTML 5 to be a pretty huge disappointment.

[zcorpan]

Doing that would not have broken a single page on the internet because they're written in HTML 4 (or 3.2).

That does not matter one bit. Browsers that implement HTML5 affect pages written in HTML4 (or 3.2) because they only have one implementation to deal with all pages, not one implementation per HTML version. This is why it is important for HTML5 to be backwards compatible.

[Chroniclemaster1]

That does not matter one bit. Browsers that implement HTML5 affect pages written in HTML4 (or 3.2) because they only have one implementation to deal with all pages, not one implementation per HTML version. This is why it is important for HTML5 to be backwards compatible.

Wow, I had no idea. I thought that was the entire point of the DOCTYPEs was to provide compartmentalization, but obviously not. So HTML is not capable of a hard version, only soft versioning like 5. You can't EVER have a major revision of HTML.

So what do you think will come after it? If HTML 10 would still have to support everything in previous versions (including 1.0, 3.2, etc.) then it's not a viable long term structural language. Something will have to replace it.

[gary.turner]

It's not really necessary that the html version support obsolete elements/attributes; only that the browser does. It is necessary, if backward compatibility is desired, that the new not contradict the old.

cheers,

gary

[zcorpan]

Wow, I had no idea. I thought that was the entire point of the DOCTYPEs was to provide compartmentalization, but obviously not. So HTML is not capable of a hard version, only soft versioning like 5. You can't EVER have a major revision of HTML.

Well, technically we could, but we don't want to, since it makes implementations a lot more complex and it's not needed.

So what do you think will come after it? If HTML 10 would still have to support everything in previous versions (including 1.0, 3.2, etc.) then it's not a viable long term structural language. Something will have to replace it.

It has worked fine so far.

It's not really necessary that the html version support obsolete elements/attributes; only that the browser does. It is necessary, if backward compatibility is desired, that the new not contradict the old.

That's not how HTML5 does it though -- it specifies everything that needs to be implemented, including obsolete stuff.

[Stomme poes]

it specifies everything that needs to be implemented, including obsolete stuff.

Is this for the Everyone Renders Errors the Same Way thing? On the one hand I like identical error rendering... yet on the other hand, everyone doing it differently has helped me convince people to validate their code so many times...

Would be cool if modern browsers ignored obsolete things, but came with a "Garbage" button (could even have a cute little trash can or bag as the icon, complete with wavy stink lines!) users can click to see if the page shows up as expected once they "allow garbage". Lawlz.

[zcorpan]

Is this for the Everyone Renders Errors the Same Way thing?

Yeah.

As for motivation for validation, see http://www.whatwg.org/specs/web-apps...ts-for-authors

[Stomme poes]

The choir is already motivated. Stuff breaking in one browser your clients use but working in another browser your clients use— that motivates everyone else : )