Skip to main content

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
Labels:

Comments

Post a Comment

Popular posts from this blog

Element.focus() in IE9 running Jasmine tests with Karma

I recently udpated our Jasmine unit tests to run in Karma ; expanding our browser coverage, adding code coverage reports , and using fixtures for testing DOM manipulation . One of my tests kept failing in IE9, but only when I ran from the console. If I attempted to debug in the browser, everything passed. It turns out that IE9 (at least) needed a few ms to catch it's breath before correctly focusing on the starting element. To do this, I just added a 100ms delay before each test ran (Using Jasmine 2.3). beforeEach(function(done){ loadFixtures('myfixture.html'); // Setting focus in IE requires a delay to work correctly! setTimeout(function(){ done(); }, 100); });
Post a Comment
Read more

CSS line-height Units Explained

In Chris Coyier's recent article, " Fun with line-height! ", he mentions that we often use unitless values for line-height so that it's proportional to the font size. This is only part of the story, and I was reminded of a Stack Overflow question that got me investigating more about how line-height worked with regards to the various CSS units. If you're declaring the line-height on each element, you won't notice any difference. But if you're not crazy and using the first C of CSS (that's 'Cascading', by the way), then the inherited line-height might not work the way you expect. Disclaimer: This is my understanding after doing some research and testing. I may not be completely correct. TL;DR When using a relative unit (em, %), the line-height is calculated based on the font size of the element where the line-height is defined. This line-height is then inherited, unchanged, by each of its descendants. So we end up with a line...
Post a Comment
Read more

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...
Post a Comment
Read more