I have a large number of template files I am printing with Chromium. They all rely on the same CSS file. On a good number of them I need to just make everything a little smaller. If I adjust the scale in Chromes print options to 75% I get the desired result.
I need a way to get a similar result in CSS?
The only browser compatibility I need is Chrome.
This question was asked before, but wasn't really answered as the person asking the question was only using this as a workaround and found a better solution to the problem. In my case I really want to know the answer to the asked question.
Css to emulate scaling in Chrome
I have tried all the suggestions proposed in this post and none of them worked.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
I am working on a Responsive Layout for my Website. I have an extra space on the Right side for English and Left side for Arabic Version, I can not exactly determine were does it come from. this responsive it looks good in FireFox but in Google Chrome creates it.
link of my website :
http://kirkuknow.com/english/
change the website to mobile version at inspect element
Bestenter image description here
English version - It seems to me that the problem is in the div with id #subNews in the mobile view of the website. It contains several divs with the class .subNewsContainer, which are empty, but still hold their widths.
Once I removed #subNews via the Chrome developer tools, the right side blank white space was gone.
Maybe the problem here is that you're not handling that subNews part correctly in the mobile version? You're not rendering any content, but still rendering the divs.
Edit (adding the root cause for arabic version): - it seems the problem in the Arabic version is different. There, the div with id #langbar (language bar?) has a fixed absolute position from the right (600px), and therefore goes a lot to the left, therefore creating that blank white space. Removing it from Chrome developer tools fixed the problem, so you should fix the stylesheet for that div and the ones below it.
General tip: the easiest way to find these issues is just start searching in developer tools. Start deleting each div in the DOM tree, until the problem is resolved. Once you deleted an element and the problem was resolved, you can dig deeper into understanding why that specific div causes the problem. Good luck!
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
Have a curious issue with my footer links in chrome.
http://www.kfc-uerdingen.de/
Firefox has no problem displaying the links in the footer. However in chrome only the ones in the first column are clickable.
Before that I had another issue with chrome where all but the last columns disappeared as soon as there were more than two, but I solved that by adding the footerContainerInner-div, which took over the column related css.
It's not a z-index issue from what I can tell.
Has anybody encountered this before of can see what's going on?
One solution is to avoid nesting transforms.
Instead, you can use transform: rotate(-2deg) skew(-2deg) on #footerContainer.
Transforming an element modify its stacking context; it seems chrome doesn't handle it very well when you use columns.
It may be a bug.
Try running in compatibility mode. Also, I understand that z-index is not the only step. In order for the reference to be cross-browser compatible, the push and footer classes also need to be position relative for the z-index to be recognized (add -webkit-transform:translate(0,0)).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Edit: Resolved. Rather than resetting the Zoom to 100%, the "View < Actual Size" resolved the issue.
I've been having an issue with Chrome rendering divs as fractions and not exactly as the specified numbers.
For example:
HTML
<div class='tile'>foo</div>
CSS
.tile {
background-color: #CCCCCC;
border-width: 2px;
border-style: outset;
display: table;
float: left;
}
Rather than being rendered as 2px, the border-width is "1.8181817531585693px" inferred both from the Chrome Developer Tools > Elements > Computed and using the debugger with jQuery .css function.
A few additional things to note is that this only happens when it's loaded on an FTP, not locally. This issue also doesn't occur in either Firefox or Safari. Any ideas or explanation as to what exactly Chrome is doing, or the solution to it would be much appreciated. Thanks!
The short answer is they are dealing with real numbers that are binary internally, and things must be done quickly.
So some numerical corners are probably being cut, that are normally not noticeable to the average web page viewer, that is if a page is designed so that it is not noticeable.
Go figure, I know, you would think that browsers would be more accurate, but I have found that even with the most careful and detailed control of my css, there seem to be rounding errors that play havoc with small details when displayed.
First, I would suggest you use em rather than px. I know you might have to start over with your css, but I have found it to be more reliable, screen to screen. Remember modern pages are not based on pixels. They are dynamic beasts that can be zoomed in and out, and squished narrower and still must output something reasonable.
Also I would suggest rethinking how you are laying out your page so such small details are not an issue. In carpentry the skilled artisan knows how to hide the rough edges with a molding.
I have a very accurate web page I use to generate to a special printed flyer. It was a royal pain to force html and css into something they didn't want to do, which was be accurate.
Also I can test my production site on the 5 major browsers, right on top of each other so I can see little differences when I switch between them, from one browser to another. They are all off just a little from each other in various ways, and really there is no way to make them accurate.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Mine would have to be the float and margin bugs...
If you float an element, and then specify a margin for it, it will double the margin.
The solution to this is to add display: inline to the element. This will stop the double margin, and all other browsers will ignore it because only block level objects can be floated.
I wish I'd known that I'd be spending hours trying to fix a bug in IE 6 over and over again for years on end and I really would have been happier delivering pizza.
I wish I knew about quirksmode.org. The compatibility tables, bug reports, javascript examples are all very useful.
Don't code for IE6 first. That's the path to madness.
I wish I'd known that many IE 6 error line numbers are off by one.
Number one thing: hasLayout
If I had known about this from the start most of my worries would've been solved.
I even regard it as a worse problem than IE6's stupid box model.
That if your really anal and spend shit loads of time on it that it pays off and you then become an IE guru fearing nothing but the sad self you have become...
Although it is nice to impress people with your amazing IE bug fixing abilities...
Most IE bugs can be avoided by using different (normally better) CSS methods and super clean logical xhtml
Always clear your floats with overflow hidden (or just hasLayout for IE)
Understand what hasLayout is (basically a css porperty that gives IE a kick in the ass)
When you start devving sites check IE6 all the time, untill your a pro ;¬P
Unfortunately, and I do train a small team of 6 developers, experience is one of the only things that really helps with these problems, stay calm, do good research in google and post your problem to a community if you really are stuck with a good demo of the problem.
Nice links >
http://css-tricks.com/ie-css-bugs-thatll-get-you-every-time/ (although I recommend the PNG fix by Bob Osola /-0)
http://www.gtalbot.org/BrowserBugsSection/ (amazing and funny... great!)
Good luck!
I wish I'd known why Microsoft hated me so much.
I wish I'd known about Position is Everything, but specifically the peekaboo bug has always got me.
I wish I'd known about
the conditional comments to include stylesheets just for IE
xhtml headers to make IE render in compliant mode
the box model problem, so that I knew what to put in my IE stylesheet
After I learned about these things, I haven't really used a lot of time fixing problems in IE6
.Hauge
Transparent PNG should have been supported...
the underscore trick
if you put an _ infront of the css atribute it only gets read by ie6.
ie. _border: 1px solid #000000;
creates a border only in ie6
Probably that SELECT elements dont render with the correct z-order.
For example, if you have a floating DIV with a higher z-order overlayed on top of a select - the SELECT element will still render on top of the DIV.
Infuriating.
The rendering quirk which causes a small white space underneath an image in a table cell if there is any white space between the end of the img tag and the closing td tag.
This renders right:
<td><img src="myimage.jpg"></td>
This renders wrong:
<td>
<img src="myimage.jpg">
</td>
The main problem we have had is with scheduling enough "fix in IE6" time. That and the designers' tendency to come up with stuff that is easy to do in Flash and tricky to achieve in CSS has cost us many days of extra work.
I wish I knew that my code didn't validate. Or that an XML declaration in XHTML puts IE into quirks mode.
http://www.pushuptheweb.com/ or one of many other sites pushing to drop IE6 support. I'm aware that rendering web pages correctly for IE6 visitors is the core of many web businesses, but sooner or later something has to give. I just dont get why MS doesn't force an update >.<
That even with all the PNG hacks in the world, if you're using PNGs as backgrounds in your divs (to make, for example, a panel with rounded borders), you're headed for a world of pain. (Links and other elements not being clickable, IE6 crashing in earlier versions of the png dll, etc.)
In summary: don't use transparent background PNGs if you want it to work in IE6.
The importance of DOCTYPES in IE, and
Web Bug Track
I Wish I'd Known That Internet Explorer Is The New Netscape Navigator 4.7.x
1
hasLayout and this excellent explanation:
http://www.satzansatz.de/cssd/onhavinglayout.html
I had a new lease on life once I'd wrapped my head around it! Ensuring that the containing element hasLayout fixes the vast majority of my problems.
2
jQuery!! Writing IE-specific CSS is bad enough, so I'm glad I rarely have to worry about JS anymore.
I wish I'd known about dev tools like Firebug Lite and HttpWatch that make debugging lots easier.
in addition to other IE bug lists that Ross and Loque gave above (gtalbot.com, what a beautiful site!
http://css-discuss.incutio.com/?page=InternetExplorerWinBugs
http://webbugtrack.blogspot.com/search/label/IE7
http://www.enhanceie.com/ie/bugs.asp
http://channel9.msdn.com/wiki/internetexplorerprogrammingbugs/
(like gtalbot, it'll take you hours to scroll thru this
and, hey, IE 8 beta 2
http://css-class.com/test/bugs/ie/ie-bugs.htm
finally, the IE voodoo doll!
http://www.flickr.com/photos/chisa/1349759901/
*{margin:0; padding:0; border:none}
i swear to god this line changed everything. presto! everything is the same size! and then i dove into the rabbit hole that ya'll find me in now. marvelous.