This problem IMO is more related to CSS but I am open to any solution. I am trying to print a webpage who's height is defined in px (I also tried %). Now What's happening in Safari and IE 8 and onwards, page contents will not print on one page.
Current Setup
div.parent-container{
height: 900px;
}
div.parent-container div.child-containers{
height:100%;
}
What's happening
It will print everything on one page in FF but in IE and Safari contents will split in to two pages which is heck of a problem for my users. I have to tell them to set page-margins: 0.3 which is definitely not an efficient way.
What I have done
I have tried different #page and browser specific hacks to make it work but it doesn't prove to be fruitful OR doesn't seem efficient to me( Never been a fan of customized browser hacks).
What I want
CSS/JS solution to make page contents print on one page may be something like 'Shrink to Fit'.
Thanks,
Rahi
Printing devices usually measure their content in physical dimmensions (in, cm, ft, etc). Pixel width is dependent on monitor resolution, and thus can't be relied upon for every output device.
If it's crucial your page prints the way you'd like it, you'll most likely need a CSS file designed for printing -- one that uses inches, centimeters, or whatever you'd like.
Check out this previous post -- I think it will help.
Related
I am having issues trying to load my site, http://www.internhacks.io/, on any mobile browser.
The project can be found here on Github.
I have tested the site on mobile using Chrome dev tools, and everything loads fine/acts responsively.
However, when testing the site on my actual phone, sometimes the site does not load at all, sometimes only partially.
Note: the apply button is not meant to do anything yet
I think it may have to do with having a large image as the background. Should I be serving a smaller version if detecting the window is smaller? The img height is set to 100vh.
If anyone knows what might be causing this, or knows of a better way to debug the site on mobile than in Chrome dev tools, please let me know!
I use Opera mini to test mobile devices (aka android) with various screen resolutions.
"height is set to 100vh" huh? never saw that one before. To fit graphics within space available, avoid fixed sizes (aka 100px) and I use relative width:xx%
YES, it's wasteful to send large graphics to a mobile device and from the server, you need to send some xxx-low-res.img instead
it's helpful to load JS scripts into a section to allow all objects to be loaded first.
I think your main issues is that the big images should use smaller, light-weight pictures instead since it'll speed up the resize process when rendering on the phone. Other than that, you want to stick away from, as #jobeard mentioned, from using fixed sizes like the 100vh and use a relative width such as 10%.
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
I have a simple table with css. When I add a bottom border to the middle row, the next row has a really weird border. it happens only in chrome, and I have no idea why.
I should say the I apply the bottom border to the middle row using javascript (because I don't know the size of the table beforehand). I tried to apply without javascript, and it works without the weird problem.
here is an example of the table, notice the borders in the middle:
http://ri-cloud.appspot.com/super_tacticko?create
here is the javascipt I'm using to create the middle line:
// add the middle line
var half = height / 2; // it has to be zugi anyway
var $middle = $('tr').slice(half-1, half);
$middle.find('td').addClass('middle-td');
If resizing the window fixes the issue (as it does in my case also) it is most likely a rendering bug... Chrome has a number of these that spring up from time to time, mainly because it tries to be faster than everything else by cutting corners (imo).
The only way to work around a bug is to keep trying different approaches until you find one that doesn't trigger the issue, either that or try programatically resizing your table/body after it's been created and then put it back to the right size again — this may force Chrome to redraw correctly... and should occur quickly enough that the users wont notice. A third approach could be to build the table entirely in JavaScript and once properly formed, embed it into the page.
The reason why the CSS method probably works is because it will be using Chrome's rendering methods at a different point in the rendering process to that of the JavaScript style modifications.
Basically, I have seen Chrome do some pretty strange things. The hacks I've used in the past to get around odd Chrome problems have been:
Use decimals in dimension calculations — i.e. 30.1px instead of 30px
Not setting opacity to full — i.e. 0.99 instead of 1.0
Not to use an ip address prefixed with a . when setting a cookie
Use overflow: hidden to repair strange renderings in certain situations.
Oh just for the record I'm viewing on Windows 7 via Chrome v25.0.1364.97
I have run into similar problems in Chrome on Windows 10. The cause of this problem is that Chrome is not working correctly with Windows text-size settings feature (IMHO changing DPI in Win OS). When I have switched from 125% text size to 100% text size, Chrome was rendering my HTML table correctly. As far as I have been testing, other browsers are working with this feature OK.
Finally I made a quick fix to this issue as follows:
table {
tr td {
border-color: transparent !important;
outline: 1px solid #666;
}
}
It is not bullet-proof, the sizes of borders are 2px, but better something than nothing.
The issue discussed in this question happened to me with a production site, but in addition to Firefox, we saw it in IE.
This is how it should look, with all three fading to different pictures intermittently:
We got these screenshots from clients:
Abmormally small images:
Weird sized images:
We were able to reproduce it reliably with Firefox with a hard refresh (ctrl-f5), but the only one in our office that could reproduce it in IE was running IE8 on Windows 7, and then not reliably. The client was using IE7, I believe on XP.
I fixed it by setting up the slideshow in $(window).load() instead of $(document).ready(), but I never figured out why it was so hard to reproduce in IE. Management is unsettled by the fact that we could not reliably reproduce it in IE or explain why it happened, and I've been asked to investigate.
Does anyone have an idea? Does the same issue discussed in the linked question apply to IE in certain circumstances? All I can say at this point is "we can't always pin down things like this."
UPDATE: I was able to make it happen reliably in IE by not setting the src attributes in the slideshows until after I set up the slideshow in Javascript. I think this proves it was indeed the same timing issue, just happening more rarely because IE is a different rendering engine. Management is still curious what other circumstances intervened, but I'm confident now that it was indeed a timing issue in all browsers, and our production site is safe from further issues.
Also, I asked the same question on jQuery forums here and was told to explicitly set image sizes in the img elements. This also fixed the issue.
It's explained in the link you posted. It's a timing issue. Sometime the cycle starts early, sometimes not. And 'sometimes' may just be 'almost never' in some browsers.
Starting the cycle in document.ready ensures that all images have been loaded before the cycle starts so the dimensions are properly detected.
It can very well depend on CPU speed, network latency, browser, OS and whatnot.
The reason it's so hard to reproduce consistently is because the environment is very complex, and the results depend on things you don't see right away.
I know this is late in the game, but I, too very recently experienced this problem. It drove me nuts. The solution is, in fact to use the $(window).load event method to start the cycle plugin--it guarantees that all associated page-load activity (including any downloads associated with ANY child elements) is complete before it fires. It works in all of the 'big five' browsers.
In my case, I am displaying images of different sizes and aspect ratios, and populating the image list automatically by using a server-side script to populate a variable containing dynamically created tags for all the image types in a designated directory that I tell it to include. Consequently, I can't include the image width and height in the tags, because I don't know what they are. In order to get around this, at the client side I use cycle's onbefore: to fire a script that dynamically looks at the image being processed and then sets the slideshow container to a width and height matching the photo's native width and height. I display a "Loading xx photos..." message with an animated GIF loader graphic so that the user knows something is going on while the images are downloaded.
The slideshow(s) in question reside in an area on the hangmanhills.org website that is restricted to Hangman Hills Residents' Association members only, so I can't show you the end product.
This video explains the problem best: http://www.screencast-o-matic.com/watch/cQ1Oc9f1L
Basically the directory is located here: http://www.ipalaces.org/uploaderprogress/grrrrrr.html
Is the problem piece using YUI.js as the uploading script. The YUI updates the table's row with new information on every event. So I have it update it with some CSS/HTML so that it does a progress loading bar. It works fine for all browsers but IE. I am not sure if this is a known rendering bug or what, and if there is even a fix for it?
the working-demo.html basically shows that if you just resize the div using javascript, IE renders it fine. Its just updated the table's row with new div information seems to cause rendering issues.
I couldn't reproduce the bug because you applied that fix. But I did take a look at the source. The way you are animating that progress bar just begs for bugs. Try compatibility mode in IE8 and you will see that it's shrinking instead of growing (because the element is centred) and that progressbar-completed element is 2x bigger then container. Same in Chrome and probably Safari.
This is how I would do it:
(source: maikumori.com)
Make A constant for example 250px. Then you have to make a background image with same size as A containing progress bar as if it was at 100%.
Then:
background-position = B = -1 * Math.Round(A * UploadedSize / FileSize)
Pros:
Takes less markup
If you make background image 2*A and B = B + A then you can have custom image for "blank" space therefore you can make fancier progress bars easily
Should work in most modern and not so modern browsers
Doesn't make a mess if user has css/javascript disabled
Cons:
A must be constant
Haven't tested =(
P.S.
Sorry for blinding colours, couldn't change them afterwards ... mspaint
I found a solution.
If I include this in the HTML then it will work fine:
<div class='progressbar-completed' style='visibility: hidden;'></div>
It seems like IE is having trouble maintaining the "memory" of the background file when its dynamically created in javascript.
Putting the DIV in the html itself seems to make the memory of the background file persistent in IE.