One of my favorite sources of active mining is that of Peter-Paul Koch digging in to mobile browsers and how they behave. Sponsored by Vodaphone to do a study of various mobile devices and their respective browsers, PPK has been doing some serious analysis of what the landscape looks like.
Armed with a battery of tests he analyzes the various browsers manually (a painstaking task) but it yields some sweet fruit:
He breaks down the results into three areas (note: The results are very much still a work in progress, as noted by PPK, so please be aware of that before making any specific decisions on implementation or usability):
Mobile JavaScript/CSS Tests - These are the most comprehensive tests, analyzing a number of common DOM methods, Ajax, touch events, keyboard events, font styling, and custom events. Scanning the tables of results should be able to give you a pretty good picture of what mobile browsers are like.
Mobile CSS - Covering everything from CSS selectors (new and old) along with basic and advanced styling techniques.
Mobile W3C CSSOM - Covers aspects like screen size, mouse position, document size, and scroll offset.
In general, the results are terribly painful. The majority of the devices and browsers available today are a complete mess. Thankfully smart devices are making solid inroads bringing along good-quality browsers (WebKit-based browsers and Opera Mobile) but it's going to be a while before those devices are widely available.
Peter-Paul gave two follow-up talks on mobile browser testing, at Google and at Yahoo, that are worth watching, for additional details.
A couple months ago, while attending the recent iPhoneDevCamp 2, I had the opportunity to speak with a number of developers who were doing JavaScript development on the iPhone.
One developer, Wayne Pan, showed me this weird bug that he kept encountering: He was using CSS Transforms to change the positioning of some elements that were contained within an iframe - but when he did this the elements would 'jump' outside the iframe and overlay its contents over the parent page.
I asked him to prepare a simple test case for me so that I could explore it further - anything jumping outside of an iframes' confines is a huge no-no in browsers - it could lead to a form of a Clickjacking attack.
I did some more testing - I needed to confirm two things:
Could a CSS transform, in fact, position an element outside of an iframe.
Could one interact with the items that were placed outside the iframe.
I created two tests - one which utilized a link that I wanted to spoof and another that had a password input that I wanted to spoof. Both had the same basic principal: Assume that an iframe on a page (maybe a banner ad?) was malicious and wanted to trick the user into providing information, or visiting a certain page, when they interacted with the element's contents.
The contents of the iframe'd page looked something like this (this is the link spoofing case):
This is what the pages should look like (or look similar to them, at least) in MobileSafari - if the bug did not exist:
But this is what it looked like on the iPhone OS 2.0 (no other WebKit engine was effected):
Note that the iframe banner ad isn't even visible when this bug is in play: The shifted iframe contents have completely overwritten the parent page. The user is oblivious to what is happening: The URL looks correct - and so does the link/password input - but it's all being spoofed by the malicious iframe.
Interaction with the elements yields the spoofed results:
So while it's obviously possible to override the complete pages' contents it's important to note that the contents shifted outside the iframe are not able to be interacted with -- only the contents that still remain within the confines of the iframe boundaries. This makes it an 'imperfect' attack but certainly one that is still very potent. A smart phisher could easily work some magic to trick the user.
I should note that after I discovered all of the above I quickly submitted my findings to the Apple Security team. They deemed it to be very important and asked me to not write about it - which I did.
The other day they finally released iPhone 2.2 which included a fix for my specific issue.
CVE-ID: CVE-2008-4232
Available for: iPhone OS 1.0 through 2.1, iPhone OS for iPod touch 1.1 through 2.1
Impact: Websites with embedded iframe elements may be vulnerable to user interface spoofing
Description: Safari allows an iframe element to display content outside its boundaries, which may lead to user interface spoofing. This update addresses the issue by not allowing iframe elements to display content outside their boundaries. This issue does not affect systems prior to iPhone OS 2.0 or iPhone OS for iPod touch 2.0. Credit to John Resig of Mozilla Corporation for reporting this issue.
It's great to see a fix for this problem come about quickly and efficiently - and if you're still running an old version of the iPhone OS please be sure to upgrade!
Apple, and the WebKit team, have recently proposed two different additions to CSS: CSS Transitions and CSS Animations.
The two specifications are confusingly named - and it's hard to tell what the difference is between them at first glance. However, to put it simply: CSS Transitions are easy to use, while CSS Animations are made for programmers.
CSS Transitions
CSS Transitions provide you with the ability to force CSS property changing to occur smoothly over a period of time, rather than immediately and coarsely.
For example if you were to set elem.style.width = "500px";, and its current width was 100px then the element would, normally, jump up to 500px wide. With a CSS Transition it would smoothly move from 100px to 500px - the full CSS required would look something like this:
This would make it such that any manipulation of that element's width would be done as a smooth transition. Note that no other properties are listed and, thus, are not affected. You can list as many properties as you wish, in a list: "width, heigh, opacity" (for example).
CSS Transitions complement the existing tools that we have for working with CSS from JavaScript. Any changes to a CSS property still work - they just happen much more smoothly.
Of course transitions can also be injected dynamically from JavaScript, like so:
Since you can hook in these custom transitions it makes it possible to use them directly from JavaScript and within frameworks. Which leads to the question: Can the core of JavaScript animation frameworks be replaced with CSS Transitions, if they exist?
We had this discussion recently on the jQuery dev list and one user, Jonah, implemented a quick proof of concept to demonstrate how it CSS Transitions would work within jQuery. He also wrote up a stress test to see how it scaled.
Give the stress test a try in WebKit (or on the iPhone, if you have access to one) and you'll definitely note an increase in animation smoothness - especially when a large number of animations are being run.
So why not just add in the CSS Transition code today?
There are a large number deal-breaking gotchas:
You can't stop an animation that's already running.
You get no feedback as to how the animation is running - only an event callback once it has completed.
There's no way to synchronize multiple animations.
There's no way to specify custom easing functions.
The inability to stop an animation is absolutely killer - and a huge requirement for any JavaScript framework that would be looking to adapt this as part of their code base.
That being said, the current transition code does have its place (namely within iPhone development) so I wouldn't be surprised to see a solid jQuery plugin popup that iPhone devs start to use.
CSS Animations
CSS Animations are a second proposal from Apple/WebKit that embodies a much-more-complex way of doing animations. To give you an idea of the level of power that's provided observe this quote from the proposal:
"Many aspects of the animation can be controlled, including how many times the animation iterates, whether or not it alternates between the begin and end values, and whether or not the animation should be running or paused. An animation can also delay its start time."
The ability to pause animations is crucial - and immediately makes CSS Animations a more-viable candidate for use from JavaScript frameworks.
Here's an example of how you would set up a CSS Animation, from the proposal:
div {
animation-name: 'diagonal-slide';
animation-duration: 5s;
animation-iteration-count: 10; }
@keyframes 'diagonal-slide' {
from { left: 0; top: 0; }
to { left: 100px; top: 100px; } }
CSS Animations also provide a greater number of callbacks (letting you know when an animation has started, every step of the animation, and when it has ended) which can be important for doing animation synchronization.
Although the CSS Animation proposal has a number of things going against it:
Its syntax and usability is far more confusing than that of the, relatively simple, CSS Transitions.
It includes the concept of keyframes - while I'm sure this might be useful for someone I just can't see a large enough benefit for such a large feature.
Honestly, at this point, I'd prefer to see CSS Transitions come around, but with a few additions:
The ability to pause or stop transitions.
Animation start, step, and end callbacks (along with information about how far along the animation is).
The ability to provide a custom JavaScript function which would provide a custom easing function.
#1 and #2 are much more important here - but seeing both of those additions would help to make CSS Transitions actually a viable tool for web developers (not to mention that it would provide the best of both worlds - ease of use for non-framework-using developers and power and control for those using frameworks).
Now I felt that way until seeing this example from the CSS3 Layout spec document:
"a . b . c" /2em ". . . . ." /1em "d . e . f" ". . . . ." /1em "g . h . i" /2em
5em 1em * 1em 10em
I could immediately determine what the template was trying to do and how the document was going to look. Even if it is kind of crazy at first glance I'm dying for something like this to be implemented. To create an equivalent document using the CSS that we have now - or even Tables - would absolutely futile.
Even the syntax isn't that bad when you look at it. When examining the example I can see that there are three significant rows of content (two of which are 2em high and one of which will expand to fill the full height) and two spacer rows (each are 1em high). Thinking about how to implement something like this using normal CSS now makes my mind explode in frustration - especially in cross-browser manner.
So while this templating layout is still, very much, in the pipe dream category (no one will even touch it until IE implements it) I think it has a lot of merit and should be strongly examined - especially beyond the initial shock of the new syntax.
Honestly, this is just a goldmine waiting for some enterprising developer to come along and use the syntax to build a solution that'll work in all current browsers (maybe a server-side, or JavaScript, tool that'll process the template and inject the right style rules using a grid CSS framework).
For the upcoming Firefox 3.1 release a lot of work has been going into improving its CSS support (specifically, in relation to the CSS 3 specification).
One areas that have received solid implementations is that of border-image. This is a new CSS 3 module that makes the exact slicing of images (and their positioning around an element) quite easy.
The most obvious use case for them exists in constructing beautiful scalable buttons. And there is, perhaps, no better use case than the one provided by the iui library: replicating portions of the iPhone user interface in a pure-CSS manner.
Here are two examples from the iui library (slightly tweaked to support both WebKit's and Mozilla's implementations of border-image).
The premise behind border-image is complex, but easy to learn. When used in the manner shown above you are, effectively, providing slice offsets into the provided image - telling the browser how to position the slices.
For example the 5s in the border-width and border-image indicate that there should be a 5px-wide border on the left and right of the button. The contents of the border should be populated with the left and right-most 5 pixels from toolButton.png. Since a horizontal border width value is provided it is possible to scale the contents of the button horizontally (inserting more contents will allow it to continue to work properly).
The 0s, on the other hand, indicate that entirety of the button background should be consumed by toolButton.png - and that none of it should be used to show the border (border-image can be used as a crude mechanism for injecting background images). Because of this the image won't be able to gracefully scale vertically.
CSS3.info provides another example that shows how the stretching and rounding work.
with the following base image:
Rounding:
Stretching:
By tweaking the stretching of the border-image you can end up with some truly-compelling results.
border-image has a large number of compelling use cases. It's fantastic to see some coordinated efforts by browser vendors to make their implementations common-place.
This week I've been busy working on implementing a test suite for the Selectors API specification. I picked up a new microphone recently so I decided to do a quick walkthrough of the work that I've been doing and how I've been going about it. You can view the the video below:
You can run the test suite for yourself here (it's still very much in flux - there are various parts that may still be wrong): http://ejohn.org/apps/selectortest/
Here's a quick break down of a test run that was done earlier:
- Special Firefox 3.1 Build (73.8% - More details)
- Safari 3.1 (49.3% - No Fragment or Namespace support)
- WebKit Nightly (51% - No Fragment or Namespace support)
- Opera Gogi - "ACID3 Build" (76.7% - No Fragment support)
- IE 8 (Can't run - the file is proper XHTML so it tries to download it.)
- Firefox 3, Opera 9.5, IE 7 (0%)
The work that is being done to implement the specification in Firefox can be seen on its associated Bugzilla bug. I'm shooting very hard to make sure that everything is in place so that this makes it in to the upcoming Firefox 3.1 release (the first alpha of which is due out in a couple weeks). The benefits that this will have for both JavaScript libraries and their users will be tremendous.
Like every web developer I've spent a lot of time using the Firebug extension to Firefox in my day-to-day development. I've found it interesting to see how my development methodologies have changed with access to that tool.
Unsurprisingly, my personal development style mirrors much of the general web dev public. But what I find most interesting is to try and track trends in web development that Firebug has single-handedly revolutionized.
Firebug Advances
Performance Profiling
Prior to Firebug there was only rudimentary analysis of JavaScript performance (using tricks like injecting timers and computing the difference). Firebug brought us the ability to analyze all function calls during a period of execution, see how they each affected each other and, probably most important, see the difference in the sub-millisecond range.
Previously none of these techniques were possible with pure-JavaScript techniques - having the ability to tap into the JavaScript engine (which Firebug does) is fundamentally important to getting good analysis.
You can see an immediate interest, by JavaScript library authors, in the performance of their code bases around the time of Firebug's introduction of profiling.
Console logging with object introspection
Logging statements has always been possible with JavaScript (and, most infamously, with the alert() function) however Firebug gave us something significant: The ability to click and introspect into logged objects. This includes the ability to click DOM nodes (and see their properties and methods) and even normal objects (like Arrays or Object literals).
Firebug has to maintain a lot references to point to where these objects exist - and it wouldn't be possible in pure-JavaScript without introducing an excessive number of memory leaks.
Current Styles / CSS Rules
There had existed some tools for examining the current CSS style values of a DOM element (such as its dimensions and positioning) but Firebug brought a whole new level of inspection: The ability to see which stylesheet rules were introducing specific styling on an element. Not to mention the ability to edit the rules in-line (along with disabling them outright).
This level of inspection completely overhauled Web Design - and has been able to detach many web designers from their IDE-of-choice into a more agnostic view of CSS design. Absolutely the biggest short-coming of this feature is its inability to work cross-browser (although, that argument can certainly be used for most Firebug features).
Network Performance
Firebug's network tab gave developers the ability to see - in very real terms - two things: 1) How long a resource was taking to load and 2) How the loading of that resource was blocking the loading of other resources. #2 is especially important, seeing that the execution of JavaScript blocks other actions from occurring can be an eye-opening experience to most developers. Or even seeing how a slow-loading stat tracking script can prevent the further display of the page.
XMLHttpRequest Inspection
While XMLHttpRequest use existed prior to the existence of Firebug it was horribly hard to debug - it was rarely obvious where errors were occurring - on the client-side? on the server-side? in the transmission? The ability to see how the requests occurred - and very importantly - how long they took (and even how frequently they occurred!) has done much to improve the overall quality of Ajax use on web pages.
JavaScript Debugging
I would've said that JavaScript Debugging was a piece of that equation, as well, however Venkman definitely lead the way, in that respect (and has been a de-facto debugger for quite some time).
I'd argue that these trends wouldn't be where they are right now if it weren't for Firebug - and that tools are the primary reason for a development strategy's success. As a corollary look at the relative success of web standards - I'd argue that adherence to HTML or CSS wouldn't be where it is today without the tools to verify a page's compliance.
How to Improve
The question now becomes: What are the next set of tools that Firebug can introduce that will revolutionize its respective areas of development?
I'd like to propose a couple, possible, areas of interest:
JavaScript Library Analysis
As it stands Firebug's JavaScript function analysis is, perhaps, too finely-grained to provide help in many instances - especially when the use of JavaScript libraries is at play. For example, when using jQuery, you're generally more concerned with finding out how fast, or slow, a particular method is - or a selector - not the performance of all the individual internal methods of jQuery.
I began some of this analysis with my Deep Profiling jQuery Apps experiment but that's really only a test. Smart integration of JavaScript library knowledge into Firebug can provide significant details about how your code should be performing.
Visual Performance Profiling
Application performance profiling is rather clumsy right now, we have a number of disparate resources (network performance, rendering performance, script performance) that we need to mentally merge to create a full picture of what's happening. To counter this I'd like to propose a way of visually viewing how components of a site affect its overall performance. Perhaps a way to break things down like this:
The YSlow Firebug plugin already provides some level of analysis on your site - but it's much more holistic (giving you generic tips for files and pieces of code). Whereas a more specific approach would be greatly appreciated.
Ajax Improvements
We currently have the ability to view XMLHttpRequests as they occur, which is great, but some additions could be made that would serve to be quite helpful, such as:
The ability to manipulate a request and re-submit it. If you're attempting to see how different inputs will affect your site, this would be a great way to play back requests or see how they can be best improved.
Right now Firebug only lets you know the basic textual output that's coming from the server-side. Having it be able to tell you if incoming XML, JSON, or even HTML is syntactically correct (and even being able to navigate the resulting structures - as the browser would see them) would be a huge boon. As it stands it can be quite frustrating to receive a slightly-malformed response from a server and be stuck trying to figure out what's going wrong.
Better JSON/JSONP integration is essential. There are a large number of Ajax requests being done through dynamic script tag injection - and those are completely unmonitored by Firebug's XMLHttpRequest tracking. Being able to see what requests and responses look like - and where errors may be occurring - would be immensely useful.
Rendering Performance Analysis
While we have fantastic tools for digging in to the performance of JavaScript - CSS is a complete unknown. How much overhead do our stylesheets provide? How many elements does this CSS rule affect? Does this rule cause a costly reflow to occur? and how many times? How long does it take to render a particular portion of a page? Would changing the structure of my page help to improved perceived rendering speed?
Virtually all of these questions are un-answered and we need a tool to help provide a solid response.
Security Analysis
Security is one area that has seen virtually no attention in the respect of user tools. Most developers have no idea how secure their web site is or how vulnerable it may be to attacks. There needs to be easily-accessible tools for testing:
SQL Injection attacks
XSS Injection
Susceptibility to Spoofing (Data Encryption)
At the very least. The problem here is that while these tools will be incredibly useful for developers to improve their web sites - it'll also encourage malicious behavior. Although, arguably, those that wish to be malicious already have the tools to do so.
Standards Integration
Inline support for analyzing the standards-compliance of a page. Being able to see notes next to specific elements, attributes, CSS rules, etc. that show information on how they don't comply with particular standards - or even how they could be improved to match standards.
This includes inline strictness warnings for JavaScript (produced by the JavaScript engine).
I think that compliance should go a step further, as well, and look to provide information on Microformat and RDFa compliance - pointing out specific errors and helping sites to become better formatted.
Finally - RSS and Atom standards compliance. Notifying a developer that their site's RSS/Atom feed is malformed would allow them to immediately make a more compliant feed (a common area of mistakes).
Internet Explorer Support
The final, and perhaps most difficult, item that should occur would be a port of Firebug over to Internet Explorer. Both Safari and Opera have web developer tools integrated into their browsers - however Internet Explorer still consumes a majority market share and there's no good tools in sight. (I, personally, use CompanionJS but it's still a far cry from the full suite of utilities that Firebug provides - especially in the realm of DOM/CSS.)
This could probably be remedied if there was a really good pure-JavaScript Firebug (although the overhead associated with many of Firebug's features would lead to an astronomically-sized implementation). The current "Firebug Lite" is something of a joke - only vaguely functioning in modern browsers.
Not only do I want to see Firebug improve - it's imperative that Firebug continue to improve, for the sake of web developers everywhere. If it simply stalls and works into a stasis of bug fixes then web developers will be stuck with the current set of tools for quite some time. While other browsers are improving at a rapid pace, it'll still be quite some time before they are able to match the current feature-set of Firebug.
Since so much of web development ecosystem is currently linked to the health of a single tool advances have to be made now and they have to be made quickly in order for the web to flourish and survive as a development medium.
David Baron, a Mozilla developer, has a write-up on the new CSS features that are available in Firefox 3. There's a mix of additions - everything from CSS 2.0 and 2.1 features to new additions that are tracking CSS 3.
Some of my favorite additions include:
The CSS 3 Box Specification (in the form of -moz-max-content, -moz-min-content, -moz-fit-content, and -moz-available values to width, min-width, and max-width).
-moz-fit-content actually does let authors do some things that previously weren't possible without tables, such as putting a background on headings that doesn't fill the whole width of the container unless the heading does, but is a single rectangle if the heading breaks to multiple lines (see Demo).
Wrapped whitespace (white-space: pre-wrap). This allows you to have a <pre/> whose contents are wrapped nicely, while still maintaining its rigid structure.
rgba() values. You can now apply opacity directly to background colors (as opposed to having to create a shim div/span and styling that instead). Note that the below text is fully opaque.
body {background: url(stripes-6); }
div {background: rgba(0, 255, 0, 0.5); }
h2 {background: rgba(255, 0, 0, 0.5); }
inline-block and inline-table Such a powerful addition - and one that now brings Firefox in line with most other browsers. It'll allow you to create much-more-complicated layouts that were previously very trying to implement using normal CSS. Demo.
