C
A
T
E
G
O
R
I
E
S

&

R
E
C
E
N
T

SVGs and Browsers

Posted by tigerhawkvok on November 05, 2009 20:15 in computers , programming , websites , internet

First, I realize I missed this week's Tuesday Tetrapod. I'll put up a double-feature next week — but I've been trying to meet a personal deadline and didn't quite have time to give the TT the attention it deserved. So, let me touch a little bit on SVGs and, thus, in a roundabout way, what's been occupying my time.

First, "SVG" stand for "Scalable Vector Graphic". As the image at the right demonstrates, zooming in on raster graphics such as bitmaps, PNGs, or JPGs introduces artifacts. Further, if you want to reuse the image, you cannot scale it beyond a certain resolution. Vector graphics, on the other hand, are very much like text in that their descriptions are essentially plaintext describing how lines arc. The lines arc the same way no matter how zoomed in you are, so they are rendered on the fly by computers. This means that they are infinitely resizeable, and retain fidelity limited only by the physical pixel sizes on your monitor.

Now, the problem is, of course, Internet Explorer. It's not the only problem, but the main one. See, IE doesn't support SVGs at all. Just can't do a thing with them. While Firefox has finally passed IE6 in market share, IE still holds ~65% of the global market (though on technical sites, its market share is closer to 20%). So this was a game-stopper to SVG adoption.

However, in October Google released the SVGWeb library, which is a simple Javascript library that renders SVGs on IE in Flash, and displays them as a Flash document. Suddenly, in one blow, SVG has a nearly universal level of application. If NetApplications is right, a combined implementation has a 98.88% market share penetration. Now, this isn't quite right, as Flash still doesn't support 64-bit browsers, so users of Internet Explorer 64-bit are out in the cold — but most users of 64-bit operating systems, even those that use IE, use the 32-bit version, so that's pretty negligible.

Now, with that hurdle done with, we have a few other hoops to jump through. First, of Gecko, Webkit, and Presto-based browsers (read: Firefox, Safari + Chrome, and Opera), Gecko and Webkit each incompletely support external SVG resources with the two tags that should work, <object> and <img> (Presto properly supports both). Gecko does not support <img> at all, and instead displays the alt-text; Webkit supports <object> but manipulating sizes and such does not work.

Now, I wanted to use an SVG-based logo on my site, and I was fed up with this implementation problem, so I wrote up a simple PHP library to get SVG working conveniently on multiple browsers. Now, to use an SVG, all you have to do is

<?php dispSVG('PATH/TO/FILE.svg'[,'ALTERNATE TEXT',WIDTH_IN_PX,HEIGHT_IN_PX,HTML_ID,HTML_CLASS]); ?>

Where everything in the square brackets is optional (do note, however, that if no height or width is specified IE will default to 100px by 100px). So, for example, on this implementation test page, the logo with the yellow background is just in:

	    <div style='background:yellow;width:500px;height:600px;'>
	      <?php dispSVG('assets/logo.svg','logo',450); ?>
	    </div>

That's it. Nice, simple, clean and cross-browser. All you have to do is extract the library to your server in a location, edit the $relative variable in svg.inc if it's not in the root directory, and paste the following into the head of your (X)HTML document:

<?php 
require('PATH/TO/svg.inc'); // edit this path
if(browser_detection('browser')=='ie') echo ""; 
?>

Once you've done that, you're done! Just call dispSVG whenever you want to display an SVG. By giving the ID or class calls a value, you can address your SVG as normal in you CSS. Nice and easy! It's not quite perfect, as CSS background only works with Presto (of course. Go Opera!), but it works for most uses.

Now, all that is because I'm working on creating a site to advertise my website creation and deliver built-to-order computers for customers. The computer building system is almost done, requiring some modification on the last four system types to give configuration options. Then I just need to generate some content for the other pages, and it'll go live!

So, I ask (what readers I have) a favor: Can you please check out the site, and give me any stylistic, functional, or content critiques, reccommendations, or comments you may have? With luck, soon it should have the proper domain http://www.velociraptorsystems.com/!

Google Wave and (no) Internet Explorer

Posted by tigerhawkvok on September 30, 2009 16:21 in news , websites , internet

To follow up on my anti-IE6 post, looks like Google's Wave project won't support IE. To quote Ars:

The developers behind the Wave project struggled to make Wave work properly in Microsoft's browsers, but eventually determined that the effort was futile. Internet Explorer's mediocre JavaScript engine and lack of support for emerging standards simply made the browser impossible to accommodate. In order to use Wave, Internet Explorer users will need to install Chrome Frame.

This isn't even just IE6 — this is all versions of Internet Explorer. Hilarious!

Website Development 2: Killing IE 6

Posted by tigerhawkvok on September 28, 2009 15:41 in websites , internet

Believe it or not, I'm finally following up a little on this 1.5 month old post on web development

So, in my standard course of RSS feeds, I ran acrosss Ars Technica's monthly web usage share post. I noticed a nice by-percentage breakdown of IE market share, and realized that Internet Explorer 6 has about 16% market share.

This is a browser that is eight years old, doesn't render transparent PNGs, doesn't render CSS correctly, has missing CSS selectors, and has 139 security vulnerabilities. Oh, for good measure, a number of Javascript commands outright crash it.

There are entire sites devoted to the push to eliminate IE 6:

Even companies, like 37signals, have phased out IE6 support.

Here's a quick thing you can insert into your own pages (right before </body>) for a subtle but effective notice to upgrade, taken from ie6update.com:

