CSS: When does -ms-overflow-style NOT apply? - css

There seem to be some situations in which -ms-overflow-style doesn't apply, even though I don't see any CSS that sets that property. The (awful IMO) auto-hiding behavior isn't happening, without using "-ms-overflow-style: scrollbar". Does anyone know what other DOM or CSS circumstances might cause this?
EDIT: I didn't make myself clear, apologies.
I work on a large app with a lot of dialogs that appear in a custom lightbox built on top of script.aculo.us. In Edge, in those dialogs, scrollbars on divs don't work, and dropdowns exhibit some harder to describe problems.
There are several striking things about those problems:
Edge only
Can be prevented my defeating Microsoft's auto-hiding scrollbars with this CSS: {-ms-overflow-style: scrollbar;}
Only happens in those lightboxed dialogs
I was asking what defeats -ms-overflow-style because the problems appear to be the result of Edge's default behavior, which outside of those lightboxes, is being blocked by something. I was essentially asking what that something might be.
I don't want to "use" -ms-overflow-style, except to get rid of Edge's auto-hiding scrollbars, and only if I have to. Outside of those lightboxes, it seems not to be needed. I wondered why.
Does that make more sense?

Related

What are the downsides of using text-shadow for font anti-aliasing?

I found this method:
.fontSmooth { text-shadow: 0 0 1px rgba(51,51,51,0.5); }
and it works perfectly! but in some places it is said that it's a bad solution (with no further explanation), why is that?
It'll probably work, though there are two main issues.
First off, as coreyward originally pointed out (though he apparently deleted the post after one downvote), the text-shadow property is part of an ever-changing HTML5 spec. It's relatively new on the scene, and its syntax and implementation are liable to be extremely different across browsers and may change even further over the next few years.
The more short-term issue here, though, is that blurring a text shadow takes serious work on the part of the browser. It's fine for maybe headers and the like, but if you're planning to apply this to your whole page, please bear in mind that it will run much slower in older computers, and even scrolling up and down will be laggy. So, be careful in deciding to what extent such smoothing is appropriate.
I'd also like to point out that, if the user hasn't enabled anti-aliasing system-wide, it's quite possible that the user doesn't want it. It's just kinda silly to use CSS tricks to override a platform-level setting.
Normally you should not try to fix that kind of things that are responsibility of users-side. It might work well under certain conditions, but as shadows were not meant for that, you cannot be sure its visual impact on different conditions.

Weirdest IE bug ever? -- hovering a link causes page elements to jump up and cover others

Ok, I've been dealing with IE bugs for a long time now, but this one is beyond me. IE 7 and even 8 does it for sure, I've not seen it on FF or Chrome.
So here's a live URL which produces it: http://mog.com/music/America/Holiday
Reproducing isn't easy, it can take a few times to make it happen. Watch your scrollbar to see it change size so you know the page length was suddenly dropped quite a bit.
Here's how you do it:
Hover over any sub-nav link (Main, Albums, Songs, Photos, News, etc.)
Try them until you see the scrollbar change size. Once it does, scroll all the way down and notice the footer has jumped up on top of much of the page content.
Be careful scrolling down that you don't roll over a few other page elements that will suddenly fix this. So far I can see that any of the Play buttons will somehow fix this.
It's just beyond weird. How could a rollover state cause this kind of behavior?
I've tried:
Removing the a:hover style - THIS FIXES IT... WTF? Of course we ideally would keep some hover state, so hoping to avoid this fix.
Reproducing the hover functionality using jQuery hover(). - THIS DOESN'T FIX IT.
I figure the clues are in the elements that somehow magically fix it...and possibly in where the page jumps to, what elements suddenly get obscured by the footer.
Lastly, I didn't produce this site from scratch and it uses a lot of absolute and relative positioning for certain things and I know that is partly what causes these weird bugs. I rarely, rarely use esp absolute positioning to avoid these kinds of bugs, but it's a bit too late now.
Thanks for anyone willing to check it out!!
Well, I figured it out. It was an odd case of the "Guillotine" bug. One I luckily haven't come across before. Turns out the "special" CSS rules on those nav links' hover state (particularly it seemed the border and bg image) were enough to trip this bug. One way around was to drop those styles, but not ideal. The real fix, however, was an unsemantic clearing div placed in just the right spot. More info found here:
http://www.positioniseverything.net/explorer/guillotine.html
Hi just a short note: When did you validate your html the last time?
As you probably know, but might have forgotten, fixing your html can sometimes solve a lot of problems. There are 72 errors seen by http://validator.w3.org

Are there some good CSS practices in order to avoid browser-compatibility issues with IE?

