Svoboda | Graniru | BBC Russia | Golosameriki | Facebook

opensource.google.com

Menu
Showing posts with label HTML5. Show all posts
Showing posts with label HTML5. Show all posts

Gumbo: A C library for parsing HTML

Tuesday, August 13, 2013

We're pleased to announce the open source release of the Gumbo HTML parser, a C implementation of the HTML5 parsing algorithm.

One of the big accomplishments of the HTML5 standard was to standardize the HTML parsing algorithm, so that all browsers see the same HTML document in the same way. So far, most implementations of this algorithm have either been tied to specific browsers or rendering engines, or they've been written in specific scripting languages. This makes it hard to write quick one-off tools to manipulate and cleanup HTML if you don't happen to be working in a language that already has an HTML5-compatible parsing library.

Gumbo seeks to provide a simple library that can serve as a basic building block for linters, refactoring tools, templating languages, page analysis, and other small programs that need to manipulate HTML. It's written in pure C for ease of interfacing with other languages, and has no outside dependencies. Gumbo was built from the start to support source locations and correlating nodes in the parse tree with positions in the original text.

For more information including download, installation, and usage instructions, please visit the Gumbo project page.

By Jonathan Tang, Search Features team


Celebrating Dart’s birthday with the first release of the Dart SDK

Tuesday, October 16, 2012


Working with a combination of small scripts to create large web apps is no easy task.  This is why a year ago we released a technology preview of Dart, a project that includes a modern language, libraries and tools for building complex web applications. Today, after plowing through thousands of bug reports and feature requests from the web community, a new, more stable and comprehensive version of Dart is now available and ready to use.


Dart is carefully designed so that you can build your web apps without having to choose between static and dynamic languages. With Dart, you can start coding simple scripts on your own and scale seamlessly to building large apps with hundreds of thousands of lines of code.  These complex apps can also be supported by a big team with a significantly reduced debugging and maintenance overhead.

With this first developer-oriented version of the Dart SDK, we’ve made several improvements and added many features:

A faster Dart Virtual Machine that outperforms even V8 on some Octane tests.
A new Dart to JavaScript translator that generates fast and compact output.
An HTML library that works transparently on modern browsers.
A library to interoperate with JavaScript code.
An easy to use editor.
Pub, a new package manager
Dartium, a Chromium build with native Dart support.
A server-side I/O library.
A language specification describing the Dart semantics, including new features.

Over the following months, we will continue to work hard to evolve the SDK, improve Dart’s robustness and performance, and fine-tune the language while maintaining backwards compatibility.

You can download the Dart Editor from dartlang.org. It comes with a copy of the open-source SDK and Dartium. Thanks again for all your feedback - keep it coming.

Posted by Lars Bak, Software Engineer

How the world was open sourced

Wednesday, December 21, 2011


Once in awhile at Google our illustrators get excited about lasers, Morse code, H. G. Wells’s The War of the Worlds – and then come up with beautiful Google doodles that find their way onto our homepage. Sometimes our programmers also get excited and team up with the illustrators, and that’s how we found ourselves with Google doodles celebrating Les Paul’s guitar, Pac-Man, Jules Verne’s bathyscaphe, and even your own customized turkey that you could then share on Google+.

I’m one of those people who is more comfortable with 80 monospaced characters endlessly repeated than with a paintbrush. Earlier this year I worked with Sophia Foster-Dimino from the Google doodle team on a doodle celebrating Stanisław Lem, my favorite sci-fi writer and philosopher.

 

Just like picking the right paintbrush and palette is important for all our doodles, so is figuring out the right technologies and proper user interface for those we want to make interactive. That’s something I’m personally really excited about and that’s why today I wanted to share that excitement and the entire source code of the Stanisław Lem doodle with you – accompanied with an article explaining HTML5 technologies that we used… or didn’t use:


Please note: We are sharing the code of the doodle under the Apache 2.0 License, but the images and animations accompanying the doodle under the Creative Commons BY-NC-SA 3.0 License. The big difference between those two is that the first one allows commercial re-use, whereas the second one forbids it.

So take it for a spin, play with it, and if you do something interesting, find a flaw, or have a comment – let us know at [email protected]. Thanks!

By Marcin Wichary, Senior user experience designer, Chrome

August Penguin 10th annual meeting in Israel

Friday, September 9, 2011

Last month, 300 open source developers gathered in Tel Aviv for the 10th anniversary of August Penguin, the annual open source event in Israel. The event started with a review of activities of Hamakor, an Israeli open source organization that strives to drive open source software in every aspect of our life - in the government, with small-medium business and on the web. The day continued with other open source initiatives, and with prizes for local open source development and innovation, and ended with technical tracks.

Developers from all ages attended the event:

