Tag: WHATWG

Categories
Google Web Development

Google Is Moving Away From Google Gears

LA Times is reporting:

“We are excited that much of the technology in Gears, including offline support and geolocation APIs, are being incorporated into the HTML5 spec as an open standard supported across browsers, and see that as the logical next step for developers looking to include these features in their websites,” wrote a Google spokesman in an e-mail.

I complained a while back that things seemed too fragmented. To date I’ve been pretty leery of things because I wouldn’t want to support two competing methods or require users to either download Google Gears or use a browser that supports cutting edge technologies. It’s either too much effort and code footprint, or too much effort from the user perspective to download another binary.

A few Google folks replied to my earlier blog post and noted that they fully intended to work towards convergence. I’m glad it’s finally becoming a reality. I hope Google Gears will continue to be developed for the purpose of filling in missing functionality for certain browsers that tend to fall behind and simply let the browser take over if and when it eventually supports that functionality. That would create a consistent environment across platforms and browsers.

Categories
Mozilla Web Development

Rebreaking The Web

It’s happening again. Once upon a time, browser vendors started adding their own features without consulting with each other and agreeing upon standards. What they created was a giant mess of inconsistencies across browsers and platforms that is still in effect today. Ask any web developer and they can tell you of the pains that they have suffered trying to make seemingly trivial things work everywhere consistently. It’s no easy task. Before IE 7, even an ajax required something along the lines of:

var httpRequest;
if (window.XMLHttpRequest) { // Mozilla, Safari, …
    httpRequest = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE
    httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}

That’s right, IE 6 didn’t support the native xmlHttpRequest object (more here). This is just one of many examples in JavaScript and CSS. document.all anyone?

The end result of this problem became to be known as the “Web Standards” movement. Simply put it’s an idea that code should follow a standard that results in consistent output across all browsers on various platforms. Write once, run anywhere. While it’s taken years for this to manifest, it’s slowly become a reality. Firefox, Safari, Opera have fairly consistent rendering (at least in comparison to the mess of just a few years ago on the browser scene. IE 6 was fairly poor in terms of modern web development, but IE 7 made progress, and IE 8 is Microsoft’s greatest effort to date to bring their browser up to speed.

Continue reading “Rebreaking The Web”
Categories
Google Mozilla Web Development

Google Gears

In case you were wondering what Google Gears meant to the planned support for Offline Web Applications in Firefox 3.0, here’s an article you may be interested in. No definitive answers, but does mention the possibility of combining ideas.

Google Gears is pretty cool, but I’d be much more comfortable if Google submitted the API as part of WHATWG and it were standardized. Google Gears would then be the way to use it without a browser having native support. I personally don’t like the idea of competing implementations.

Categories
Google Mozilla

Ian Hickson goes to Google

Ian Hickson has gone to Google. It’s great to see Google picking up great minds like him. WHATWG is clearly something Google should have an interest in. Considering how Google seems to be pushing the Web into this “Web 2.0” (yes it is a bullshtick term from the geeky technical perspective, but it’s relevant from the business side of things). WHATWG is clearly moves in that direction.

Categories
Apple

Apple and the Internet

Anyone still not reading David Hyatt’s Blog should start doing so ASAP. If you read this blog, and find anything relevant, you will most definitely find his relevant. He’s a browser guru with his hand in many things. A definite site to bookmark. A few comments on this whole Safari/Dashboard thing…

Personally, I wish it were done in XUL, and XUL were fully implemented on Mac OS X via Web Kit. Would have been really neat. Personally I find XUL based interfaces to feel quite natural at this point. Even Mac OS X’s Firefox is feeling good. With Apple’s concentration it would have been great. But they did go with the second best (and still good) option of HTML, with lots of standards support. And that’s still a good solution, though not my personal favorite.

I’d also like to make note of a good quote here:

We have a phrase we like to use here on the Safari team, and that’s “real-world standards compliance.” What that means is that where possible we attempt to be fully compatible with the W3C standards, but we also want to support the real-world standards, i.e., extensions that for better or worse have become de facto standards. If you really do believe we should not have implemented contenteditable, then you are simply out of touch with reality.

Hyatt does say something that makes me feel really comfortable with Apple’s approach on standards:

finally we have submitted all of our extensions to the WHAT-WG for review. The slider in particular is already in the Web Forms draft. It is our hope that these HTML extensions will ultimately be standardized by a working group, but I wanted to emphasize that we are working with other browser vendors such as Opera and Mozilla to ensure that these extensions are implementable in those browsers and that these extensions can be standardized. We are not simply off “doing our own thing.”

This I’d really like to see happen. I’d ideally like to see these things work on multiple browsers, just like the new plugin system coming around. Perhaps Mozilla can be setup to allow these new Widgets to work? Would be nice to see Apple, Mozilla team up.

Lastly, regarding namespace…

Webkit is looking to use:

http://www.apple.com/2004/xhtml-extended/

IBM adapts HTML and uses:

http://www.ibm.com/data/dtd/v11/ibmxhtml1-transitional.dtd

I kind of perfer the /dtd/ and have a documented DTD available, so my ideal solution would be:

http://www.apple.com/dtd/1.0/xhtml-extended.dtd/

holding the format dtd/version/item.

Just my $0.02.