The Google Maps Javascript API Version 2 has been officially deprecated as of May 19, 2010. The V2 API will continue to work as per our deprecation policy, but we encourage you to migrate your code to version 3 of the Maps Javascript API.
Google will issue an announcement if the current version of the Service will be deprecated. For a period of 3 years after an announcement (the “Deprecation Period”), Google will use commercially reasonable efforts to continue to operate the Deprecated Version of the Service and to respond to problems with the Deprecated Version of the Service deemed by Google in its discretion to be critical. During the Deprecation Period, no new features will be added to the Deprecated Version of the Service.
OK; this was another one of those WTF-CSS moments after spending a couple of hours scratching heads trying anything and everything.
A website currently in production; we’re doing some X-browser testing and a very odd scenario kept occurring in IE7 only. The website looked beautiful in everything except IE7 (usually it’s IE6 we’re cursing at). For some reason DOM elements kept ‘vanishing’ even though they were there!, there in the HTML. We thought we were going mad!
A cursory glance at the ‘vanishing’ elements in the IE Developer Toolbar > DOM Inspector highlighted their “hasLayout” property, and it’s “-1″ value (not set) which led me to a solution, but I’m still scratching my head as to why!?
Firstly the solution in-case anyone has Google’d looking for the same answer:
For IE7 ONLY, to make your vanishing elements magically re-appear, applying ONE (or more) of the following properties to the ‘vanishing’ elements will force those DOM elements to have a “hasLayout” value of “1″ (true), in affect forcing them to render. HOWEVER in typical Microsoft fashion some of these CSS attributes have UNIQUE values that really do not stick to any x-browser standard. (Typical M$! *evil*).
display:inline-block
height:{any value}
float:left (or) right
position: absolute
width: {any value}
-ms-writing-mode: tb-rl
zoom: {any value}
Secondly, the theory for anyone interested:
From what I can make out; and I’ll probably add to this as I found out more, but from what I can make out, under a given set of circumstances absolutely positioned elements near floated elements will ’cause them to ‘disappear’. This article (http://www.brunildo.org/test/IE_raf3.html) exploring this scenario led me to another article (http://msdn.microsoft.com/en-us/library/ms533776%28VS.85%29.aspx) at the Microsoft Developer Network (MSDN) and ultimately a solution. By forcing hasLayout to 1 you’re telling IE that this element hasLayout, has form, shape and substance. In other words don’t hide the damn thing! I’d definitely welcome any comments as to WHY this happens because it’s one of those incidents where the solution works but you don’t quite understand the underlying principals behind it.
UPDATE Jun 4th, 2010:Apple have put together their own showcase demonstrating the power of HTML5 (Safari needed) http://www.apple.com/html5/
UPDATE Apr 8th, 2010: You have got to love Google! Give their engineers some “20% time” and see what they do with HTML5; the <canvas> tag, some WebGL (Warning: cutting-edge browser required). Mind blowing. Read more: http://code.google.com/p/quake2-gwt-port/
NOTE: To preview some of the links included in this article you will need to be on an HTML5/SVG compliant browser. i.e. Webkit based (Chrome, Safari) or Gecko (Firefox 3.5+), you’re on IE (Trident) ? Don’t even bother clicking on the links !
With a lot of recent articles proclaiming that, with the imminent release of HTML5 will also come the death of Flash, I figured I’d start doing some reading around. I know the W3C are still drafting HTML5 standards (Version as of Mar 4th, 2010), but it’s close. Very close. Browsers are hedging their bets on what will be included and slowly we’re seeing adoption of some core HTML5 spec’s, most notably in Webkit based browsers (Chrome and Safari).
For me; the introduction of HTML5 will introduce many new HTML tags, some exciting new Javascript events (like native drag and drop!), but I think, of ALL of these features none will be as widely adopted, or as expansive, as the humble <canvas> tag.
A container, a Flash ’stage’ if you will for the sake of analogies. To quote:
With recent Javascript library developments from Mootools, jQuery, YUI, even the BBC’s own “Glow!” (to name just a few) we are seeing next generation Javascript (or if we’re being trendy “Web2.0″) that rivals some of Flash’s mainstream tweening capabilities. DOM and JavaScript Library mash-ups have exposed a new era of creativity. SEO compliant interfaces that lift content into a new dimension.
That humble canvas tag is going to extend that concept way beyond what I’d previously imagined possible. SVG (Scalable Vector Graphic) mash-ups created with Inkscape for example. Literally being able to compose SVG output that can be sucked straight into a canvas with CAKE (not to be confused with a well known MVC framework for PHP), but rather the Canvas Animation Kit Experiment, already developing next-NEXT generation Javascript frameworks to compliment HTML5 canvas painting.
Just think of SVG definitions as a cross between HTML imagemap’s and XML, but on steroids! The ability to define glyphs for typographic freedom. No more font constraints. Typographic freedom ? (We’ll see how the font houses (Adobe)) feel about that!
Vector graphics and the canvas tag. Enough to ‘kill’ Flash? We’ll see, but enough with the waffle. Show me some examples! Here you go, but remember; for optimum output view these on the latest Webkit based (support for HTML and SVG) browsers (Chrome/Safari).
Google have taken SVG graphics and the capabilities of the canvas tag to new heights. With the installation of their O3D plugin it is possible to animate 3D objects directly within the browser. This is an absolutely amazing demo’ and with just a little bit of imagination the possibilities that this can lead to are endless!
