Browser Cache

I ran into an issue at work the other day that was a bit strange. A portion of one of our forms is using tables for layout (Yeah, I know... it's older code), in all other browsers the fields lined up with the others on the page, but in IE9 there was some unexpected extra space throwing the layout all off. I took a look, and noticed a few things: The table had a fixed width of 690px There were only two columns in the entire table, but the second cell had colspan='2' Both table cells had a fixed width The sum of the table cells widths (including padding and all) was less than the width of the entire table So what does all of this mean? Well, the main issue is that, since the total width of the cells is less than that of the table, the browser has to figure out what to do with the leftover space. Let's see what happens (I'm leaving off the colspan and adding some extra elements for demonstration purposes). cell 1

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)

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'

I've seen some responsive image solutions proposed, and they seem great. But there's still some debate and it will be a while before support is widespread. In the meantime, I've expanded on a method I've been using for re-sizing images on the fly, which I believe can be further expanded on to make it even better. Basically, I use a PHP script and ImageMagick to generate a re-sized and cropped image, which I also cache for later use. Here's the essentials of the script I'm using: Using this script, I can request re-sized images via JavaScript, or even CSS (presuming the image is in a background) based on the current screen resolution and pixel density. This may not be the most elegant solution, but it's worked fairly well for me. For the purpose of this example, assume this script resides at domain.com/tools/ Note: This is an untested adaptation of a working script. It may not work as-is. $file = urldecode($_GET['f']); $widt

The Problem I wanted to grab the width and height of an image that was on a remote server. I've done this with PHP, but never in .NET. The Solution I did a little digging and came across this code (slightly modified for my own purposes). Dim request As HttpWebRequest = DirectCast(WebRequest.Create(URL), HttpWebRequest) request.Method = "GET" request.Accept = "image/*" Dim response As HttpWebResponse = DirectCast(request.GetResponse(), HttpWebResponse) Dim s As Stream = response.GetResponseStream() Dim bmp As New Bitmap(s) Width = bmp.Width Height = bmp.Height

As more and more mobile OSes are released, that means apps have to developed for more and more platforms; multiplying the workload and the cost to both create and maintain any mobile app that you want to be available to anyone. Luckily, the web offers us a more standardized platform. (And before you cite differences in browsers: browsers are free and much easier to change than hardware, and there may be some minor discrepancies but the base technology used for development is still the same across the board). While there are obvious drawbacks (available data connection, bandwidth, integration with device-level features), many of those do not have that great of an impact for a lot of applications or can be circumvented with HTML5 APIs. One hurdle that HTML5 doesn't solve (at least, not that I've seen) is to run a web app in a way that the user experience is the same as if they were running a native app; meaning the removal of the browser chrome (address bar, browser menu,