We’ve been watching over the last little while as the Humanized crew has leveraged their experience with Enso to create Ubiquity, an in-development command-line interface for the browser. But what about folks who aren’t as enamored with their keyboard as they are with their mouse?
Aza Raskin has recently published an interesting video showing how Ubiquity could work with just a mouse. It centers around this little nib which is barely visible when text is selected:
Hover over it, and it becomes more opaque:
Click on it, and a side-panel appears with the applicable Ubiquity commands:
This code creates a protocol handler for www.example.com that makes mailto links direct the user to the www.example.com web application, inserting the link into the URL given replacing the %s value. The final argument is the title of the protocol handler to present to the user.
There are obviously security limitations around this:
Note: Web sites may only register protocol handlers for themselves. For security reasons, it's not possible for an extension or web site to register protocol handlers targeting other sites...The URL template supplied when registering must be of the same domain as the webpage attempting to perform the registration or the registration will fail. For example, http://example.com/homepage.html can register a protocol handler for http://example.com/handle_mailto/%s, but not for http://example.org/handle_mailto/%s.
The user will be prompted on whether they want to allow this protocol handler:
Now, when the user clicks on a link that has a registered protocol handler, they will be prompted on how to work with it:
Firefox 3.1 now includes support for the HTML 5 video and audio tags. A nice new article just went up on using these on the Mozilla Developer portal. Firefox 3.1 currently supports the Ogg format, but other formats are being discussed for future support.
var v = document.getElementsByTagName("video")[0];
v.play();
There are a whole slew of events that you can listen to as well (there are 22!), so that you can attach behavior and update your UI based on different media events:
I've been delving back into the gnarly world of XML on the web lately and surprised to see what's changed and what hasn't. Coming up to speed on what's new in this part of the Ajaxian world, I found a great article from IBM DeveloperWorks on what Firefox 3 brings to the table with XML. Some highlights:
"Firefox 3 introduces one huge improvement to basic XML parsing. In the past on Mozilla browsers, parsing an XML document was synchronous, blocking all operations on the document until it was fully loaded...To the user, this meant he starts to see how a Web page shaped up before the browser had completely processed the page; on the other hand, with XML documents the user saw nothing at all until it was completely parsed...In Firefox 3.0, construction of the XML content model is incremental, much as it is for HTML. This will make a big difference for practical use of XML on the Web."
This is a good thing, since it means using XML on the web should be much faster as it is incrementally displayed now rather than appearing all at once at the end.
Another nice new feature in Firefox 3 is improved XSLT support (XSLT is a standard way to transform one XML document into another one, such as into HTML to display in the browser):
"The biggest win for those looking to use XSLT in Firefox is support for EXSLT, a set of XSLT extensions developed and sanctioned by the XSLT community and supported in many other XSLT processors. Firefox 3.0 adds support for a large subset of EXSLT, starting with the node-set function, an important workaround for XSLT 1.0's most severe limitation. EXSLT is organized into modules, each of which defines several extension functions and elements."
Lots of new EXSLT modules are now supported (including regular expressions!), which should make writing XSLT stylesheets much easier and more productive.
Even though XML on the web hasn't had the best success, it's still an important tool in the Ajax developers toolchain, especially those aspects that are cross-browser. Most developers don't realize they can do XPath, XSLT, advanced XML, and more cross-browser; while you don't usually need this power, sometimes its the perfect tool to solve a tough problem.
Finally, one of the things that would have helped XML on the web gain more adoption would have been to make working with namespaces easier. I stumbled across a great editorial today that I didn't see reported on how this could have been done. For example, why didn't they just standardize on prefixes like 'svg:' instead of long URLs? Its probably too late (though the HTML 5 working group is leaning in some of these directions), but the ideas in here are good:
"The decision to identify XML namespaces with URIs was an architectural mistake that has caused much suffering for XML users and needless complexity for XML tools. Removing namespace URIs altogether and simply using namespace prefixes to identify namespaces would make it easier for people as well as software to read, write, and process XML."
Isn't it great that a browser point release these days adds so many features? We are starting to see this from Firefox, Opera, WebKit and others, and it is exciting!
The labs team got Geode out there, and quickly we have seen the addition of the W3C Geolocation API added to the Firefox core. I can test Where Are You with a native implementation.
@font-face
WebKit lead with their @font-face implementation, and getting browser #2 to support it is huge. Now you can load up a font using same-origin rules via simple CSS:
We now have lots of examples testing out the video and audio tags with support for both OGG Theora and OGG Vorbis.
This is something that the Web really needs to work out. The codec game is far from Open, and with native support we get to do cool things such as integrating media with canvas, svg, and plain old HTML. Take a video, add transparency, and skew it a little.... and add an overlay message.
XHR Updates
XHR Progress Notification
We’ve added a better way to get progress notifications for XML HTTP Requests. We’ve implemented the W3C Draft Spec on progress events. In Firefox 3 the events available on the XHR object were progress, uploadprogress, load, abort and error. For 3.1 we now support the loadstart, progress, load, abort and error events. (uploadprogress is also supported, but is deprecated.)
We’ve implemented the draft specification for access-control for cross-site requests. Web developers have long wanted to be able to get data from one site on another but same-origin restrictions on many types of requests prevent many developers from mashing up content. This new access control mechanism offers the ability for servers, content and web clients to cooperate to make a lot of new things possible on an opt-in basis. The spec is complex, and support is new, so if you’re interested reading the spec is probably the best thing to do. It contains examples and uses cases.
Fast JavaScript VM
An early version of TraceMonkey is here:
Beta 1 does include TraceMonkey, our super-fast JavaScript engine, but it’s not turned on by default. If you do want to turn it on, go to about:config, set javascript.options.jit.content to True, restart your browser and try it out.
This is an early beta, of course, so there will be issues. Please file bugs if you find sites that don’t work or cause crashes or hangs. The more testing we get, the better it will be when we turn it on.
Phew, good times for browsers == good times for Web developers.
UPDATE
More browser news, Flock 2.0 is out there, providing a very social browsing experience.
The event object contains two properties: .clientRects and .boundingClientRect, both of which refer to the result of the associated DOM methods.
In a nutshell, boundingClientRect gives you a single rectangle encompassing the entire area in which a paint operation could've taken place whereas clientRects gives you a number of rectangles, each encompassing an individual area that was drawn.
There are a substantial number of iPhone apps that tie into the builtin native components such as the camera.
Brad Lassey has been hacking on Fennec (the Mozilla mobile browser) as well as Firefox itself to integrate with camera phones and Webcams alike:
I wrapped a video tag, image and a few buttons in xbl and bound it to <input type=”camera” />. When a user hits a website using this tag, he or she currently will see a live video preview and a “take photo” button. When the user clicks the button, the photo is grabbed from the camera and shown to the user in the image element. The image element and video element are in a deck element so only one is shown at a time. After the photo is taken, there is a button that reads “Take another photo,” in case the user doesn’t like the one they just took. Once the user is satisfied, this element works like any other form element and the file can be uploaded to a web service.
After talking to a few people this should actually be bound to <input type=”file” accept=”image/png”/>. Also, it needs some UI design both for what it looks like in content and for a configuration dialog. Finally, we’ll need to think about security and make sure no one can snap a photo of you when you’re not looking your best.
I kinda like having an input type="camera" myself, to be more explicit. It would be cool if you can get access to the image as data (e.g. the value is data:......). I love it.
This work landed on trunk last week. I’ve also submitted my proposal to the SVG WG for standardization. I hope that they’ll like it; there aren’t many degrees of freedom here, for example there’s no new syntax to decide on, so there’s not much to fight over :-). And it’s good for SVG to be able to use its effects more broadly. We’ll change our implementation to match whatever the WG decides.
Unfortunately we don’t yet support external document references, so the elements describing SVG effects have to live in the same document as the elements to which they’re applied. This limits the usefulness of these effects in regular (non-XHTML) HTML for now. But we’ll fix that so that the effects can live in an external SVG file.
WebKit gets all of the love these days. It's the skinny little brother that gets all of the hot dates. It is easy to think that Gecko is complex, but there is nuance to the tale, and Ars brings that nuance.
After explaining the strengths of WebKit, and the history of Gecko, they move on to notice how much of Gecko has changed:
From a technical perspective, Gecko is now very solid and no longer lags behind WebKit. A testament to the rate at which Gecko has been improving is its newfound viability in the mobile space, where it was practically considered a nonstarter not too long ago. Mozilla clearly has the resources, developer expertise, and community support to take Gecko anywhere that WebKit can go.
We asked Mike Shaver, who is now Mozilla's VP of engineering, to comment on how he views the Gecko/WebKit dichotomy today and why he believes Gecko is still important.
"I have a lot of respect for the WebKit guys, and for the work they've done," he told us in an e-mail. "The web is better because they're around and pushing hard, and Mozilla itself is better from the competitive push as well as cooperation ranging from new web standards to plugin interfaces to the nerdiest of implementation discussions."
Although he respects the technical achievements of WebKit, he believes that the WebKit development model and fragmentation in the WebKit ecosystem would create serious challenges that make it unsuitable for Firefox.
"We're getting a ton of value out of a unified engine for all our projects, from desktop to device and xulrunner to Thunderbird. If you look at the WebKit landscape right now, you see a lot of different projects there and it's not clear how or if they'll converge," he wrote. "We'd obviously need to hack WebKit pretty hard to adapt it to our needs, and it's not likely that adding another fast-moving variant to that mix would be helpful to anyone, least of all WebKit! We learned about fork maintenance and integration the hard way (and had to learn it a couple of times, to be honest), so that's not trouble that we want to borrow."
I admit that I used to think it would be good for Mozilla to get behind WebKit, and port XUL on top of it. With Firefox 3 they proved that they can change code under the hood and be productive. Having the two systems enables competition, and can only be a good thing for the Web right now.
One example of Mozilla moving faster these days is the Firefox 3.1 alpha launch which has Gecko 1.9.1 and the following features:
If you’ve been following the Gecko 1.9.1 development since it started then you’re probably already aware of, and possibly already taking advantage of, these CSS properties that I implemented but haven’t talked about yet (this web-tech blog really is a great idea!). They are in Alpha 1, but for maximum stability regarding them you should wait until Alpha 2 comes very shortly. I am, of course, talking about CSS3 text-shadow, box-shadow and column-rule.
(I would’ve liked to include an example in this post, but Wordpress doesn’t seem to like “strange” CSS properties)
Text shadows were in CSS2, but were dropped in CSS2.1 due to lack of implementations; but it’s slowly making a comeback! That’s why the -moz prefix is not necessary for text-shadow, but is needed for the other two (-moz-box-shadow and -moz-column-rule). To see some very creative uses of this property check out this web page. Another cool thing is that this property plays nicely with the “contenteditable” attribute, so you can make a text editor with flickering flames behind your text. Who said Silverlight was needed for pretty RIA’s?
Box shadow is really nice, you can apply a shadow to almost any arbitrary element in your web page, thus easily giving your web app an extra bit of beauty. We also support the multiple shadows feature for both text and box shadows. Column rule allows you to draw lines between the gaps that separate columns if you are using CSS3 columns. It takes exactly the same syntax as a border side (border-top, etc), and pretty much completes our support for CSS3 columns functionality-wise.
This post comes on the back of CSS word wrap support (e.g. word-wrap: break-word;), CSS 2.1 generated content (e.g. tr::before { display:table-cell; content:"First cell"; }), and more.
Aza Raskin and the Mozilla Labs team have launched Ubiquity the command line tool that they have been talking about for awhile.
Ubiquity is "experiment into connecting the Web with language in an attempt to find new user interfaces that could make it possible for everyone to do common Web tasks more quickly and easily."
The overall goals of Ubiquity are to explore how best to:
Empower users to control the web browser with language-based instructions. (With search, users type what they want to find. With Ubiquity, they type what they want to do.)
Enable on-demand, user-generated mashups with existing open Web APIs. (In other words, allowing everyone–not just Web developers–to remix the Web so it fits their needs, no matter what page they are on, or what they are doing.)
Use Trust networks and social constructs to balance security with ease of extensibility.
Extend the browser functionality easily.
The screencast explains more:
What is cool about the system, is that it is a platform. If you fancy adding a new command, it is as easy as the following 'date' command:
, Firefox