I've discover so far that:
stating the width in some elements fix issues in IE.
and of course using a CSS reset
Do you know any others?
Learn about hasLayout
Inline block behavior can be achieved on IE7 by turning on hasLayout, then setting display to inline. This has turned out to be quite useful to me.
Make sure your doctype is present and correct. This alone can save hours of pain.
Use conditional comments anytime you need to hack something especially for IE. PLEASE don't fall into the amateur's habit of adding star/underscore junk in your main stylesheet.
I'd say that manually setting width would more often than not break things in IE, as a lot of IE versions implement a flawed box model.
I'd also say that a lot of all browser incompatibilities originate from a sub par understanding of the box model and float/clear, block/inline.
Having said that, I of course do not deny that it is IE, rather than the developer, that is the real problem, but I usually seek to avoid browser incompatibilities by using HTML structures that not even IE could miss-interpret, rather than through CSS hacks, and I've found that that is often quite doable.

IFrames Dual Scrollbar Issue

I am using an iframe right now.
This is not my first choice and I generally try to avoid them, but the problem is the client has different versions of their middleware on different boxes and is reluctant to upgrade one of them.
Anyway, now that I've made my excuses. :)
I am trying to display a pretty sizable page and there is scrolling involved. But for some reason, sometimes there are double scrollbars. One on the page, the other in the iframe.
Does anyone have a workaround for this? I would like to have just one scrollbar.
I think I figured it out, just eliminate all the margins in the enclosing file.

Is CSS layout really as delicate as it seems to be?

I have been experimenting with the Majestic template at freecsstemplates.org. So far so good; I really like the look (or to be more specific, my boss really likes the look).
However, I am noticing that the CSS that drives this template seems very brittle; small changes can cause really radical breakage. In particular, if I reduce the size of the header in the CSS (to eliminate some of the empty space at the top of the page), both of the outside columns suddenly disappear.
With small websites, sometimes I cry uncle and just use tables for layout. I realize this is heretical; should I be leaving the design to the professional designers? Or maybe I'm going about this the wrong way, and someone can set me straight.
I honestly think this layout has been made pretty badly. The width of the elements seems to change where they appear on the page, and they're all need to be pixel perfect for everything to be centred.
For some bizarre reason the whole page has been placed inside the div element marked 'header'... This doesn't make much semantic sense for a start.
However, it seems if you decrease the width of every element which has one, then everything does get smaller, and nothing should disappear.
I would recommend looking at some other more sensible layouts, since I don't think this is a very good way of attaining that style -- as you've said, it's brittle. Have you tried using the extension Firebug for firefox? It allows you to make on-the-fly changes to the css, and see how it affects the style, which will help you learn fast.
CSS is delicate, but still easier to deal with than a site full of table layouts. I found Dave Shea's book CSS ZenGarden to be a great help in learning CSS from a designers perspective.
Often in layered templates there are a few places where changes to CSS can be made, and it can be really confusing to follow which selectors are controlling the element you wish to manage. There are many tools out there that can help, but some that have been useful to me are:
Google Chrome and its Inspect Element option
Selector Gadget - a bookmarklet that will help you visually determine the selectors that affect an element
Firefox's Web Developer plug in
One other tip is to learn about the !important modifier - it can come in handy to force a particular property setting when there are multiple CSS selectors affecting the same element.
CSS in my experience is easy to understand in concept, but takes a long time to master.
Brittle CSS can be very brittle, but good CSS can be wonderfully flexible.
As it stands CSS can either make layouts wonderfully simple and flexible or it can make the simplest of tasks an absolute nightmare.
Purists will tell you to use CSS no matter what, a pragmatist will tell you to use what works. If using a table or non-CSS solution makes something infinitely easier to do, then use it!
Personally I try to use pure CSS as much as possible, but there have been times when I want to do nothing but swear when something glorious in FireFox looks awful in IE. This is where the hacks come in. It is these hacks and work arounds that tend to make CSS brittle in the first place.
Half the problems with CSS would go away if all the browsers did precisely what the CSS spec says they should do. Alas, this is yet to happen so we have to live with either using tables, or on occassion, brittle CSS.
The best solution is to make the design as simple as possible. If you find you have a hundred divs and lots of CSS trickery to do something straight-forward, stop. Re-think how you are approaching it and try again.
At the end of the day your website users don't really give a monkeys what your website looks like as long as they can get at the information they want with minimum effort. Successfully manage that and they will not care how photorealistic that shiny nav bar is, or how well the borders line up etc.
That's my 18pence at any rate :)
I agree most css template is hard to read, and different people may have a very different approach to the same layout strategy. Since there are too many hacks/tricks/techniques in css it is really fragile when you try to modify those existing one since almost all cases, the styles are very dependent to each other.
Css doesn't break as long as you don't break it ;) It's a language. Just like a regular one, if you don't use proper grammar people won't understand what your saying.
If a layout doesn't work or suddenly your page looks rubbish, I'll guarantee you it's your fault. Css isn't brittle, the code you wrote with it might be.
So start by learning the basics and don't just dive into some file you found online which might (in your case, does) contain very bad code.
If you end up wanting to use tables for everything may I suggest you start looking at some grid systems like http://960.gs/ and ease your pain.
Gideon

Resources