10

Updated Question

So, I've found what's causing this issue. It is, in fact, open sans as suggested in this question. Now my question is, why is Chrome not loading the first time when using Open Sans?

Here's what I'm seeing. Open Sans is included directly in the project. Instead of the import statement like in the question above, we have a number of @font-face css rules such as this one:

@font-face {
    font-family:'Open Sans';
    font-style:normal;
    fontweight:300;
    src:url('../fonts/OpenSans-Light-webfont.eot');
    src:url('../fonts/OpenSans-Light-webfont.eot?#iefix')
    format('embedded-opentype'), url('../fonts/OpenSans-Light-webfont.woff')
    format('woff'), url('../fonts/OpenSans-Light-webfont.ttf')
    format('truetype'), url('../fonts/OpenSans-Light-webfont.svg#open_sanslight')    
    format('svg')
}

If I comment those out, the <h3> tags I use load fine. If I leave those in, they don't load the first time but do load every subsequent time. Has anyone else using Open Sans seen this issue? How did you fix it?

Original Question

I'm stumped on an issue with Google Chrome and printing. There are a few specific elements that are missing when opening print for the first time. Each time after that first time everything loads fine. It's like the CSS rules didn't quite finish processing before the print preview renders.

The page is using Bootstrap 3 along with some custom styles. The HTML for the element in question is as follows:

<h3 class="myHide">Some text</h3>

The screen/normal CSS is as follows:

.myHide { display: none !important; }

The print CSS is as follows:

.myHide { display: block !important; }

Unfortunately I cannot share the actual CSS and HTML, but the above is identical in function. The first time I hit print, every <h3> with that class doesn't show up but there is blank space where it should be. Every time I hit print after that it shows fine. I'm only seeing this issue in Chrome. FF and IE work fine every time no matter how I print.

I've tried a few things which were mainly small tweaks to the CSS. One thing I tried was switching from the custom class to show/hide stuff to the ones offered in Bootstrap, but the same behavior was observed. I've spent quite a while googling solutions, trialing different options, and talking with others about this, but haven't found a working solution yet which leads me here hoping someone out there has seen this.

Note: I've looked at a similar question but fonts aren't imported like that for this project so that solution won't work (unless it's an issue with Open Sans itself and not an issue with how it's imported into the project).

Update: The page does have some functions listening for the print event. Specifically, I use onbeforeprint and onafterprint for FF and IE and I use matchMedia for Chrome. I'm still looking into them, but it seems unreasonable that these would be delaying the processing for CSS styles and HTML elements on the first time but not subsequent times. However, I'll keep looking into it.

Community
  • 1
  • 1
jvdub
  • 891
  • 5
  • 19
  • Is there an element such as a div encasing your `h3` that you're hiding / displaying as well? – NotJay Oct 28 '15 at 20:12
  • It almost seems like maybe it is a rendering issue and the browser isn't drawing the element in time, have you tried adding a short delay? – Adjit Oct 28 '15 at 20:12
  • I just double checked the parent `div`'s and they are not shown/hidden at any time. I'll add a short delay on print and see if that helps. – jvdub Oct 28 '15 at 20:14
  • I also just came across this question, and it seems there were some issues with using JS to print (but that was 3 years ago, so it may no longer be relavant, however may also be an option to try) - http://stackoverflow.com/questions/10401454/javascript-print-blocked-by-chrome-workaround – Adjit Oct 28 '15 at 20:16
  • So, I tried adding a short delay and thought it worked, but it actually didn't (it was the second time I tried to print). – jvdub Oct 28 '15 at 20:19
  • @Adjit, thanks for finding that other question. After looking that that, I don't think it's quite what I need. I do have some functions that run, but they listen to the media changing... but maybe that's the issue. Chrome's print event listeners are different than FF and IE, so maybe the issue is in that function... I'll have a look there. – jvdub Oct 28 '15 at 20:25
  • What happens when you use chrome to emulate the print screen? This may let you debugg the issue http://stackoverflow.com/questions/9540990/using-chromes-element-inspector-in-print-preview-mode – Adjit Oct 28 '15 at 20:47
  • Looks like in FF the page's styles are rendered before the `matchMedia` runs while in Chrome the `matchMedia` function runs before the print styles are rendered. That still doesn't answer the question as to why most of the page renders fine but these specific `h3` elements don't. – jvdub Oct 28 '15 at 21:08

1 Answers1

4

Ended up just changing the styles used. Instead of using display: none I'm now using the following:

.my-hide {
  display: block !important;
  height: 0px;
  overflow: hidden;
}
@media print {
  .my-hide {
    height: auto;
  }
}

For some reason these CSS rules get processed in time while the others don't.

jvdub
  • 891
  • 5
  • 19