Include a print styling for Seven.

I think it's entirely possible that someone may want to print an admin page but it's an extreme edge case. I'm not sure if it's worth the extra weight in CSS, the time, or the paper to get this looking good.

However, given this is how a printed page currently looks in Seven, I think this one line fix to hide the toolbar is a big gain at little cost.

I'd rather follow best practices here and include the print CSS in side of a media query instead of in a separate file, the browser downloads both on page load anyway. We're going to have to set the main stylesheet to media "all" instead of "screen"

tags

ok moved the print styling in to a media query and changed the style media from screen to all, to make the print media query work.

#4: drupal-print_stylesheet-2.patch queued for re-testing.

currently blocked by #2031317: Color upgrade path test is broken

4: drupal-print_stylesheet-2.patch queued for re-testing.

Reroll for simpletest.

OK, we have a new problem with the patch.
The testRebuildThemeData function throw the error. the test always want the 'screen' array instead of 'all'.

core/tests/Drupal/Tests/Core/Extension/ThemeHandlerTest.php, line 281.

Could we change this test?

Here is the new version. It"s use many things from hml5boilerplate css:
https://github.com/h5bp/html5-boilerplate/blob/master/css/main.css

I tested the patch #14 (after removing the whitespace on the line 88), and it seems to have some problems with the select lists that causes vertical lines. I haven't printed the pages but only taken screenshots of the preview before printing, so I'm not sure if the lines would really be printed or if it's just the preview.

I'm not sure if printing the path of each link is useful or somewhat confusing instead.

Thanks for testing.

I removed whitespace, and change 4space tabs to 2spaces.
Add fix for select box, and another form elements, to not show vertical lines across the print layout.
Tested more times the link with/without the href, and i removed it.
I tested print layout to print PDF files.
Added support to show dropbutton links.
Some fix on tabs navigation.
Added some code, like show background-images on dblog on chrome.

I am changing the status to review.

Add files, with do-not-test, see #13.
After we finish the print layout, then make a patch for the test.

Toolbar shows in print preview on FireFox/Ubuntu. It repeats at the top of every page in the preview. So if the prviews has page 1 of 4, 2 of 4, etc., the toolbar will be on every page.

Same effect whether the second line of the toolbar is showing or not. Not affected by which page is being previewed.

Remove the toolbar entirely from the print view?

Yeah we should

Here is the new one.

Re-rolled this patch for the latest d8-dev and added a declaration to hide the toolbar in print versions.

Since you are changing the .info.yml file to be reading the media as "all" then we should go ahead and straight forwardly change the test to match.

Here is the same patch rerolled with the test included, so renaming the patch so it will kick off a test run.

Reroll.

Testing

Patch can't be applied using "git apply". This is the message shown:

When applying it with the patch command, a file called layout.css.orig gets created.

Rerolled and applied patch successfully with no errors. Uploaded patch.

@criscom The patch needs review from one more person before we can RTBC

Reviewing

Reviewed and it worked. Tested in Safari, Firefox and Chrome on Mac

I think these got in accidently in the #29 reroll.

Adding #32 patch without "layout-column" related theming.

Yes, looks better. Okay with me.

I'm going to update the issue summary.

Updated the summary. Also been hiding some of the files. This issues still needs a review, manual testing and screenshots.

The buttons size, spacing and color contrast needs to be fixed.

I tested with the patch #40, and otherwise it seems ok but the operation options transformed in circles should be fixed. The first screenshot is from admin/structure/views, the second one from admin/structure/types/manage/article/fields.

On the views page, the button that is blue on the screen is white on my printed sheet (so there is no contrast problem), but on the field management page it is blue also on the printed sheet.

I tested with Firefox.

Updated patch, made screenshots about the fixes, remove duplicated format for #toolbar-administration.

It looks good for me with the patch #46.

Thanks, it would be good if we could move this into it's own print.css file for now, layout does not make sense.

I agree that layout.css doesn't seem to be the right place, but the description says

To accomplish this, we would use a media query (instead of a separate file, following the best practice from HTML5 Boilerplate).

If you prefer it to be in a separate file, I'm ok with that.

