Check out the "Signs of Hope" hero text in IE8: [removed]
Do I have to hack away at a conditional stylesheet, or is there a better, IE8-compatible way to do this typography?
Looks like you've figured this out, but for future knowledge seekers I'm going to guess the whole text was set to some particular line-height, despite different font-sizes.
The white text needs one line-height and the green should have another; or you can just remove line-height, or set it to normal, and let the browser automatically handle the different text sizes.
Related
I want to change the background color of an edit control (i.e. regular EDIT window class) in that control's EN_SETFOCUS. I know that I should handle WM_CTLCOLOR, do SetBkColor() on the DC I get, and return a handle to a brush with the background color. HOWEVER, when I do that from EN_SETFOCUS, my control isn't invalidated or redrawn properly. Basically I get a 1-pixel border in the wrong color around my text; so a rectangle within the black border that is already around the control itself. If I move my mouse cursor over the control, some parts of that wrong border are redrawn correctly, and sometimes the whole artifact disappears after a small amount of time, as if some timer is causing a complete redraw.
I have tried invalidating the control in various places, RedrawWindow, SelectRgn(NULL) on the DC, playing with wS_CLIPCHILDREN and -SIBLINGS of the dialog, invalidating the dialog on the rect the control is at, but none of this works. I have also found a vague reference to a similar problem online in a post from 2001 (!) but no solution. Has anyone ever encountered this? Any ideas on other things I could try?
FWIW, this is using VS9 on WinXP, and using MFC, but I've also send messages 'by hand' and that didn't change anything, I don't think MFC in this case is the culprit. Of course I could be wrong :)
Edit:
Code of the dialog of the screenshots below (minimal sample) is here: http://pastebin.com/zepdhdp5 . This is a small wizard-generated app - nothing special, the full source code can be downloaded from https://www.dropbox.com/s/d8nxaryoo0vclue/edit_control_redrawing_sample.zip .
The control looks like this after it gets focus:
and like this when it loses focus:
As you can see, it looks like there a border around the text area that doesn't get invalidated.
I have tried to reproduce this with pure win32, but when I don't use commonctrl6, it doesn't exhibit the problem. I can't manage to get commonctrl6 to work in win32 though, so I'm suspecting now that it's got something to do with that.
Well what do you know - after another day of intermittently attempting various things and trying different angles in google searches, I found the magic keyword: non-client area invalidation. Which led me to http://forums.codeguru.com/showthread.php?307470-Invalidate-NC-area , which contains the solution:
SetWindowPos(NULL, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_DRAWFRAME);
(in the SetFocus/KillFocus handlers)
My theory of what's going on is that the commonctrl6 visual styles manager treats the border around the edit control as non-client area, and miscalculates the area to be invalidated by one pixel when the control gets the focus. SWP_DRAWFRAME seems to be the only thing that forces a complete update of the control, RedrawWindow() with RDW_FRAME didn't cut it.
Ah well, hopefully my question here at least saves someone down the line from wasting his time like I have...
I am using flot to display a bar graph. Due to the long label of x-axis, I use a js plug-in which named jquery.flot.tickrotor.js.
The label looks fine on most computers. But on some computers, the letters in the label are kind of messed up and the font looks strange.
I really want to post the pic to show the display but I don't have enough reputation to do so.
Does anyone know what may cause this problem?
The labels are probably rotated using CSS transforms. Some browsers - mainly IE 7 & 8 - do a poor job of rendering the rotated labels.
If the plugin supports rendering text to canvas directly, enabling that should fix the problem. Otherwise there's nothing you can do about it. Since those browsers are disappearing from the market due to their age, the problem will eventually just disappear.
This is best explained with images.
Firefox, right:
Chrome, wrong:
jsfiddle.
That is a (fully green) image with 2px (red) border and a border-radius of 6px. In my design, the border is barely visible, so the image looks completely square in Chrome.
Is it possible to achieve the correct result in Chrome without extra markup nor javascript?
I don't believe you can do this with Chrome. Images will extend over the bounds of border-radius, and I think that's the intended behavior (or else they just didn't notice).
When using a div, for example, you can see that the background behaves as it should. You could consider using a div instead of img, and using your source image as the background (and forcing its width and height).
Plainly said: In Chrome, there does not seem to be a way to force your image to be hidden by the border of itself (or even of its container) unless it is set as a background. In fact, the issue has been asked about before, and blogged about as well (and, in fact, patrickzdb's comment there may help you).
Apparently it is a bug in chrome..
I normally apply box-shadow for chrome instead of border.
so, if you don't mind to apply css hack to workaround it without javascript: http://jsfiddle.net/3cuHU/
I'm using css animations on my page and Safari seems to change unrelated font weights elsewhere on the page when animations are running. Any idea why this happens? All other browsers work fine, include webkit ones like Chrome.
I've detailed the bug in a video here - http://www.screenr.com/gZN8
The site is also here - http://airport-r7.appspot.com/ but it might keep changing rapidly.
I'm using compass (#transition-property, #transition-duration) on the arrow icons. No transitions applied on the heading that's flashing. On a Mac - so it might be the hardware acceleration, but I'm still trying to figure it out.
When you trigger GPU compositing (eg, through CSS animation), the browser sends that element to the GPU, but also anything that would appear on top of that element if its top/left properties were changed. This includes any position:relative elements that appear after the animating one.
The solution is to give the animating element position:relative and a z-index that puts it above everything else. That way you get your animation but keep the (superior IMO) sub-pixel font rendering on unrelated elements.
Here's a demo of the problem and solution http://www.youtube.com/watch?v=9Woaz-cKPCE&hd=1
Update: Newer versions of Chrome retain sub-pixel antialiasing on GPU composited elements as long as the element has no transparency, eg has a background with no transparent or semi-transparent pixels. Note that things like border-radius introduce semi-transparent pixels.
Apparently, that's the price you pay for hardware acceleration: all text momentarily turns into images, which causes the drop in render quality.
However, applying html {-webkit-font-smoothing: antialiased} to turn off the sub-pixel anti-aliasing makes this problem go away. That's what I'm doing for now.
UPDATE: Since then, I've also come to learn that this happens only when the browser can't be sure if the section being animated is going to affect the text. This can usually be handled by having the text above (higher z-index than) the elements being animated, and/or making sure the text has a fully opaque background.
I've faced this issue numerous times and have had success adding the following css to the animated element:
z-index: 60000;
position: relative;
It seems it needs both z-index and position to be effective. In my case I was using it with Font Awesome animated spinners.
So I've spent a significant amount of time coding and designing this webpage, and it works perfectly in every browser I've tested it in: IE7, IE9, Firefox, Chrome, Safari. But when I view the webpage in IE8 (and only IE8), the vertical scroll is disabled. The scroll bar is there all right, but it's turned off and I can't use it or the mouse scroll wheel.
I'll post the code for the webpage if I absolutely have to, but first I wanted to see if anyone had ever heard of this happening before or had any initial thoughts.
Okay, I figured this out. If you put height: "100%"; in the html tag of your page's CSS stylesheet, it will break scrolling in IE8, but other browsers will still work. Go figure.
Here is a hack way of getting the scrollbar to work with a height of 100%. Not the best solution but it now scrolls in IE8.
html {
overflow-y: hidden\9;
}
html, body {
height: 100%\9;
}
body {
overflow-y: scroll\9;
}
mainly three things you should see
If you have given style as overflow:hidden
If you have given hight in page percentage.
if you have given float:static.
Fix this issue your IE 8 problem will be solved.
Reason : IE 8 is different than nything else for CBC check IE frist! To the topic, IE 8 hides (only scrolling bar) of scroll bar if you have overflow as hidden, secoundly if you have places hight as 100% IE 8 takes overflow as hidden (can say takes by its own!) n float is element who can go beyond page size if you have it as inherit or relative but static dose not increase dynamicly.
You tried on other IE8 (not your local ie8)? Maybe the problem is in your ie8.
Run with no-addon mode or try to disable all addons (including bars)
Restore advanced settings. Tools -> Internet Options -> Advanced -> Restore Advanced options.
I have also faced this type of problem many times.Scroll bar with IE8 , should not visible in a plain HTML page. So, please check the content inside your <body></body> tag . There may be is some margin or padding tag.
I am using IE8 currently , but there is no such scroll bar is showing. No need to fix the height:100% for HTML or BODY. Please check your page deeply.
If you are using CSS, it may come in handy that you need a reset CSS value so that the page renders properly in IE8. I have provided the link as well as the snippet from http://sixrevisions.com/css/css-tips/css-tip-1-resetting-your-styles-with-css-reset/ . This may help you. If anything this is a nice site to read if you are starting development.
A reset to where it all started…
The concept of CSS Reset was first discussed formally way back when dinosaurs still roamed the internet (2004 to be exact) by Andrew Krespanis. In his article, he suggests using the universal selector (*) at the beginning of your CSS file to select all elements and give them 0 values for margin and padding, like so:
* {
margin: 0;
padding: 0;
}
The universal selector acts like a wildcard search, similar to regular expression matching in programming. Since in this case, the * isn’t preceded by another selector, all elements (in theory – some browsers don’t fully support it) is a match and therefore all margins and paddings of all elements are removed (so we avoid the spacing differences shown in Example 1).
Applying the universal selector margin/padding reset to our earlier example, we now remove all inconsistent spacing between all browsers (in other words, we don’t make the browsers think for us, we show them who’s boss).
Example 2: Applying the universal selector margin/padding reset
But now we don’t have any spacing in between paragraphs, so somewhere below our universal selector reset, we’ll declare the way we want our paragraphs to look like. You can do it a number of ways – you can put margins (or padding) at the beginning or top of your paragraphs, or both. You can use ems as your units or pixels or percentages.
What’s important is that we choose the way the browser will render it. For our example, I chose to add margins (instead of padding) both at the top of the paragraphs and at the bottom – but that’s my choice, you may want to do it differently.
Here’s what I used:
* { margin:0; padding:0; }
p { margin:5px 0 10px 0; }
Example 3: Declaring a style rule after the universal selector.
Note: The example I used for discussion is a simplified example. If you only used paragraphs for your web pages and no other elements, you wouldn’t want to reset your margins to 0 using the universal selector only to declare a style rule right after it for your paragraph. We’ll discuss this more fully along with other best practices later on down the page.
Shortly thereafter – CSS guru Eric Meyer further built on the concept of resetting margins and paddings. In Eric Meyer’s exploration, he discusses Tanek’s work undoing default HTML styles (which he called undohtml.css) which not only resets margins and padding, but also other attributes like line-heights, font styles, and list styles (some browsers use different bullets for unordered list items).
After many iterations and refinements, we come to a wonderful solution called CSS Reset Reloaded CSS Reset, which not only makes this CSS reset method more accurate than the universal selector method by using higher specificity by naming all possible HTML tags (because the universal selector fails to apply the reset to all HTML tags), but also sets default values for troublesome elements like tables (in which the border-collapse attribute isn’t rendered consistently across browsers).
Of course, there are other methods of resetting your CSS (such as Yahoo!’s YUI Reset CSS which I currently use on Six Revisions), and you can roll your own based on your preference and project needs.
SITE: http://sixrevisions.com/css/css-tips/css-tip-1-resetting-your-styles-with-css-reset/
NOTE: I am kind of new at this, so please bear with me.