When printing long tables with Safari, the THEAD and TFOOT sections of a table are only printed on the first page. The THEAD & TFOOT section of a table should be printed on every page, like suggested by W3C: http://www.w3.org/TR/html401/struct/tables.html#h-11.2.3
To be clear. The above mentioned specification states: "When long tables are printed, the table head and foot information "may be" repeated on each page that contains table data." So it "may be" printed. Not "should be" printed. But to be consistent with other browsers like IE, Firefox that have this feature implemented I agree it should be implemented.
(In reply to comment #1) Would be nice to see it implemented. It really helps to read multi page reports and gives the opportunity to print only selected pages without losing the column titles.
Bump. This would be a really nice feature? Any thoughts or progress?
Nope :/ Safari and Opera still don't support this feature but Firefox and MS-Explorer do.
Yes, the specification says "may be" printed on every page, rather than "shall be" or "must be". This goes beyond consistency with other browsers. Without repeating table headers and footers, Webkit is unsuited for any line-of-business application which requires the printing of tabular content - which is to say virtually all such applications.
2 years later and still no solution on the horizon? Web based business applications become more and more important and Safari is just out of that area because of missing key features?
*** Bug 34218 has been marked as a duplicate of this bug. ***
Are there any plans to move this change request forward? It's been around some years now and it's really a major annoyance. At least to me. I've read somewhere that a potential fix is quite easy, while others state that only a major rewrite will do. Any hints into what direction this might go? Best regards, Raphael
The same problem, please do something about it. THX
A big lacking feature in Webkit, especially since it is used in Qt, and not added after 4 years. Can it become a priority ?
Lacking this feature prevents webkit from producing great printed results. Please add.
Adding my support for this, some wizard should give it a shot!
I would also like to see a fix for this. Is there any way that thead and tfoot can just be pulled into the header and footer area so that it repeats on each page? Is that viable at all? Or do the page dimensions need to be altered and moved around?
I want to confirm that this behavior is a MUST for LOB web applications because otherwise printing professional looking content from an otherwise incredibly powerful system is near impossible. I've never submitted patches to an open source project but I'm going to take a look because it would require FAR less work and money than the alternatives that my company faces to maintain IE support (most HTML to PDF components use WebKit).
Seriously, it's an important feature. Reported since 2008, come on!
I would also like to see this feature implemented. Printed media CSS support is rather lacking on webkit vs others, and with solutions such as wkhtmltopdf becoming more popular, this is becoming something of a necessity for some.
+1 for this - As a user of wkhtmltopdf this would be very useful for itemised invoice tables.
It should be implemented!!!
This issue is the 14th most voted issue in chromium, with 471 votes. It's sad that this works in IE and FF but not webkit; We have clients asking for this feature and all we can say is "use another browser just for this task", when we would normally tell them to use chrome. https://code.google.com/p/chromium/issues/detail?id=24826
Just a note that I'd like to vote for this issue - we'd like to generate a PDF printout from Safari with headers and footers, this is impeding us.
Chrome is really good to work ,but only for this we plan to use other browser. why chrome team making such delay to add this feature to chrome .
Any position fixed element should be printed in every page, like Firefox and Internet Explorer do.
(In reply to comment #22) > Any position fixed element should be printed in every page, like Firefox and Internet Explorer do. "... In the case of the print media type, the box is rendered on every page, and is fixed with respect to the page box, even if the page is seen through a viewport (in the case of a print-preview, for example). ..." http://www.w3.org/TR/CSS2/visuren.html#propdef-position
5 years later and still no solution . header and footer element should be printed in every page, like Firefox and Internet Explorer.
I also add my votes to this bug.
I also vote to fix this annoying issue please.
As we are highlighting the customers use only chrome as it is fast and user friendly.. on the big time feature which is not fixed for long time.. is really paining. Please fix as early as possible to command our customers to go ahead with Chrome as better browser.
Is there any progress on this bug? It seems that this is a pretty widely used function and it is a shame that Chrome and Safari do not support it correctly.
"Me too" Hello? Is there any marginally intelligent reason why the most powerful technology company in the world can't solve this rather important issue after over *SIX* years? P A T H E T I C
+1 seriously
I have a MUCH better idea. How about just implementing proper print support with CSS Paged Media Modules Level 3? http://www.w3.org/TR/css3-page/
please, solve this issue
What's taking so long ?! SERIOUSLY ! FEB 2008 TO AUGUST 2014 AND COUNTING 6.5 YEARS !! Just SAD.
+1 C'mon guys, even IE handles this properly!
+ 1, Our company needs this feature also.
I need this, even on IE it works.
Hi! Any workaround??? I really need this!!!
+1 this would be very helpful to have.
+1 we need a header block that repeats across pages. The THEAD (or css equivalent) that works in IE and mostly works in FF, is already part of the html 4 spec (and presumably inherited by html 5). It would be okay for other methods to work, as long as something does. For example: In FF I combine header {position:fixed} with an html {margin-top}, to avoid the problems with some odd/complex arrangements crashing it when using body{display:table} header{display:table-header-group} and having several actual/nested tables on the same page. In IE body{display:table} header{display:table-header-group} works correctly. This stable functionality would be a good target for WebKit. As, it already mostly works in Gecho, perhaps capping iterations or putting some other safeguard in place would make the code usable in WebKit (otherwise) as is. As, WebKit is forked from Gecho, copying code from Gecko should not be a huge undertaking. As the Gecko bug is for a limited set of circumstances, placing limits on execution should be sufficient for now - to prevent the Gecko bugs from emerging in WebKit.
(In reply to comment #39) Nitpick: WebKit is not forked from Gecko but stems from KHTML. > As, WebKit is forked from Gecho, copying code from Gecko should not be a > huge undertaking. As the Gecko bug is for a limited set of circumstances, > placing limits on execution should be sufficient for now - to prevent the > Gecko bugs from emerging in WebKit.
+1 I stand corrected. I still need the functionality though. If nothing else, can you at least make html {margin-top and/or padding-top} and header {position:fixed} repeat on each printed page. That would be good for a start. And handling {table-header-group} and/or thead/tfoot correctly would be ideal.
+1
+1 for adding this functionality.
+1 can anybody explain what is so difficoult about this?
+1 Please fix
+1 should be fixed
+1. This has dragged on for far too long.
The issue is still there to be worked on. C'mon.
Just stumbled across this. As seen on SO and just about everywhere, this issue puts to shame Chrome. ... 7 years and no update has been done with this? I mean, even a basic, half-broken implementation would be better than nothing. And since Chrome actually generates PDF when printing, I mean, come on! How hard can it be to just insert the <thead> container before adding new rows?
Wow, we recommend Chrome to all of our clients at work. But after not being able to include the header of my table in my print out on every page I am not sure that will be an option. Please fix this!
+1 The lack of this feature is making me seriously consider embedding Gecko despite the app being Qt and already having webkit embedded. It's vital for business and legal requirements and it shows that chrome, safari, et al. aren't suitable for certain business purposes.
+1 This is a very important feature. I cant recommend using webkit based browsers because of this issue.
+1 Really frustrating when you make a revolution in your company exalting Chrome, and after some good results, you end up in this.
Our customers are using Chrome, but this prevents important feature not to work as expected and we must suggest them to use FF or even IE before Chrome. I'd be interested to hear as well what's so hard about making the fix?
Any magic happening ???
Please fix!!!!!! Soon !!
so, 2016 and still no solution for this very old issues?
Still a issues as of 3/16/2016 Chrome version 49.xx
What a wonderful bug. Still 21/04/2016.
Fixed in Chrome (as long as you use `break-inside:avoid;`): https://bugs.chromium.org/p/chromium/issues/detail?id=24826#c45
*** Bug 143330 has been marked as a duplicate of this bug. ***
Now as this is fixed in Chrome I hope WebKit will catch up soon!
Please fix this bug. It is very useful. I hope it is fixed soon.. Chrome has fixed this bug. Please fix in webkit source. https://codereview.chromium.org/2021703002/#ps1
Is it fixable or not? Is anyone working around this?
Any update on this??
Is it real?? In 2016 No solution to this bug??
8 years .. still not fix ?
Is there anyone that read these bug comments and can explain why no one can start solve this? Is it so difficult??
Any update on including header and footer of a table in my print out on every page.
2008-02-07 So sad...
almost TEN YEARS isn't enough time to fix this bug?
+10. I created an account just for this
Who is responsible for this important bug?!
This is important!!
+1 More than 10 years and still no updates.
Wow. Should the developers take a look here?
splendid support ... nothing changed
As a note to everyone, this was fixed in Blink, so Webkit is the only engine that doesn't support this.
Is there any chance to fix this bug? It's a shame that only Safari does not support this functionality and it is a very useful one.
Just created an account just to make a comment on this thread. I Hope Safari will release an update for this issue. Guess it's more than 14 years now.
rdar://12254989
*** Bug 159052 has been marked as a duplicate of this bug. ***