<!--[if IE 6]>
<script type="text/javascript">
	/*Load jQuery if not already loaded*/ if(typeof jQuery == 'undefined'){ document.write("<script type=\"text/javascript\"   src=\"http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js\"></"+"script>"); var __noconflict = true; } 
	var IE6UPDATE_OPTIONS = {
		icons_path: "http://static.ie6update.com/hosted/ie6update/images/"
	}
</script>
<script type="text/javascript" src="http://static.ie6update.com/hosted/ie6update/ie6update.js"></script>
<![endif]-->

It's kind of insane that this browser is still around. Even if you run a small site — enough small sites start popping this up, and you'll get people's attention.

I also have a PHP setup that's more configurable, and if someone wants it, I'll put the code up.

Phylogenies Everywhere

Posted by tigerhawkvok on September 14, 2009 14:36 in computers , evolution , biology , programming , websites , internet

A surprising amount of this weekend was dedicated to working on phylogenies. I updated non-eusuchian crocodylomorphs, avialae through neoaves to at least extant order; minor updates to sauropoda, and an update on sauropterygia.

The site also finally got a long-needed search engine. It's not the most efficient thing in the world, but doing a binary search is essentially useless. I made it modular, so I may still end up seeing how a sort + binary search with preserved keys turns out, or cut out the cruft (change the amount of the document searched).

I finally also added a dirty implementation of tagging. I used the <tt> (teletype) tag and changed its contents to not display (CSS display:none). Thus, tags for an entry can be hidden in this element, and will be read by the search engine, but not displayed.

I also noticed that it was hard to find some of the sources I cited with just name and year — so I've started adding linkouts, DOIs, or ISBNs too all sources provided, to make it easier in the future.

Kind of looks less in writing than it felt like ... but I'm happy with the way it's going.

Website Development

Posted by tigerhawkvok on August 15, 2009 23:50 in computers , websites , internet

There's a degree of subtlty in webwork that is missed, but is particularly noticible when you spend a lot of time designing sites, be it for yourself or for clients. I think that I'll break this down into a few miniposts, to share my ideas on the topic, give a bit of threading through a few posts, and, well, to hopefully bring some ideas out. Right now, my plan is to look at:

  • Code validity
  • Aesthetics vs. Usability
  • Simple engines and security
  • Why I hate Javascript and Flash
  • Website modularity
  • Front-end website interfaces

Which brings us to this first post on code validity. Now, that is a bit of an obscure choice to start with. Really, who cares? The number of sites lacking a Doctype declaration is fairly amazing. People still mix display markup with content markup. What's with all this, well, kvetching about web standards?

Let's start with the doctype declaration. For example, this blog uses (for now, anyway, and valid as of this posting) the XHTML 1.1 Transitional doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

This tells the browser to use this style of interpretation when rendering the markup. In particular, the browser should handle certain not-strictly-OK bits of code, such as <input> tags existing outside of block level elements (that is, elements that occupy a chunk of a webpage instead of being able to exist in-line).

This touches on another aspect of valid code. Different types of elements have different nesting requirements. For example, the tag used to write this paragraph, <p>, is by default a block level element. It occupies a block of a webpage, and cannot have other block-level elements inserted into it, like a second paragraph element, or a <div> element (as a general rule; some elements are special, notably <div> and <table>). A block level element creates a new line when formed.

By contrast, inline elements, such as the anchor tag (<a>, most commonly used for links) are inline elements. They cannot exist outside of block-level elements. This seperation of block and inline level elements simplifies layout design and makes websites render more faithfully across browsers; when this isn't done, the browsers need to make a non-standardized choice about how to seperate these items. Do they form a new line or no? Are the spacings different? Does it implicitly form another block level element until closed? And so on.

The next item is a bit of a change from the old style of coding back in the 90's and early 2000's. It used to be that you could see bits of code like this:

<p><font color='green' type='comic sans ms'>Whee green!</font></p>

Now, you would see one of these:

<p class='greenpara'>Whee green!</p>
<p id='greenpara'>Whee green!</p>
<p style='color:green;font-family:comic sans ms,segoe print,pristina;'>Whee green!</p>

Which would all render

Whee green!

So what is the difference? In the first example, the code's style information was a different element, both block and inline, that would live with the content markup. However, in the latter three, the content is just the paragraph element, and the styling information is referenced by a class identifier (can apply to any number of items with that class), and ID (just one item), or a different style of code, applied to the entire paragraph element. This is known as CSS, or Cascading Style Sheets. This means you can actually have multiple styles for a page, as well demonstrated by the CSS zen garden, which has one page with multiple stylesheets to give it vastly different stytles. Less amazingly snazzy ways of seeing the same thing can be seen in the beta site I had done (wow, has it been a year?) for the UCMP. Over here, you see the full site in all it's CSS glory; over here you see the site with the external CSS sheet stripped out, and only inline elements remaining, and here an alternate color scheme that never got off the ground (and is thus incomplete).

Part of the beauty of CSS was that it allowed stylesheets to be moved externally to other files, and then referenced by <link> or <style> elements. This means the one stylesheet could be used by multiple pages, and be updated seperately and have it reflected across all pages simultaneously. For example, you can see the layout code for this site here.

If you want to check out the validity of your code, you should check out http://validator.w3.org/ — at the time of this writing, the front page (and all the posts on it) have been marked up correctly and return a valid page.

Till the next entry ...