I create in this patch a separated print.css file. I'm not sure if I've done everything in the right way:

• Should the print.css file include the media query? (Here it does.)
• Should the print.css file be listed in the .info file in a separated 'print' section? (Here it is.)
• Should the ThemeHandlerTest.php be modified? (Here it isn't besides what was done in the previous patch.)
• I put the print.css file in core/themes/seven/css/base/. Does it make sense?

I added the new line in the end of print.css, fixed the .info file and added the print.css to the ThemeHandlerTest.php.

This patch fixes the style sheet declaration order in the .info file.

Wow, that's a nice improvement! Here's two screenshots of #85, one without and one with the patch applied.

Before:
After:

Looks good to me!

Looking good to me. Thanks

Otherwise, we could always include:

-- http://printstylesheet.com/

Rerolled, only context lines were changed. So, back to RTBC.

1. +++ b/core/themes/seven/css/base/print.css
@@ -0,0 +1,83 @@
+  .dropbutton-multiple .dropbutton .secondary-action {
+    display: block;
+  }
+  .js .dropbutton-widget,
+  .js td .dropbutton-widget /* Splitbuttons */ {
+    position: relative;
+  }
+  .js .dropbutton .dropbutton-toggle {
+    display: none;
+  }
+  .js .dropbutton-multiple .dropbutton-widget {
+    background: none;
+    border-radius: 4px;
+  }

   More special stuff for dropbuttons - this will break before release.

2. +++ b/core/themes/seven/css/base/print.css
@@ -0,0 +1,83 @@
+  input.form-autocomplete, input.form-text, input.form-tel, input.form-email, input.form-url, input.form-search, input.form-number, input.form-color, input.form-file, textarea.form-textarea, select.form-select {
+    -webkit-appearance: none;
+    border-width: 1px;
+  }

   Why is their a webkit only directive here?

3. +++ b/core/themes/seven/css/base/print.css
@@ -0,0 +1,83 @@
+  .admin-dblog .icon {
+    -webkit-print-color-adjust:exact;
+  }

   Are we sure we want to specifically target webkit browsers here?

More special stuff for dropbuttons - this will break before release.

Dropbuttons require special print styling because they have special styling. I don't see the problem here. It's a bit weird that js is running on a printed page but I guess a lot of sites these days would look broken without JS.

Why is their a webkit only directive here?

hmm, we don't set appearance in Seven's form.css. Is anyone able to explain the logic behind this?

Are we sure we want to specifically target webkit browsers here?

-webkit-print-color-adjust:exact; is a webkit only property that does not exist in other browsers. It's an explicit direction to print background images. In #2236855: Use CSS for file icons in file fields we decided that there is no need to print purely presentational icons. I think we can remove this line.

Rerolled the patch, removing the webkit only directive as suggested in #65.

See #65.

Right! :) Removed the additional webkit only rule.

Looks like Alex's issues have been address, here's an interdiff from 63-68 to confirm.

Here's a re-roll.

Hmm interdiff failed. But the only difference is from this:

to:

Yep looks like DRUPAL_ROOT has been changed to this->root. That's the only difference

To be honest this does not really feel like a feature - printing web pages is something people can do regardless of this patch so redefining as a task. Since this issue is now a normal task we need to outline how it fits within the allowable Drupal 8 beta criteria. Can someone add Drupal 8 beta phase evaluation template to the issue summary.

I have added the requested template. How do we make a decision on this now?

Now that we have the template I think we can move it back to RTBC.

Reroll after: #2377397: Themes should use libraries, not individual stylesheets

Fixing the reroll.

A quick manual test and all is well.

What is the point of having the media query in both places? According to the issue summary boilerplate suggests using a media query instead of a separate file. If we want this to be aggregated into Seven's global-styling css then I think we need to remove the media query from seven.libraries.yml

Fixed the issue from #83.

Update: Something went wrong. Check the next comment for the correct patch.

Something went wrong. Here's the patch and the interdiff.

@alexpott Nice catch :-) Yep this is what we want. It reduces the number of loaded CSS files by one.

Thanks Sander for the patch.

Committed 7aef0c7 and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation for to the issue summary.

We should be changing the modes of these files - fixed on commit.