Internet Explorer and Inkscape SVGs

Vector graphics are slowly supplementing bitmap images and have become a cornerstone in modern web design for an amazingly simple reason: because they are composed of mathematically defined coordinated rather that a fixed number of pixels, they scale up and down with no loss in quality. This fact makes them great for responsive web design (a single site whose layout scales and reflows according to screen size, mostly removing the need for a separate site for mobile devices). Slowly but surely, vector graphics are being used in place of bitmapped buttons, small simple images, and layout elements (such as a navigation bar) in websites. Already it makes more sense in the corporate world to design a logo in vector instead of bitmap so as to scale it for any advertisement size and layout, the same with many mobile applications too, so website designers are now adopting this trend fueled by the explosion of smart phones, touchscreens, and tablets of varying sizes.

Thankfully, web browsers and website frameworks have noticed this trend and have done their best to support vector graphics, mainly in the form of SVG files, which are either saved as an external file and loading using an <img> tag or through inlining the file (much like using a Base64 encoded bitmap image) using the <svg> tag. Today, any web designer can create a SVG vector image using any vector graphic creator, such as Adobe Illustrator or Inkscape, add it to a website, and have it rendered and ready for scaling in every modern web browser.

That is, except for Internet Explorer.

For as long as website design has been seriously considered, Internet Explorer has been a major force to be reckoned with, either for good or bad. As the browser with the most market share, developers are often placed in an all-or-nothing support situation, with some degree of support being performed most of the time. Further complicating the matter is the various versions of IE in use, mainly ranging from IE 8 to the newest IE 11. While IE 10 and 11 are drastically improved compared to the last few versions, there are still plenty of standards compliance issues designers and developers alike must workaround without crippling more compliant browsers. One such IE issue that must be dealt with even in the newest version is (surprise!) SVG support. However, the issue is not as simple as it sounds. Although Internet Explorer supports SVG graphics, it has a beef with SVGs exported from Inkscape (but not from other Vector graphic editors), even when using the “Plain SVG” Save As option.

In this post, we are going to be exploring this strange scenario, why it happens, and how we can avoid having Internet Explorer choke on our beloved vector graphics. A live demo of the issue at hand is available at You will need to use Internet Explorer to view this. However, I have provided screenshots of the issue, though, as it makes everything much easier to comprehend when you can see what is happening (and making up for the Impossible, unless you know how cross-browser support). ;).

Continue reading “Internet Explorer and Inkscape SVGs”


Web Coding Style Guides

There is nothing like well written code. I am not talking about the efficient type either. I mean the clean, well-formatted, neat looking code. Code that looks the same no matter what environment it is displayed in. Clean code, both efficient and neat, makes the world go ’round.

However, how do you know what is considered clean code? What is the baseline you are to compare your code to? The answer lie in style guides. Every programming language has them, both for the code you write and the code that powers the language. By reading and following your chosen language’s style guide, you can be sure your code is a piece of code beauty (that does not mean ASCII art either 😛 ). In the world of HTML, CSS, and JavaScript, there is no single style guide to follow but rather many to choose from. Although there are a few predominant ones and they usually contain some of the same suggestions, it is up to you to choose which one to follow. Furthermore, there may be a few rules from one you like from guide X but overall prefer guide Y. You may also have personal preferences not listed. All the decisions can become confusing.

This is where this post comes in. I am going to show off a few of the most well-known style guides and provide some tips on handling it all.

Are you in the reading mode? I hope so, because this quest for cleaner code is going to be long. Forward, march!

Note: this post is not directly about discussing code styles you, I, or the programmer next to you uses. While I will briefly mention some of my coding style, the primary objective of this installment is to explore some of the HTML, CSS, and JavaScript style guides out there and help you develop your own personal guidelines. Discussing personal style guides is beyond the scope of this post. 😉 In addition, the words “rules” and “guidelines” and their variations are used synonymously to mean “suggested practice”, per the aforementioned purpose of this document.

Continue reading “Web Coding Style Guides”

Setting Up a Python-powered Localhost

When designing/developing a website, normally you’ll setup a local server (known as a localhost partly because of the http://localhost:8000 URL used to access it) to test the code and configuration over an HTTP connection to ensure everything runs correctly. However, doing so can be quite hard. I’ve previously used XAMPP for a localhost, but that required me to download a huge installer or Zip archive (granted, there were a lot of content), run the services, then either copy my project to a special folder (either manually or through a script) or work out of that folder. After doing that for a day’s work, I decided against that option. Adobe Brackets has a Live Development feature that kinda duplicates that feature, but it currently requires Chrome. Isn’t there another, simpler way to setup a localhost to test my site?

Apparently there is, and is uses something I already have installed: Python!

Continue reading “Setting Up a Python-powered Localhost”

Filter Out Unwanted Files – Blender 2.6 API

Many of you are familiar with my work on the LDR Importer for Blender, how I adopted it am now the maintainer of the script, and how there are now two other developers working on it, not counting contributors.

In v1.1, the script receive some notable updates by me, rioforce, and the other developers. One of the changes made is the ability to filter out any non-LDraw models from the file browser. This has been on my wish list for a while, but I have not been able to find a simple implementation or documentation on how to do this.
Continue reading “Filter Out Unwanted Files – Blender 2.6 API”

LDR Importer Version 1.1.5 – Standards

LDR Importer v1.1.5 was released today. Thanks to MinnieTheMoocher‘s sharp eye, this intermediate release’s change log is only artificially small. The patches that went into the changes were actually quite large. Thanks to MinnieTheMoocher, the entire library layout should be supported, including unofficial, p/48, and the new p/8 folders. In addition, support for high-res and low-res primitives are supported, again thanks to MinnieTheMoocher. It was these patches that brought LDR Importer in better compliance with the LDraw Parts Library that gained this release the codename Standards.

This is an intermediate release because the development team is planning on performing major refactoring on the script in v1.2, and MinnieTheMoocher’s reports pushed back those plans (for the better, mind you). As it stands right now, we should begin the process in February. The plan of action is still under development.

You can get the newest release from GitHub!


I wish Python had…

Yes, there are plenty of wish lists for Python already, but I’m going to make another one.

I wish Python had a switch block like JavaScript does. switch drastically reduces the number of lines, conditions, and effort of setting up multiple if, else if, and else blocks, and in the process makes the code more legible and reduces confusion with all those braces.

You can see how nice the switch block is for yourself in the following examples. First we will use switch

var sweet = "Cake";
switch (sweet) {
    case "Candy":
        console.log("Candy is dandy.");
    case "Pie":
        console.log("Portal got it wrong. Pie is actually a lie.");
        console.log("Cake! My favorite! :D");

… and now for if, else if, and else

var sweet = "Cake";

if (sweet ==="Candy") {
    console.log("Candy is dandy.");
} else if (sweet === "Pie") {
    console.log("Portal got it wrong. Pie is actually a lie.");
} else {
    console.log("Cake! My favorite! :D");

See how much nicer that is? It is that typeof simplicity I would like to see in Python’s admittedly already simple syntax.

However, I guess I can’t complain too much. Python does not deal with braces (run from __future__ import braces for yourself to see why), so a layer of complexity is removed, allowing if, elif, and elseblocks to be very small, even if I must set up some conditions.

from __future__ import print_function
sweet = "Cake"
if sweet == "Candy":
    print("Candy is dandy.")
elif sweet == "Pie":
    print("Portal got it wrong. Pie is actually a lie.")
    print("Cake! My favorite! :D")

So much for my wish list. 😛