Google provided the event organizers with HTML5 shaped cupcakes, it was a blast!
Speaking of HTML5, there was a very interesting session in the event that talked about cross browser incompatibilities of many of the government websites. It was mentioned that the open source community together with Google will further engage top sites in Israel and promote an open and standardized web.

By Amir Shevat, Google Developer Relations

Introducing the Mobile Bookmark Bubble

Tuesday, September 14, 2010

Today, we’re pleased to announce that we’re open-sourcing the Mobile Bookmark Bubble, a JavaScript library that helps users of your web application bookmark the app to their home screen, just like a native app. We’ve been using this library in several of our own web apps, and hope you’ll find it useful for your users, too.

The bubble, which currently supports iPhone, iPod and iPad devices running iPhone OS 3 and above, slides in at the bottom of the application with instructions for creating the bookmark. The bubble automatically slides back out again after a few seconds if the user does not interact with it. HTML5 local storage is used to prevent the bubble from being shown after the user has dismissed it too many times. The amount of time the bubble remains visible, as well as the number of times the bubble can be dismissed, can be easily configured.

The Mobile Bookmark Bubble is released as an open source project under the Apache license, and is available now on Google Code. The repository includes a small sample application demonstrating how the library can be used. If you’d like to send feedback or have any questions, please see our discussion group. Happy hacking!

By Neil Thomas, Software Engineering Team

Interesting times for Video on the Web

Friday, April 9, 2010

If I told you that Google had helped fund an ARM code optimised version of the Theora video codec, most people’s reaction would be immediately to skip forward to the next blog entry. Audio and video codecs are the classic example of things that no one cares about, until they don’t work.

Ask most computer users what their preferred video codec is and they’ll look at you as if you asked what sort of motor they’d prefer in their washing machine. “We just want it to work!” they say. In this regard, it’s exactly the same for content creators and publishers. Every visitor to a website that can’t view a video is one set of eyeballs less for a message to get through to. It doesn’t matter how clever the advertising is, how much time is spent honing the message or how many clever viral tricks are deployed to attract surfers to the site, the moment the page opens up with a big blank box where the content should be, all that has been in vain.

So, publish video so it plays back on everything

Nice idea - but far from simple to achieve. At the moment there is no standard way to deploy video on the web. Some sites use Flash, but this restricts them to a viewing audience that have Flash players, instantly excluding most phones. Some use embedded Java players, but this restricts you to a viewing audience running on powerful enough devices to be able to decode video and audio in a virtual machine, excluding anything slower than a laptop. Still others rely on embedded native players (such as Windows Media Player), excluding every platform other than the intended one. Finally some sites just offer videos as links and farm the job out to whatever video playing software the user has (hopefully!) installed on his machine.

None of these meets the seamless “it just works” goal - and none of them looks like it will ever do so in future. Like it or not, the profusion of different web access devices out there means that this is only going to get harder and harder. Once it was enough to make sure your video was viewable on both PCs and Macs. Now you have Android, ChromeOS, iPhoneOS, Linux, Maemo, Symbian and umpteen others. Not only that, you have to cope with a range of processing powers, from desktops to laptops, to netbooks, PDAs and phones. The problem is exploding, not shrinking.

Fortunately, there is some good news in the form of HTML 5. This new version of HTML (the basic language used to write webpages) introduces a video element.

This will allow people to write their websites specifying the appearance of videos in a standard way. How the individual browsers choose to implement the playback is then up to them - whether they handle movies themselves or farm them out to embedded/external players is a decision made by the viewer, not forced back onto the content creator. The even better news is that support for this is already arriving - Firefox, Opera, Chrome, and Safari have already rolled out HTML 5 support and other browsers won’t be far behind.

So, problem solved?

Well, sadly, no. Having a consistent way of publishing video is a great start, but there is still the issue of what format to use. There is no “one size fits all”. Are we surfing the site on a phone with a small screen? Or with a netbook? A desktop? Or on our new 150 inch QuadHD 3D LCD TV? Screen size, connection size and processing power all affect the decision here. In the same way that we’ve seen home video quality improve from VHS to DVD to BluRay, video on the web is going to get better and better. And that’s fine: existing web server technologies can tailor the video tags used to the browser/devices in use.

What is clear though, is that we need a baseline to work from - one standard format that (if all else fails) everything can fall back to. This doesn’t need to be the most complex format, or the most advertised format, or even the format with the most companies involved in its creation. All it needs to do is to be available, everywhere. The codec in the frame for this is Ogg Theora, a spin off of the VP3 codec released into the wild by On2 a couple of years ago. It scores quite well on both the quality and compression fronts, standing up respectably against it’s more popular rivals such as MPEG4, while actually being much simpler to decode. The overwhelming feature that makes it stand out from its rivals is the fact it’s free. Really free. Not just “free to use in decoders," or “free to use if you agree to this complicated license agreement," but really, honestly, genuinely, 100% free. The specification for the stream and encoder/decoder source is available for public download and can be freely used/modified by anyone. Theora was designed and is maintained with the overriding goal of avoiding patents. No other codec can come even close to claiming to be as patent or royalty free as Theora can, whilst still holding a candle to the alternatives.

