This "just another blurry icons issue" is starting to give me serious headaches, that's why I decided to ask for some help here. And believe me, I have already read all the 'blurry icons' articles on the web.
The image below shows what's happening with the font icons on github.com when you resize the browser width, switching between odd and even values.
But the problem comes from somewhere else, it comes from some parent element (.container) which centers itself using margin-left/right properties set to 'auto'.
All the icons are properly grid-aligned, they all have font-smoothing: antialised, and the SVG font is already moved in front of the .ttf one. So no, it's not one of these problems. It's strictly related to how the browsers render the font icons when you have a parent container center aligned by using margin auto.
Any ideas how to fix this without changing the margin property of the self-centering parent container?
Struggling with the same issue myself. At least in my case, it seems to be caused by the icon glyph's horizontal position ending up at a sub-pixel value (e.g. at 99.5px instead of 100px). This can be caused by a lot of different situations, such as horizontal centering (as in your case).
Unfortunately, I'm not aware of a workaround other than adjusting the icon's horizontal position case-by-case, e.g. by applying a sub-pixel margin that adjusts the icon's position back into the pixel grid (e.g. margin-left: 0.25px).
Related
Code sandbox: Code sandbox
I have a column of Icon like this:
I css it with overflow-x:auto so that It can scroll the icon outside the container.
But when It bounced out. The overflow-y: visible didn't work for me so the Icon is still inside the box.
I tried using oveflow-y but didn't work for me. I coded a code sandbox so that you guys can have a look. Thanks for all of your help! Have a nice day!
For overflow-y to work, the height of the content in the element needs to exceed the specified height.
I just removed the height of container and slightly increased the padding of AppBar to make it work. Yes, you have to little workaround to meet the height of the container actual to the design.
Another solution, for now, I can suggest is to play with z-index property of the elements.
SanBox
from mozilla : "Setting one axis to visible (the default) while setting the other to a different value results in visible behaving as auto."
source : https://developer.mozilla.org/en-US/docs/Web/CSS/overflow...
You could avoid this side effect either by controlling the scroll another way (css and javascript driven scrollbar) (this would by the way avoid the different scrollbars on some browser which can be a little ugly (ie under edge), either by setting the container bigger, and setting a nested element for the background.
I'm finishing this website page, http://www.goldhairmoveis.com.br/bancos
But somehow the product alignment is broken.
All the configuration is the same for all divs and only this is broken.
The problem is that one of the images (cadeiraopop.jpg) is 1px bigger than the rest.
The reason this is a problem, is the bootstrap alignment is done using css floats. So what is happening is the element starts and the oneside of the page and floats in the direction that you have specified (in this case, starts right, floats left). It continues to float until it hits something and then it stops. There for, you will need to ensure all images are the same height (preferably the same width as well.)
You can do this by manually editing the image size, or just use a css height attribute.
I am using the built in canvas widget (javadoc) and wondering how to make it take the full browser window.
I tried setting 100% width and height and removing all padding and margins, for body,html and canvas.
I have 3 problems:
1. I checked with chrome's dev tools and the clean.css seems to override myproject.css
2. Even after those css rules and removing the margin on the body in the dev tools, there is still a vertical scrollbar.
3. I struggle a bit with the fact that the canvas coordinate space is independent of actual pixel size. The mause events give me pixel location. Is there a way to get events in coordinate space "pixels"?
After another 4 hours of fiddling I found the answer, and decided to share:
1. I saw that the way i used to load css was deprecated so i used client bundle
2. This was my main problem, solved by explicitly disabling scrollbars
Window.enableScrolling(false);
3. setting just the coordinate space will automatically adjust pixel size to it.
So basically for a full window canvas: 100% width and height and 0px margin in css for html and body. Adjusting coordinate space to client size in the on resize event and explicitly disabling scorllbars.
I was very surprised when I found that a <div> with a size of - say - 200px becomes 220px wide if you give it 10px padding. It just makes no sense to me, the external size should not change when an internal setting does. It forces you to adjust the size every time you tweak the padding.
Am I doing something wrong, or is there a reason for this behavior?
EDIT: I know this is how it's supposed to work, my question is why? Is it logical in a way I don't understand? Does this give any advantage over the opposite approach of keeping size and padding separate?
There are two different so-called "box models", one adds the padding (and border) to the specified width, while the other does not. With the advent of CSS3, you can luckily switch between the two models. More precisely, the behaviour you are looking for can be achieved by specifying
box-sizing: border-box;
ms-box-sizing: border-box;
webkit-box-sizing: border-box;
moz-box-sizing: border-box;
width: 200px;
in your div's CSS. Then, in modern browsers, the div will always stay 200 px wide no matter what. For further details and a list of supported browsers, see this guide.
Edit: WRT your edit as to why the traditional box model is as it is, Wikipedia actually offers some insight:
Before HTML 4 and CSS, very few HTML elements supported both border and padding, so the definition of the width and height of an element was not very contentious. However, it varied depending on the element. The HTML width attribute of a table defined the width of the table including its border. On the other hand, the HTML width attribute of an image defined the width of the image itself (inside any border). The only element to support padding in those early days was the table cell. Width for the cell was defined as "the suggested width for a cell content in pixels excluding the cell padding."
CSS introduced margin, border and padding for many more elements. It adopted a definition width in relation to content, border, margin and padding similar to that for a table cell. This has since become known as the W3C box model.
The reason why it's like that is that technically the width of elements is supposed to apply to the content, not the container.
According to the CSS1 specification, released by the World Wide Web Consortium (W3C) in 1996 and revised in 1999, when a width or height is explicitly specified for any block-level element, it should determine only the width or height of the visible element, with the padding, borders, and margins applied afterward.
More info about this behavior*
* Disclaimer: Yes, this is my own blog and I think I did a thorough job of explaining the box model so I'm putting it as reference.
Padding is supposed to be in addition to the given width of an object.
See the CSS 2.1 specification for box model.
While it is true that you can view padding as either an internal or an external attribute, the fact of the matter is that according to the current specifications it is an external attribute. It was a choice between two, as far as I can tell, equally valid options.
I haven't read up on the box-model attribute, but assuming that alex is right, then in the future you will be able to choose between the two ways of interpreting padding.
If the size increases with padding, it's working as intended. In browsers with broken box models like older Internet Explorer versions, the div will be 100 pixels wide, but that's incorrect handling of the CSS.
http://www.w3schools.com/css/css_boxmodel.asp
If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?
It's better that the default behaviour is that the width of the container is not affected by padding or margin values.
If your box is within a box, remove the inner box's width (the one with the padding) and it will fix the problem.
""If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?""
First of all, any good web developer would know better than to put an image into a container where it doesn't fit. That is developing 101. If the padding doesn't allow for the image, the image or the padding should be changed. Pure and simple. So the argument mentioned above is faulty.
Padding is an internal setting, internal to the boundries of the container. So when something is inside that container, and you increase the container's padding, the item(s) inside that container should coded so the can be reduced in size.
The word "padding" itself says it all. Can you imagine if UPS added padding to thier boxes to protect the contents inside, only to find that the box increases in size! Rediculous, right? Of course it is! Padding is meant to add space around the inside of a container WITHOUT the container breaking and expanding in height or width.
It's browsers like mozilla, gecko, and opera that have broken box models, not IE. The box model that the "consordium" implements is faulty at best and reaks havoc on web develpers.
If the "consordium" implemented the same box model as IE, than we developers would have a much easier time with the columns of our webpages. I think you have to agree with me on that point. Plain and simple.
I am so tired of people saying that IE is inferior. I can give tons of examples where IE holds strong while the cheaper browsers like firefox break under the pressure.
My two cents. Hate me if you want, but what I speak is common sense and nothing else.
The font size I need to match the design I have is 85pt, which is extremely large. In IE6 and IE7, my design is affected because the divs that contain these elements become larger than they normally are, and as a result, elements under these are pushed further down, somewhat breaking the design. I have the height defined for these elements and when I decrease the font size, the elements begin to shrink to the correct size. I've added line-height: 0; to the element and this works in all modern browsers.
Unfortunately, the design I'm working on cannot be shown publicly, but I was hoping to get some insight into other possible techniques that I could try to get the design to render correctly. The height of the parent element is 144px, which includes 10px padding on top and bottom and a top and bottom 1px border.
Unfortunately there's not a lot more that I can add to this, but I'll include whatever info I can if asked.
line-height:0 is a great start. However, I'm a little concerned about the 10px padding on the parent element. Whenever you mix padding with IE, you start to lose control over width & height.
I'd start by removing the padding-top on the parent and convert that into a margin-top:10px on the actual child element. If that still gives you trouble, remove the margin and try a position:relative on the child with a top:10px.
Finally, try adding a overflow:hidden to your parent element to force it to not budge when the font-size gets larger.
All this depends on what your child element actually is. If you convert it to an inline element (like a span, em, or strong) it might help alleviate some rendering issues, depending on your predefined styles.
Another thing to consider - are you using floats? Sometimes you'll get a double-float issue with IE and floats. A quick google for "IE double float" will show you why.
Does that help?
Convert the font-sizes to pixels and use px instead of pt. Make sure there that padding, margin and border is 0. Verify that there are no whitespace in your HTML except for between words. Whitespace can end up being displayed as a newline or space, making elements bigger than intended. Also don't set line-height to 0, set it to either auto or the same as font-size.
Thank you all for your input. Originally I needed absolute positioning on the element in question, while the parent element had relative positioning. However, using this with line-height: 0 caused the text to disappear in IE6 and 7; after trying to figure out where the text was initially, I removed absolute positioning and decided to leave the text left aligned in IE6 and 7, which affected the position of other elements as a result. I revisited the original absolute positioning and added border to the element to reveal its location. Doing this showed that it was exactly as I defined it: an element with a line-height of 0px, so the top and bottom borders were next to each other. For IE6 and 7, I defined line-height: 100%; and my text was almost where I needed it. I added top and the needed pixels and now my element is in the correct position with its line-height not affecting any of the other elements because of the positioning.
Thank you all again for your assistance.
My first thought when reading your post was to adjust the line-height, but since you've already done that, I'm not sure how much more can be done. From your summary, I gather that the design cannot be modified to account for the large font sizes.
Another answerer recommended using pixel sizes, but I would recommend using ems as they are percentage dimensions and will be more consistent across browsers, screens, and resolutions.
Line-height can be left as 0 (or set it to the height of the parent element), but you will likely see the text floating over other elements if the text's height surpasses the line-height.
Any possible way you could use an image for the text instead? That's really the only fool-proof method for getting all browsers to look consistent.