SitePoint Sponsor

User Tag List

Results 1 to 23 of 23
  1. #1
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,026
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)

    HTML 5 - I wish they'd rethink printers.

    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?

  2. #2
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #3
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,026
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    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.

  4. #4
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,888
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    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.

  5. #5
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,026
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stevie D View Post
    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.

  6. #6
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,888
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    <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.

  7. #7
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,026
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stevie D View Post
    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??"

  8. #8
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  9. #9
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    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! : )

  10. #10
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

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

    Quote Originally Posted by Crystal Ball
    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.

  11. #11
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,026
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    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.

  12. #12
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    Markup should describe a document's structure and other attributes, rather than specify the processing to be performed on it.

  13. #13
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,026
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by xhtmlcoder View Post
    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.

  14. #14
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    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:
    Quote Originally Posted by HTML 4.01, 11.1 Introduction to tables
    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.

  15. #15
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stevie D View Post
    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!

    Quote Originally Posted by Stevie D View Post
    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.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  16. #16
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    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.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  17. #17
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Chroniclemaster1 View Post
    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.
    Simon Pieters

  18. #18
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan View Post
    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.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  19. #19
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  20. #20
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Chroniclemaster1 View Post
    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.

    Quote Originally Posted by Chroniclemaster1 View Post
    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.

    Quote Originally Posted by 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.
    That's not how HTML5 does it though -- it specifies everything that needs to be implemented, including obsolete stuff.
    Simon Pieters

  21. #21
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    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.

  22. #22
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    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
    Simon Pieters

  23. #23
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    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 : )


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •