It also works in IE6, but needs some additional styling. But as we do not support IE6 anymore ( read this post: No more IE6 support ) we didn’t supply the CSS needed, so you are on your own if you plan to use it on this outdated monster.

The mootools dropdown menu demo can be found here: mootools drop down menu – any comments highly welcome.

IE6 is a nuisance for any web developer, and although Microsoft released already 2 successors, namely IE7 and IE8, many users still browse the web with this old, insecure and slow browser. As a direct consequence of this, Google now stops supporting this browser.

Google sets the requirements for successfully running their apps – namely, only newer browsers are supported, which are Google Chrome 3.0, IE7, Firefox 3.0 and Safari 3.0.

If this trend continues, web developers all around the globe could get into the position to not having to code for the IE6 anymore, easing the process of creating websites, lowering production time and thus costs, which in the end is a major advantage for every customer.

artViper welcomes this decision, and has stopped supporting IE6 a while ago, as you can read in this post. IE6 is only supported by direct request of clients. It’s about time that administrators, companies with stone-age old scripts stop using IE6, take some money in their hands and update their systems. It’s not just for the web developers around the world, it makes browsing at least a bit more secure if people stop using this dinosaur.

http://85.25.9.83/artviper.php

The parameters stay the same, no changes on that so far. Please change your scripts accordingly. Thanks.

We will post the new URL in our blog here – please make sure to check back.

Thank you

Simply enter your URL, ( scroll down to see the result ) and the color palette used on the particular page will be converted a) to a visual output on the screen and b) creates a file you can use in Photoshop. You’ll have the color palette ready to use in your project in seconds. No more guessing around, what color value this or that website has!

Check it out at mooColorFinder

As the name suggests, the system is based on a graph theory database. With CREATE TYPE generated classes can inherit from other classes. Inside these classes, forwardreferences and backreferences can be more easily requested as with SQL. The language used is called GQL and orients itself on common languages like mySQL.

An application area of GraphDB are for example social networks, according to sones, making “Who knows whom” relationships much faster than with the previously used technique.

Objects can be versioned and stored in different “Editions”. For example, a document available as Open Office and a PDF file. GraphDB used to store the objects its own file system that can use either a separate partition on the hard disk or a file.

Interested parties can test the database via XML web service or REST. A standalone version is planned for 2010. NET and Java interfaces are available.

sones

The Javascript library allows the use of SVG Web SVG graphics in browsers that do not support SVG directly. Under the code name “Gelatinous Cube” the developers have now released a new version which fixes some problems.

While many current browser support vector graphics format developed by the W3C SVG (Scalable Vector Graphics), users with older browsers or Internet Explorer are still locked out from SVG. SVG Web seeks to remedy this situation and ensure that SVG graphics are displayed in browsers that do not bring with SVG support.

The approximately 60 Kbytes large Javascript library needs only to be inserted into a webpage. If the browser supports SVG, the graphics are displayed with the native SVG support. Lack of SVG support will force the library to make use of Flash for displaying vector graphics.

SVG Web is available under the Apache License 2.0 and is on http://code.google.com/p/svgweb for download.

Unfortunately, HTTP was not particularly designed for latency. Furthermore, the web pages transmitted today are significantly different from web pages 10 years ago such and demand improvements to HTTP that could not have been anticipated when HTTP was developed. The following are some of the features of HTTP that inhibit optimal performance:

• * Single request per connection. Because HTTP can only fetch one resource at a time (HTTP pipelining helps, but still enforces only a FIFO queue), a server delay of 500 ms prevents reuse of the TCP channel for additional requests. Browsers work around this problem by using multiple connections. Since 2008, most browsers have finally moved from 2 connections per domain to 6.
• * Exclusively client-initiated requests. In HTTP, only the client can initiate a request. Even if the server knows the client needs a resource, it has no mechanism to inform the client and must instead wait to receive a request for the resource from the client.
• * Uncompressed request and response headers. Request headers today vary in size from ~200 bytes to over 2KB. As applications use more cookies and user agents expand features, typical header sizes of 700-800 bytes is common. For modems or ADSL connections, in which the uplink bandwidth is fairly low, this latency can be significant. Reducing the data in headers could directly improve the serialization latency to send requests.
• * Redundant headers. In addition, several headers are repeatedly sent across requests on the same channel. However, headers such as the User-Agent, Host, and Accept* are generally static and do not need to be resent.
• * Optional data compression. HTTP uses optional compression encodings for data. Content should always be sent in a compressed format.

You can read the full entry here: SPDY whitepaper