Dotted/Dashed borders fail on rounded corners in Firefox

I just learned today that a dotted or dashed border will render as solid for the rounded portions (specified by border-radius) in Firefox. There is an open bug for this, but I haven't run across it until just now. So if you're wondering why you can't put a dotted border on that circle in firefox - that's why.

Which looks like this in Firefox (screenshot from v21)

demonstrating the Firefox bug for dotted, rounded borders

Comments

Be Careful Using SASS @extend, CSS3 Selectors, and IE8

I recently ran into a situation where some of my styles were broken in Internet Explorer 8. What makes this different from all the other times my styles broke in IE8 was that, as far as I could tell, it was correct. Consider the following code: %highlighted { background-color: #ff0; color: #333; } .keyword.is-active { @extend %highlighted; padding: 10px; text-transform: uppercase; } No problem, right? Then why isn't it working? I wasn't sure, until I looked at the compiled CSS and saw something like this: .some-list:nth-child(2n), .is-highlighted, .keyword.is-active { background-color: #ff0; color: #333; } .keyword.is-active { padding: 10px; text-transform: uppercase; } Since IE8 doesn't support the css selector nth-child , it ignores the entire rule . Without looking at the final output, there's no way of knowing if this will happen ahead of time. So what can you do? Well,...

SASS Converts Zero Opacity 'rgba' To 'transparent'

I recently had a strange problem after updating SASS. I have a modal dialog with a semi-transparent overlay behind it. For modern browsers, I'm using a CSS transition from rgba(0,0,0,0) to rgba(0,0,0,.5) For older browsers (namely IE8), I'm using some JavaScript to apply the transparency and animate the transition. To make sure the background gets set correctly, I'm using the standard fallback strategy of defining the background as background: rgb(0,0,0); right before the rgba line. This worked fine, until SASS optimized my code by changing background: rgba(0,0,0,0); to background: transparent; The reason? It's 2 characters shorter. Yes, we've now saved 2 bytes of easily compressible text in exchange for breaking my code. Why did it break? Well, if you haven't already figured it out, normally a browser that doesn't support rgba will simply skip that property and move on. But transparent is supported. So now, instead of h...

Flags vs Vendor Prefixes for Experimental CSS

Google recently announced that it will be switching Chrome's rendering engine to a fork of Webkit, called “Blink”. If you're interested, you can read their blog post about Blink . One of the changes we will be seeing in Blink, is the use of browser flags in place of vendor prefixes . What this means, is that rather than prefixing experimental CSS with -webkit-, -moz-, -ms-, -o-, -khtml-, etc.; We will be required to enable these attributes using a flag in the browser (like the ones currently at chrome://flags). If you ask me, both ways have their advantages and disadvantages. Though, in the end, I lean towards the flags over the vendor prefixes, and here's why: #1 Code Bloat On average, using CSS with vendor prefixes requires writing it 5 times . Every time you use it . #2 Future Friendly Eventually, prefixed code will be replaced by the unprefixed code. #3 Browser Dev Friendly Browsers tend to continue to support the prefixed code, even if it doesn...

Browser Cache

Search This Blog