So, what’s missing?

Video decode is a pretty CPU intensive task. In order to fulfill the dream of being able to work on every device some painstaking effort is required. The complexity of Theora is considerably less than that of many of its peers; other codecs often require dedicated hardware in devices to help achieve performance targets, but with careful coding Theora can be made to run without this. In fact, on desktop/laptops realtime decode can be managed by an embedded Java player (such as the excellent free Cortado), enabling video playback on browsers still waiting to have video tag support added. For the increasing range of PDAs, phones, netbooks, web tablets and media players out there though, this isn’t an option. Rather than having typical power hungry desktop processors in, these devices tend to be built using the much more frugal ARM processors. While these have increased in power in leaps and bounds in recent years, they still can’t compare with their larger cousins for raw computational grunt. These ARM based devices represent the single biggest class of devices still needing work for decent Theora playback. Any efficiency savings we can make feed back directly into being able to cope with larger screen sizes or giving longer battery life.

This is where Google's grant comes in - by helping fund the development of TheorARM (a free optimised ARM version of Theora), they are helping to hasten the day when video works everywhere on the web, for everyone. That’s got to be something to be pleased about. And now you can flick forward to the next blog post.

By Robin Watts, Pinknoise Productions Ltd

Web Storage Portability Layer: A Common API for Web Storage

Thursday, May 28, 2009

As discussed in our Google Code Blog post on HTML5 for Gmail Mobile, Google's new version of Gmail for iPhone and Android-powered devices uses the Web Storage Portability Layer (WSPL) to let the same database code run on browsers that provide either Gears or HTML5 structured storage facilities. The WSPL consists of a collection of classes that provide asynchronous transactional access to both Gears and HTML5 databases and can be found on Project Hosting on Google Code.

There are five basic classes:

google.wspl.Statement - A parametrizable SQL statement class

google.wspl.Transaction - Used to execute one or more Statements with ACID properties

google.wspl.ResultSet - Arrays of JavaScript hash objects, where the hash key is the table column name

google.wspl.Database - A connection to the backing database, also provides transaction support

google.wspl.DatabaseFactory - Creates the appropriate HTML5 or Gears database implementation


Also included in the distribution is a simple note-taking application with a persistent database cache built using the WSPL library. This application (along with Gmail mobile for iPhone and Android-powered devices) is an example of the cache pattern for building offline web applications. In the cache pattern, we insert a browser-local cache into the web application to break the synchronous link between user actions in the browser and server-generated responses. Instead, as shown below, we have two data flows. First, entirely local to the device, contents flow from the cache to the UI while changes made by the user update the cache. In the second flow, the cache asynchronously forwards user changes to the web server and receives updates in response.

By using this architectural pattern, a web application can made tolerant of a flaky (or even absent) network connection!

We'll be available at the Developer Sandbox at Google I/O to discuss the cache pattern, HTML5 development and the WSPL library. Check it out! If you have questions or comments, please visit our discussion list.

Dojo Storage

Wednesday, March 12, 2008



The Dojo project is a leading open source Ajax framework for developing advanced web applications in JavaScript. Dojo consists of many modules for powerful cross-browser development, such as modules for offline, modules for graphics, and more. One of these modules is known as Dojo Storage.

Dojo Storage makes it possible to store large amounts of data (hundreds or megabytes of K) on the client-side, way beyond the 4K limit of cookies. Developers are given a simple key/value storage abstraction, similar to a hash table. What makes Dojo Storage unique is that it automatically determines the best way to achieve this. If Google Gears, a small open-source plug-in that teaches current browsers new tricks, is present then this will be used for storage; if the browser supports HTML 5 DOM Storage, such as Firefox 2, then this is used; and finally, if none of the others are available, then a hidden Flash applet is used to store the data permanently. There are even Adobe AIR storage providers (thanks to SitePen and Adobe) if you are running in an AIR environment!

Dojo Storage has been around for a few years. However, when Dojo made the big move to the Dojo 1.0 architecture, the Flash and HTML 5 storage providers broke; plus, new versions of Flash and new browsers made the old design inefficient. I have seriously re-factored the Flash storage system to be much faster and simpler and fixed bugs in the HTML 5 and Gears storage systems. There is now a new storage.js profile build that you can grab and include in your page to easily use Dojo Storage with the three main browser storage providers: Gears, HTML 5, and Flash. The new Dojo Storage will come out as part of the Dojo 1.1 release coming soon.

I've created a screen cast demoing the different storage providers in action:



Enjoy!
.