Planet Mozilla — 5 years of Firefox

5 Years of Firefox Cake at the Firefox Developer Day in Tokyo, Japan

5 Years of Firefox Cake at the Firefox Developer day in Tokyo, Japan

Firefox is five years old. We thought that we would celebrate that by talking about how the web has changed over the last five years and Firefox’s role in those changes.

Where We’re At

2009 has been an interesting year. We’re at a crossroads for the Internet. In the next 12 months or so we’re likely to see regulation of the Internet in the United States – possibly for good, possibly for bad. We’ve seen increased interest in the browser space with the entrace of Google with their minimalist Chrome browser. Mozilla put a vastly improved rendering engine into the hands of hundreds of millions of users with the release of Firefox 3.5. The EU is working with Microsoft to implement a ballot to make users aware of browser choice. No one could possibly say that things are boring right now. And this has only been over the last year.

But what has changed over the last five years? What are the main themes? We’ve picked a few to talk about and we hope that it helps put things into perspective for the next five.

The Rise of the Modern Browser

One thing that’s become obvious over the last five years is the wide gap that’s emerging between the field of modern browsers – Firefox, Safari, Opera and Chrome – with the world’s most popular browser – IE. The modern browser is built for the future of web applications – super fast JavaScript, modern CSS, HTML5, support for the various web-apps standards, downloadable font support, offline application support, raw graphics through canvas and WebGL, native video, advanced XHR capabilities mixed with new security tools and network capabilities.

Over the last five years we’ve been setting ourselves up for the next five. The web is moving faster, not slower, and modern browsers are set to handle it.

In this sense we’ve done our jobs at Mozilla. We were first on the scene with fast JavaScript, CORS, mixing HTML and SVG, WebGL is based on Canvas3D work we pioneered, we’re scripting hardware with geolocation and orientation. We’re helping to standardize and implement some new CSS capabilities that are being developed in other browsers, we’re leading the web towards a modern font system and giving web authors and users more security tools. Our job is to help keep the web rich and moving forward – this is a huge part of our public benefit mission. This is the opportunity that Firefox’s five years have offered us.

The browsers that are on the horizon aren’t just incremental changes – they represent the pieces to build the next generation web – rich with standards-based graphics, new JavaScript libraries and full blown applications.

Standards Won

Firefox’s growth on the web has had another important effect – bringing standards to the forefront of development. Very early in the Mozilla project almost half of the web’s HTML pages started using DOCTYPE in order to opt-in to standards mode for many web browsers. Developers signaled that they wanted to use a standards-based method for development.

That’s important. It set up the current frame for development on the web that we have today. It allowed Apple to take KHTML and turn it into Safari which then allowed Chrome to pick up that work and enter the market and render a standards-based web. Now we don’t have just one or two browsers, but many, and a lot of that has to do with the way that early web developers approached development.

Standards matter, and they should continue to matter. When they do those individual human beings we like to call users benefit with greater choice and fast innovation.

Customizing Your Experience

Led by Firefox’s add-ons system there’s been an explosion in the number of people who are customizing their experiences – both in browsers and on the web. Anywhere from one third to one half of Firefox users have some kind of add-on installed.

The web is unique, and was built to be hacked. No other widely-deployed system in the world delivers itself as source code like the web does. And this transparency has made it possible for the distributed innovation that we’re seeing in Firefox and on the web. People patching new UI into their favorite web sites, mashing up data from multiple sources or radically changing the feel of the browser itself – this is a source for inspiration for browser vendors and web site operators alike. For the first time individual people have the ability to take an active part in the future of their computing
experience.

It’s also worth noting that Gecko and Firefox are unique in this space. The highly modular nature of Gecko mixed with the fact that Firefox itself is written in HTML and XUL (another UI-focused markup language) means that it’s the only browser that’s hackable like the web is. Every other browser is built as a monolithic desktop application from the last millennium. This natural advantage not only means that Firefox has the widest array of add-ons and developers, but is also a source of inspiration for most of the rest of the market.

RSS and Data

In the last five years one of the big changes we’ve seen is web sites offering up data and feeds. Feeds in particular have reached the point where even non-technical people know what they are and how to use them. The ubiquitous RSS icon, which was originally created for the Firefox browser and given away by Mozilla, now exists on millions of web sites offering users the ability to get updates on their terms.

But we’ve gone far beyond just simple feeds. Advanced APIs are now appearing for web sites so you can integrate native applications, build a Firefox extension or be able to pull your data out of a web site.

And we’ve also moved from the promise of XML to the reality of JSON as the data format of choice.

Video

It’s important to remember that Youtube didn’t exist when Firefox was launched. At that time your only options were native QuickTime, Windows Media or Real Player. (Anyone remember Real Player?)

In the last few years we’ve seen Youtube become one of the largest sites of the Internet, the launch of Hulu, and sites like Netflix offering premium on-demand video right over the Internet to web browsers and devices alike. We’ve also seen millions of people create their own videos and publish them to the web.

We’ve also seen the launch of open video and native video support in browsers to bring the creativity and hackability of the web to currently closed video platforms.

Users as Creators

The rise of the web is a story of anyone being able to create a web site. But that’s still a largely technical exercise, even with tools. What we have seen, thanks to tools like WordPress and blogger, is the growth of weblogs, feeds and data which make it possible for anyone with a web browser to become a publisher or journalist.

And it has moved well beyond just text. People with low-cost tools are making movies and posting them. Remix culture is alive and well, creating comentary and new and exciting creations – all in the hands of pretty normal people.

Mobile

The iPhone taught us that you could build a decent browser for mobile phones and that data was important. Phones, really just in the last five years or so, have shown us that access to data plans that look like what you can get to your house can unleash developer and user creativity.

In the last five years at Mozilla we’ve also made the commitment to build a browser for mobile devices. We’re still in an early pre-1.0 beta stage, but that browser is already getting excellent reviews.

So what about the next five years?

Mozilla has been at the heart of many of the issues of the Internet over the last five years. We’ve vastly improved the browsing experience for hundreds of millions of people around the world. We’ve managed to keep Microsoft honest and forced them to release newer versions of their browsers. Firefox’s presence was a large factor in Apple being able to ship a browser to its user base as the Mac came back to the market. We’ve made it possible for third party browser vendors like Google to enter the market. We’ve proven that people care about improving their experiences on the web. We’ve given over 330 million people the taste of what it’s like to use an open source product. And we’ve overseen the technical growth of the web through direct action and standardization.

It’s hard to beat that, but we’re going to try. We’ll continue to make competitive browser releases and improve people’s experiences on the web. We’ll continue to innovate on behalf of developers and bring those improvements to the standards space. And we’ll continue to grow our amazing global community of users, developers and activists.

Over the next five years everyone can expect that the browser should take part in a few new areas – to act as the user agent it should be. Issues around data, privacy and identity loom large. You will see the values of Mozilla’s public benefit mission reflected in our product choices in these areas to make users safer and help them understand what it means to share data with web sites.

Expect to see big changes in the video space. HTML5-based video and open video codecs are starting to appear on the web as web developers make individual choices to support a standards-based, royalty-free approach. Expect to see changes in the expectations around the licensing of codecs.

And over the next five years mobile will play an increasingly important role in our lives, and in the future of the web. The decisions of users, carriers, governments and the people who build phones will have far-reaching effects on this new extension to the Internet and how people will access information for decades to come.

Mozilla has a unique place on the Internet. Driven to help improve it as part of our mission expect us to express opinions on decisions that affect its future. We act both through direct action but also through indirect action – sometimes our effects are as important as our actions. We will continue to protect users and we’ll continue to do everything they can to make it possible for the next set of people to come along and build the next great web site.

It’s been a great five years. Let’s make it another five and keep the web moving forward for the benefit of everyone.

Mark Pilgrim — @sergray Yes, I'll be at the GDD in Moscow on Tuesday, doing HTML5 demos during the keynote, then an hour-long followup session.

Stack Overflow: HTML5 — Is there a good jQuery Drag-and-drop file upload plugin?

Is there a nice tidy jQuery plugin that allows including a single JS script then using a simple snippet to enable a form? Something like this:

$j('#MyForm').enableDragDropUploads('.upload-area')

With the upload target being the action of the form.

Any solution must not prevent a regular file field from being usable (using traditional browse method).

I only need one file at a time, though of course having the option for multiple isn't a bad thing.

I've found a couple of drag-drop upload examples:
http://www.appelsiini.net/2009/10/drag-and-drop-file-upload-with-google-gears http://www.appelsiini.net/2009/10/html5-drag-and-drop-multiple-file-upload

But the code there isn't setup as a plugin. It's probably not too difficult to change it, but also no point doing so if someone else has already done that work and is simply evading my Google searches.

I'm ideally looking for a pure HTML5/jQuery solution.
A Google Gears one is acceptable, but a Flash solution is not.

Stack Overflow: HTML5 — Hidden Features/Properties/Attribute/Tags of CSS3 and HTML

In CSS and HTML world there are always features (Properties/Attribute/Tags) that would be useful in fringe scenarios, but for that very reason most people don't know them. I am asking for features that are not typically taught by the text books about CSS, CSS3 and HTML5.

What are the ones that you know?

[UPDATE] Which browsers adopt HTML tags and CSS3 element? And can i relay on this new technology (HTML5) for my business?

Stack Overflow: HTML5 — How to parse onclick javascript event parameter using MSHTML?

I need to extract the javascript call in the onlick event defined in the following markup:

<div style="cursor: pointer;" onclick='javascript:start("a", "b", "code");'>Click Here</div></div>

This is what I want to extract from onclick as a text string: 'javascript:start("a", "b", "code");'

I am a novice at using MSHTML and this is what I tried so far and I am getting nowhere. Maybe there is a better way to do this?

foreach (mshtml.IHTMLElement elm in (IHTMLElementCollection)doc.body.all)
{
    if (elm.getAttribute("onclick", 0) != null)
    {
        if (elm.getAttribute("onclick", 0).ToString().Contains("javascript:start"))
        {
            Debug.WriteLine("Found!");
        }
    }    
}

Stack Overflow: HTML5 — Will Visual Studio 2010 support HTML 5?

Since Visual Studio 2010 is slated for release in March of 2010 and HTML 5 is now starting to be used even more widely, I would like to know if Visual Studio will ship with HTML 5 templates, standard controls and support for the more common markup?

A definition for support of HTML 5 would be that any new version of Visual Studio should have similar support for code-completion, validation and markup that is currently supported for HTML 4.01 and XHTML 1.0 and 1.1.

Planet Mozilla — Distributed Extensibility

There's been a debate in the HTML Working Group on distributed extensibility; this led to a session at the Technical Plenary yesterday (and, for me, an interesting lunch discussion afterwards that led me to think about issues I hadn't before thought much about). One issue in that debate is that some people see the debate as a debate specifically about whether to use XML namespaces and some see it as a debate about extensibility in general.

I've come to accept that extensibility has positive value, and that the risk of open platforms having proprietary extensions is outweighed by the risk of stagnation and the benefits of adopting extensions into the platform. The value of openness just needs to stand on its own: people can choose open extensions over proprietary ones, just like they can choose an open core over a proprietary one. (This has similarities to the open source vs. free software debate.)

However, I think XML namespaces have some problems as an extension mechanism. One of the reasons I don't like them is that they're hard to use: people have to remember obscure namespace URIs, which makes markup harder to write. Another is that namespaces can encourage not-invented-here syndrome: they encourage extensions to be complete pieces rather than reusing as many pieces of the core as possible, since once you're writing a subtree in a different namespace, it's easier to use elements in that namespace and it's extra work to switch back into the core namespace. Thus they can encourage extensions to extend more than necessary.

Accepting that extension mechanisms are good doesn't necessarily mean their value exceeds their costs; extension mechanisms, especially in software, can be quite costly. In software, large portions of the cost of extensibility is borne by the core, but it's not clear that's also the case for standards.

Bruce Lawson — A sexy new name for the Open Web Stack?

“What’s in a name? that which we call a rose by any other name would smell as sweet” said Juliet of Romeo.

Ultimately, in the heady world of Shakespearian romance, names do matter; if you’re name is Montague, you can’t marry someone called Capulet.

And certainly names matter in the more prosaic (but equally passionate) world of Web Standards. Until Jesse James Garrett coined the term “Ajax” we didn’t really have a phrase to refer to web applications that allowed parts of pages to be updated without refreshing the page. No matter that some Ajax depended neither on JavaScript nor XML; the name was a useful method to describe both the new techniques and the stepping-up of the users’ experience.

I find myself consistently grasping for an umbrella term to describe the new technologies available to us, such as HTML5, CSS 3, Geolocation, W3C Widgets, WAI-ARIA, Web Fonts, Web Storage, Web Sockets, SVG and the like.

I’ve been using “HTML5″ as such an umbrella term for new markup specs and APIs, but it’s inaccurate; Geolocation was never in the HTML5 specification although technologies such as Web Storage used to be until they were split out.

The orginators of the HTML5 specs, the WHATWG, have recently resurrected the term Web Applications 1.0 as a superspec to wrap up HTML5, pre-defined microdata vocabularies, Web Workers, Web Storage, Web Database, Server-sent Events, and Web Sockets.

But that still leaves SVG and CSS. The term “Web 2.0″ is too tainted by marketing BS and synergy-speak to be useful—and also seems to mean social networking, or user-generated content or any number of buzzwords.

Do you have any ideas for a sexy new term? Do we need a sexy new term at all?

Stack Overflow: HTML5 — What are the boundaries or scope definitions of HTML5 development?

From reading the mailing lists and looking at the specification I cannot tell what the limits of HTML5 are as a software or programmatic technology. I have seen where they have attempted to standardize video and audio formats in HTML5 and it seems they may be writing the definitions for XHTML5 into the HTML5 specification. It also appears the specification is extremely lengthy and covers topics far outside the mere definitions and minimally required processing instructions of a markup language.

With version 5 is HTML now an application interface opposed to just a markup language? If so then what are the boundaries and defined limits of the technology? If not, then why are so many topics irrelevant to the processing of markup taking such a spotlight in the development process of the technology? When do the boundaries of a markup language end and the application preferences of a user-agent application begin? With HTML5 that separation does not appear very clear, but as an industry standard it should be crystal clear, right?

Stack Overflow: HTML5 — HTML 5 Doctype? [closed]

what is it - the HTML 5 Doctype?

Mark Pilgrim — ugly hack for some weird html5lib thing I can't fix right now

ugly hack for some weird html5lib thing I can't fix right now

Mark Pilgrim — added example of Greasemonkey script that disables HTML5 video autoplay

added example of Greasemonkey script that disables HTML5 video autoplay

Planet Mozilla — two important api changes – CSS gradients and the media load event

Robert O’Callahan has been posting updates in his weblog about changes that we’re going to be making that are web-facing. It’s worth summarizing two here for web developers.

Removing the media element ‘load’ event.

Yesterday I checked in a patch that removes support for the ‘load’ event on <video> and <audio> elements. We simply never fire it. Also, the networkState attribute is now never NETWORK_LOADED. When we’ve read to the end of the media resource, networkState changes to NETWORK_IDLE. We plan to ship this change for Firefox 3.6.

This API has been removed based on consensus from everyone who are doing HTML5 video implementations and there are lots of other options for events that Robert goes over in his post.

Changing our CSS Gradient Syntax

We landed support for a form of CSS gradients on trunk a while ago, but we got considerable feedback that our syntax — which was an incremental improvement of Webkit’s syntax, which basically exposes a standard gradient API in the most direct possible way — sucked. A bunch of people on www-style got talking and Tab Atkins produced a much better proposal. Since we haven’t shipped our syntax anywhere yet, dropping it and implementing Tab’s syntax instead was a no-brainer. So Zack Weinberg, David Baron and I did that (using a -moz prefix of course), and today it landed on trunk. It should land on the Firefox 3.6 branch shortly. It’s unfortunate to land something new like this after the last beta, but in this case, it seems like the right thing to do instead of shipping CSS gradient syntax that we know nobody wants.

We’ve never shipped the “bad” CSS gradient syntax in a final release, but it is in our first beta. We’ll be updating it before we make our final release of 3.6. Stay turned for the new syntax on hacks.

Mark Pilgrim — added note about html5-video.js requiring html5shiv

added note about html5-video.js requiring html5shiv

Stack Overflow: HTML5 — HTML5 Canvas resize to fit window

How can I automatically scale the HTML5 <canvas> element to fit the page?

For example, I can get a <div> to scale by setting height and width to 100%, but a <canvas> won't scale, will it?

Stack Overflow: HTML5 — Html5 cache manifest in a UIWebView?

I'd like to be able to use the html5 cache manifest to store images locally on an iPhone that is visiting the page via a UIWebView within an app.

I've set up a sample that I think conforms to the specs, and appears to work in safari 4 and mobile safari, but not in my app's UIWebView.

The sample html is set up at http://bynomial.com/html5/clock3.html.

This is very similar to the sample provided in the HTML5 draft standard.

Here is the entire (non-template) code of the sample app I'm using for testing:

- (void)applicationDidFinishLaunching:(UIApplication *)application {    

  // I thought this might help - I don't see any difference, though.
  NSURLCache* cache = [NSURLCache sharedURLCache];
  [cache setDiskCapacity:512*1024];

  CGRect frame = [[UIScreen mainScreen] applicationFrame];
  UIWebView* webView = [[UIWebView alloc] initWithFrame:frame];
  [window addSubview:webView];

  NSString* urlString = @"http://bynomial.com/html5/clock3.html";
  NSURL* url = [NSURL URLWithString:urlString];
  NSURLRequest* request = [NSURLRequest requestWithURL:url];
  [webView loadRequest:request];

  [window makeKeyAndVisible];
}

I've reviewed a few related questions on stackoverflow, but they don't seem to provide info to solve this. For example, I'm pretty sure the files I'm trying to cache are not too large, since they are just a couple small text files (way < 25k).

Any ideas for how to get this to work?

Planet Mozilla — Mozilla Platform Meeting Minutes: 2009-11-03

Platform/2009-11-03

From MozillaWiki

« previous week | index | next week »


Firefox 3.5.5

Firefox 3.0.16 / Firefox 3.5.6

Firefox 3.6 Beta

  • Released on Friday, Oct 30th

  • plan is to promote it heavily to rapidly increase beta audience
  • will refresh frequently via the Firefox 3.6 beta update channel, each update will be versioned “3.6b#” and presented as a “revision”
  • next update is aimed to be this Friday, minimally containing:
    • DLL component directory lockdown and blacklisting patch (see bug 524904 and bug 519357 (blocklist policy discussion in bug 525103)

    • syntax changes for CSS gradients (see bug 513395)
    • cycle-collector patch to stop cycle collection instead of crashing (see bug 521750)
    • other changes on mozilla-1.9.2 since we froze for beta

Firefox 3.6 Release Candidate

  • proposed code freeze November 18th (2 weeks)

  • proposed release November 19th (Happy Thanksgiving)
  • need to check these schedules with build and QA, obviously


See more Firefox 3.6 related blocker queries, or learn about the new status and blocker flags


(Progress reports every weekend on Planet Firefox)

  • see our active projects and get involved / propose others

  • Namoroka/mozilla-1.9.2 front end development:
    • 29 blockers left, 7 are crashkill

    • team estimates this number will be 10 by end of the week
    • per tab prioritization for session restore bug 514490 causing test failures on mozilla-central, should be wrapped up today or tomorrow, see the project page for more detail
    • windows 7 aero peek per-tab preview: as per bug 525475 we’re going to pref this off by default until the other bugs are fixed, allowing us to unblock on them


  • 18 blockers

    • 9 are FIXED, several have patches.

    • GFX team will be triaging these to see which absolutely need to block.
    • Looks good for a November 18 freeze date.
  • 3.5.4 crashes
    • We discovered once 3.5.4 had been released that we had caused two topcrashes: bug 524462 and bug 525326. These were fallout from security bug fixes.

    • More testcases helps, and we’re adding more. But the nature of graphics code (handling user-provided data) implies that it’s very difficult to have fully complete test suites.
    • It’s very likely that these could have been caught in a beta period for 3.5.4. Since we already look at crash-stats, should we just extend beta periods? Should we make it part of the “new release” signoff that we haven’t introduced new topcrashes?
  • GFX team focusing on blockers, Electrolysis, crashes, and performance.


  • Blocker report:

    • 18 blockers, but mostly (9) fixed on trunk and need 1.9.2 landing, or have patches, or we’re not sure there’s a bug

    • Silverlight issue fixed after conversation with Microsoft — we’re doing a trivial workaround for them calling NPN_Invalidate for a windowed plugin
    • Only 1 bug where we know there’s a bug and we don’t have a patch (519767)
    • 1 untriaged layout nom
  • CSS gradient syntax change (bug 513395) landed on m-c yesterday; backport to 1.9.2 is posted to the bug, the a1.9.2 queue, and the try server; would like to land it tonight or Wednesday morning assuming all is well
  • Layers API developed: https://wiki.mozilla.org/Gecko:Layers. Implementation to proceed shortly. Send feedback.
    • Framework for hardware acceleration, 3D transforms, retained buffers for elements, cross-process rendering, off-main-thread compositing, animation and video playback
  • Patches ready to remove nsIScrollableView on trunk
  • Jonathan Kew in Toronto office this week
  • WOFF getting lots of press
  • Rapturous reception at AtypI


  • Excellent work by bz and smaug on a 1.9.1 stability regression

  • Working on 1.9.2 blockers (26 total, 5 fixed/dup, 7 crashkill)
  • crashkill work
  • HTML5 parser work moving forward, getting through reviews.


  • (smichaud) 1.9.2/JEP update — No new bugs in last week. No blockers.



  • Almost done with a tool that shows numbers for all Talos tests across all branches for all platforms, summarizing median and mean per platform, including weekly difference, and difference from Firefox 3.5.

  • Found a scenario for stable cold startup numbers on Windows. Next step is to get a Talos patch up, and work with Rel/Eng to get it deployed into testing so we can see numbers on real Talos boxes.
  • Rob Strong split up the update service in bug 311965, has most reviews (affects all toolkit apps) and is about ready to land. This showed a significant win on WinCE startup.
  • Taras and Joel are working on bug 524202, tracking down exactly how and when dynamic library code is loaded. See this comment for a good summary of the issue.

Join us on IRC in #startup.


pending reviews

feature review date who interested
Windows TSF integration (1.9.2) unscheduled Jim Chen, roc
DNS Prefetching unscheduled Patrick McManus Jesse, bz, reed(?)
Mail config from ISP (Tb3) unscheduled Ben Bucksch
New system metrics (and media queries) unscheduled  ? dbaron


  • Fennelectrolysis lives: with only a medium amount of hackery of the Fennec frontend itself. Currently getting the platform-side patches landed.

  • Working quickly towards getting IPC plugins landed on mozilla-central, preffed off.
    • Multiple plugins work, ipcplugin tests work (2 orange because NPN_SetException isn’t implemented)

    • cjones working on leaks during ipcplugins tests (probably shutdown-only leaks)
    • bent finishing work on Windows hangs


  • Help with making debug tests green. bug 523385

  • Upcoming power outage at 650 castro
    • November 14th

    • bug 524047
    • Mobile tests will be disabled for the duration

Upcoming this week:

  • Electrolysis tests bug 515436

  • Stopping refcounting build on trunk on linux


  • roc: Trying to make httpd.js do GC; xpcshell tests uncooperative

  • robc: firebug – event listener service? yay!
Retrieved from “https://wiki.mozilla.org/Platform/2009-11-03“

Planet WebKit — Web Inspector Updates

A number of exciting new features have been added to the Web Inspector since our last update. Today we would like to highlight some of those features! This post is also available in Japanese (日本語), thanks to Keishi Hattori (服部慶士).

If you would like to play with most of these features you will need to be running a recent WebKit Nightly. Once downloaded make sure that you enable the Web Inspector by checking “Show Develop menu in menu bar” under the Advanced tab in the Preferences.

Enabling the Inspector in Preferences

Editing Element Attributes and Style Properties #

Editing Element Attributes and Style Properties has been made even simpler and more developer friendly. The interfaces for editing attributes and properties now support tabbing to allow you to move between items, and create new items with ease.

Besides tabbing you can also add a new attributes to a node.  Start by hovering over the node in the Element’s Tree Hierarchy and after a polite wait a clickable template for a new attribute will appear.

Edit Element Attributes

Related Bug Reports: Add Element Attributes, Tabbing, and Improved UI.

Creating and Modifying CSS Rules and Selectors #

A powerful new feature in the Web Inspector allows you create new or modify existing CSS Rules and Selectors. We expect both developers and designers will find this very useful when experimenting with new ideas or tweaking existing designs.

The interface for working with selectors starts with a new Gear Menu in the Styles Sidebar Pane. Select “New Style Rule” and a new section will be created for you, pre-populated with an intelligent selector from the selection in the Elements Tree Hierarchy. Editing selectors is activated by double-clicking. Once again, tabbing will allow you to navigate between selectors and their properties.

When editing selectors there is visual feedback when you create or modify a selector that does not affect the selected node in the Elements Tree Hierarchy. This indicator helps detect errors when making changes.

Create and Modify CSS Selectors

One more tweak to the Styles Pane is that there is always a section for the selected node’s style attribute. This allows you to easily add style information to the node as you usually would via the Styles Pane instead of editing or creating a “style” attribute. This section is nearly always on top due to how CSS specificity works.

Related Bug Reports: Selectors Support and Move to Gear Menu.

CSS Color Representations #

Colors in the Styles Pane can be shown in any of their possible representations. For simple colors this includes short hex, full hex, rgb, hsl, and potentially a nickname. For advanced colors this includes rgba and hsla. For example the color “white” can be represented as: #FFF, #FFFFFF, rgb(255, 255, 255), hsl(0, 100%, 100%), and white.

You can use the Styles Pane’s Gear Menu to set your preferred representation. However, if you want to cycle through an individual color’s different representations you can do so by clicking on its associated color swatch.

Mutiple Color Representations

Related Bug Reports: Color Representations, Preference and Gear Menu, and UI Improvement.

DOM Storage #

The Storage Panel (formerly the Databases Panel) now allows you to monitor DOM Storage areas like localStorage and sessionStorage in a familiar datagrid. The DOM Storage datagrid displays live updates so monitoring changes is possible without manually refreshing the view.

Also, the familiar creation and editing techniques apply to the datagrid. To add a new key/value pair just double-click in any open area, or double-click an existing item to start editing. Tabbing works as you would expect.

Observing DOM Storage Key/Value Pairs

Related Bug Reports: DOM Storage Support, Live Updates, Create New Items, and Tabbing.

Keyboard Shortcuts #

Keyboard shortcuts are always desired by developers. They can be hard to discover, so here is a complete list and here are the ones that were added recently:

  • Switch Panels — Command-[ and Command-] on a Mac or Control-[ and Control-] on other platforms.
  • Delete a Node in the Tree Hierarchy — either Delete or Backspace keys will do the trick.
  • Quick Edits in the Tree Hierarchy — Hitting Enter or Return on a Node in the Tree enters the editing mode for that type of Node. For a Text Node you will start editing the content. For Element Nodes you start editing the first attribute, or, for convenience, a new attribute will be added for you.

The Scripts Debugger was updated to support some popular keyboard shortcuts:

  • Continue — F8 or Command-/ on a Mac or Control-/ on other platforms.
  • Step Over — F10 or Command-’ on a Mac or Control-’ on other platforms.
  • Step Into — F11 or Command-; on a Mac or Control-; on other platforms.
  • Step Out — Shift-F11 or Shift-Command-; on a Mac or Shift-Control-; on other platforms.
  • Next Call Frame — Control-. on all platforms.
  • Previous Call Frame — Control-, on all platforms.
  • Evaluate Selection When on a Breakpoint — Shift-Command-E on a Mac or Shift-Control-E on other platforms.

Related Bug Reports: Switch Panels, Delete Node, Quick Edit, General Debugger Shortcuts and Evaluate Selection.

Cookies #

Viewing Cookie information is now possible under the Storage Panel. Supported platforms show all of the cookies and their hidden information for all domains accessed on the inspected page. Cookie information includes the name, value, path, expiration date, http only flag, and secure (https) flag. Supported platforms may also delete cookies.

If your platform doesn’t have full support you aren’t left in the dark. You will still be able to see the keys and values of the cookies that are accessible via JavaScript on the inspected page.

Inspect Hidden Cookie Information

Related Bug Reports: Initial Support, Hidden Data 1 and 2, Cookies for Sub-Resources, and UI Improvements

Event Listeners #

A new Sidebar Pane has been added to the Elements Panel which displays the registered Event Listeners for the selected node.  The Event Listeners that are shown for the selected node are in the exact order that they are fired through the Capturing and Bubbling phases.  This provides developers with the most accurate and useful information possible.

The user interface shows the registered Event Listeners separated by type. If a node has both “onclick” and “onmouseover” listeners then they will naturally appear in different sections. You can also set your filter preference using the Gear Menu. You can choose to see only the listeners registered on the selected node, or the entire event flow.

Inspect Registered Event Listeners

We are actively looking for UI improvements in this area. So if you have some ideas or feedback please feel free to let us know on this bug report!

Related Bug Reports: Event Listeners.

Syntax Highlighting #

Syntax highlighting enhances readability, makes debugging code easier, and looks really awesome. The Web Inspector now includes syntax highlighting for JSON and CSS.

CSS Syntax Highlighting

CSS Syntax Highlighting even works on the more complex “at-rules” such as @import, @media and @font-face. In addition to supporting the syntax highlighting in the Resources Panel, inline scripts and styles in the Elements Tree Hierarchy are syntax highlighted!

Inline JavaScript and CSS Syntax Highlighting

Related Bug Reports: JSON Highlighting, CSS Highlighting, and Inline Highlighting.

Breakpoints and Watch Expressions #

The Script Debugger continues to become more powerful and more useful.  We already mentioned the keyboard shortcuts above, but there are plenty of other enhancements.

There is a new Breakpoints Sidebar Pane that allows you to easily monitor and work with your breakpoints across all files without the hassle of searching for them.  Each sidebar entry shows the source line and contains a checkbox that allows you to directly enable or disable the breakpoint. Clicking on the entry will jump you directly to the highlighted line in the source file. Finally, deleting a breakpoint has been made easier by clicking the “blue tag” breakpoint indicator.  The tag will cycle through its three states of active, inactive, and removed.

A powerful feature added to the debugger is Conditional Breakpoints. Once you have a breakpoint set, right click on the “blue tag” breakpoint indicator and you will get a popup asking for a conditional statement for that breakpoint. Simply provide an expression and the breakpoint will only pause from then on only if the condition is true.

Breakpoints and other Debugging Improvements

Another new feature in the Debugger is Watch Expressions.  In this new Sidebar Pane you can add any number of expressions that evaluate in the global scope normally but in the local scope when paused in the debugger. Once added you get the full Object Properties tree view of the values of each expression.  These watch expressions automatically refresh when the debugger pauses. They are also persist across page loads.

Watched Expressions in Action

Related Bug Reports: Breakpoints Sidebar Pane, Watch Expressions, Evaluate on Breakpoint, Conditional Breakpoints, and Delete Breakpoints.

Debugging AJAX #

An extremely valuable feature for developers working with AJAX is the ability to view the exact parameters and payload sent on XMLHttpRequests.

In the individual resource view there are new sections for viewing submitted Form Data, Query String Parameters, and Request Payloads when appropriate. You can toggle viewing the information in its unencoded (default) and encoded forms with a double-click.

There is also new section named HTTP Information which contains the Request Method (GET, POST, etc.) and the Status Code (200, 404, etc.). Additionally, it adds a colored dot next to the requested URL to show the status (green for success, orange for redirect, and red for error).

View Submitted Form Data and HTTP Information

Related Bug Reports: HTTP Status Code and Data, Parameters, and Payload

Resources and Console Scope Bars #

In order to filter through the Resources or Console messages the Web Inspector now sports some familiar Scope Bars. This has proven to be very useful in the Resources Panel for easily viewing all resources of a particular type.

Quick Filtering Scope Bars for Resources Types and Console Message Types

Related Bug Reports: Resources Scope Bar and Console Scope Bars.

Resources Timeline #

The Web Inspector now specifically shows in the timeline when the DOMContentLoaded and Load events fire. This helps clarify the time it takes for pages to load and helps you improve your websites load times.

DOMContent Ready Event and Page's Load Event Indicators

Related Bug Reports: Show Load Lines

Resources Interactivity #

A couple new features allow you to more directly access individual resources from within the Web Inspector. Instead of copying their URL and opening a new tab manually you can now double-click the Resource in the sidebar to open it directly in a new window. Or, you can drag and drop the resource using HTML5 drag and drop events!

Related Bug Reports: Open Resource Directly and Drag and Drop.

Console Improvements #

Properties in the Web Inspector’s Console are now sorted in a much more natural and useful way. By sorting keys alphanumerically Arrays with greater then 10 elements are much easier to work with.

Alphanumeric Sorting

Another tweak is that collections such as NodeLists and HTMLCollections are now displayed like Arrays.  This meaning that their contents are shown directly in the console, no longer requiring any extra boilerplate.

More Descriptive Nodelists

Related Bug Reports: Sorting and NodeLists.

Firebug Command API Improvements #

More improvements have been made to support more of the Firebug Command Line API. The Web Inspector now supports the inspect() function, which can take an Element, Database, or Storage area and automatically jumps to the appropriate Panel with information. Also, the $0-$4 variables contain the current and previous selected nodes from the Elements Tree Hierarchy.

These command line APIs are usable inside the Web Inspector’s Console. To make working with these APIs even easier, they now show up in the Console’s autocompletion.

Related Bug Reports: $# Variables, inspect() Function, and Autocompletion.

How You Can Contribute #

Many of these new features were added by members of the Open Source Community. We would like to encourage you to contribute as well! Since the Web Inspector itself is mostly HTML, JavaScript, and CSS that means that you already have the skills you need to join in! Interested? Play around right now by inspecting the inspector itself!

Work on the Web Inspector using the Web Inspector!

If you’re interested in contributing and have any questions please stop by the #webkit-inspector IRC channel! As an encouragement to developers, included at the end of each section above are the core bug reports that were involved in bringing each of these features to life.

Finally, if you have ideas for new features, any improvements, or if you’ve stumbled across a bug then please don’t hesitate to create a bug report. This link has pre-populated most of the fields so that you only need to fill out the Summary and Description. As always you should do a quick search through the existing inspector bugs first.

Sam Ruby — Purity Smurity

Mark Pilgrim: Anyone who tells you that HTML should be kept “pure” (presumably by ignoring browser makers, or ignoring authors, or both) is simply misinformed. HTML has never been pure, and all attempts to purify it have been spectacular failures, matched only by the attempts to replace it.

I strongly agree with Mark’s statement.  Furthermore, I believe that it is a useful predictor of which parts of HTML will ultimately succeed and which parts will ultimately fail.

I’ll add that Mark’s closing statement that The ones that win are the ones that ship. is correct albeit incomplete.  Shipping is necessary but not sufficient.

Mark Pilgrim — Why do we have an IMG element?

On February 25, 1993, Marc Andreessen wrote:

I’d like to propose a new, optional HTML tag:

IMG

Required argument is SRC="url".

This names a bitmap or pixmap file for the browser to attempt to pull over the network and interpret as an image, to be embedded in the text at the point of the tag’s occurrence.

An example is:

<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">

(There is no closing tag; this is just a standalone tag.)

This tag can be embedded in an anchor like anything else; when that happens, it becomes an icon that’s sensitive to activation just like a regular text anchor.

Browsers should be afforded flexibility as to which image formats they support. Xbm and Xpm are good ones to support, for example. If a browser cannot interpret a given format, it can do whatever it wants instead (X Mosaic will pop up a default bitmap as a placeholder).

This is required functionality for X Mosaic; we have this working, and we’ll at least be using it internally. I’m certainly open to suggestions as to how this should be handled within HTML; if you have a better idea than what I’m presenting now, please let me know. I know this is hazy wrt image format, but I don’t see an alternative than to just say “let the browser do what it can” and wait for the perfect solution to come along (MIME, someday, maybe).

Xbm and Xpm were popular graphics formats on Unix systems.

“Mosaic” was one of the earliest web browsers. (”X Mosaic” was the version that ran on Unix systems.) When he wrote this message in early 1993, Marc Andreessen had not yet founded the company that made him famous, Mosaic Communications Corporation, nor had he started work on that company’s flagship product, “Mosaic Netscape.” (You may know them better by their later names, “Netscape Corporation” and “Netscape Navigator.”)

“MIME, someday, maybe” is a reference to content negotiation, a feature of HTTP where a client (like a web browser) tells the server (like a web server) what types of resources it supports (like image/jpeg) so the server can return something in the client’s preferred format. The Original HTTP as defined in 1991 (the only version that was implemented in February 1993) did not have a way for clients to tell servers what kind of images they supported, thus the design dilemma that Marc faced.

A few hours later, Tony Johnson replied:

I have something very similar in Midas 2.0 (in use here at SLAC, and due for public release any week now), except that all the names are different, and it has an extra argument NAME="name". It has almost exactly the same functionality as your proposed IMG tag. e.g.

<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">

The idea of the name parameter was to allow the browser to have a set of “built in” images. If the name matches a “built in” image it would use that instead of having to go out and fetch the image. The name could also act as a hint for “line mode” browsers as to what kind of a symbol to put in place of the image.

I don’t much care about the parameter or tag names, but it would be sensible if we used the same things. I don’t much care for abbreviations, ie why not IMAGE= and SOURCE=. I somewhat prefer ICON since it imlies that the IMAGE should be smallish, but maybe ICON is an overloaded word?

Midas was another early web browser, a contemporary of X Mosaic. It was cross-platform; it ran on both Unix and VMS. “SLAC” refers to the Stanford Linear Accelerator Center (now the SLAC National Accelerator Laboratory). SLAC hosted the first web server in the United States (in fact the first web server outside Europe). When Tony wrote this message, SLAC was an old-timer on the WWW, having hosted five pages on their web server for a whopping 441 days.

Tony continued:

While we are on the subject of new tags, I have another, somewhat similar tag, which I would like to support in Midas 2.0. In principle it is:

<INCLUDE HREF="...">

The intention here would be that the second document is to be included into the first document at the place where the tag occured. In principle the referenced document could be anything, but the main purpose was to allow images (in this case arbitrary sized) to be embedded into documents. Again the intention would be that when HTTP2 comes along the format of the included document would be up for separate negotiation.

“HTTP2” is a reference to Basic HTTP as defined in 1992. At this point in early 1993, it was still largely unimplemented. The draft known as “HTTP2” evolved and was eventually standardized as “HTTP 1.0” (albeit not for another three years). HTTP 1.0 did include request headers for content negotiation, a.k.a. “MIME, someday, maybe.”

Tony continued:

An alternative I was considering was:

<A HREF="..." INCLUDE>See photo</A>

I don’t much like adding more functionality to the <A> tag, but the idea here is to maintain compatibility with browsers that can not honour the INCLUDE parameter. The intention is that browsers which do understand INCLUDE, replace the anchor text (in this case “See photo”) with the included document (picture), while older or dumber browsers ignore the INCLUDE tag completely.

This proposal was never implemented, although the idea of text-if-an-image-is-missing is an important accessibility technique which was missing from Marc’s initial <IMG> proposal. Many years later, this feature was bolted on as the <img alt> attribute, which Netscape promptly broke by erroneously treating it as a tooltip.

A few hours after that, Tim Berners-Lee responded:

I had imagined that figues would be reprented as

<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>

where the relation ship values mean

EMBED	 Embed this here when presenting it
PRESENT	 Present this whenever the source document is presented

Note that you can have various combinations of these, and if the browser doesn’t support either one, it doesn’t break.

[I] see that using this as a method for selectable icons means nesting anchors. Hmmm. But I hadn’t wanted a special tag.

This proposal was never implemented, but the rel attribute is still around.

Jim Davis added:

It would be nice if there was a way to specify the content type, e.g.

<IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>

But I am completely willing to live with the requirement that I specify the content type by file extension.

This proposal was never implemented, but Netscape did later add arbitrary embedding of media objects with the <embed> element.

Jay C. Weber asked:

While images are at the top of my list of desired medium types in a WWW browser, I don’t think we should add idiosyncratic hooks for media one at a time. Whatever happened to the enthusiasm for using the MIME typing mechanism?

Marc Andreessen replied:

This isn’t a substitute for the upcoming use of MIME as a standard document mechanism; this provides a necessary and simple implementation of functionality that’s needed independently from MIME.

Jay C. Weber responded:

Let’s temporarily forget about MIME, if it clouds the issue. My objection was to the discussion of “how are we going to support embedded images” rather than “how are we going to support embedded objections in various media”.

Otherwise, next week someone is going to suggest ‘lets put in a new tag <AUD SRC="file://foobar.com/foo/bar/blargh.snd">‘ for audio.

There shouldn’t be much cost in going with something that generalizes.

With the benefit of hindsight, it appears that Jay’s concerns were well-founded. It took a little more than a week, but HTML5 did finally add new <video> and <audio> elements.

Responding to Jay’s original message, Dave Raggett said:

True indeed! I want to consider a whole range of possible image/line art types, along with the possibility of format negotiation. Tim’s note on supporting clickable areas within images is also important.

Later in 1993, Dave Raggett proposed HTML+ as an evolution of the HTML standard. The proposal was never implemented, and it was superceded by HTML 2.0. HTML 2.0 was a “retro-spec,” which means it formalized features already in common use. “This specification brings together, clarifies, and formalizes a set of features that roughly corresponds to the capabilities of HTML in common use prior to June 1994.”

Dave later wrote HTML 3.0, based on his earlier HTML+ draft. HTML 3.0 was also never implemented (outside of the W3C’s own reference implementation, Arena), and it was superceded by HTML 3.2. HTML 3.2 was also a “retro-spec” — “HTML 3.2 adds widely deployed features such as tables, applets and text flow around images, while providing full backwards compatibility with the existing standard HTML 2.0.”

Dave later co-authored HTML 4.0 and developed HTML Tidy, and went on to help with XHTML, XForms, MathML, and other modern W3C specifications.

Getting back to 1993, Marc replied to Dave:

Actually, maybe we should think about a general-purpose procedural graphics language within which we can embed arbitrary hyperlinks attached to icons, images, or text, or anything. Has anyone else seen Intermedia’s capabilities wrt this?

Intermedia was a hypertext project from Brown University. It was developed from 1985 to 1991 and ran on A/UX, a Unix-like operating system for early Macintosh computers.

The idea of a “general-purpose procedural graphics language” did eventually catch on. Modern browsers support both SVG (declarative markup with embedded scripting) and <canvas> (procedural direct-mode graphics API), although the latter started as a proprietary extension before being “retro-specced” by the WHATWG.

Bill Janssen replied:

Other systems to look at which have this (fairly valuable) notion are Andrew and Slate. Andrew is built with _insets_, each of which has some interesting type, such as text, bitmap, drawing, animation, message, spreadsheet, etc. The notion of arbitrary recursive embedding is present, so that an inset of any kind can be embedded in any other kind which supports embedding. For example, an inset can be embedded at any point in the text of the text widget, or in any rectangular area in the drawing widget, or in any cell of the spreadsheet.

“Andrew” is a reference to the Andrew User Interface System (although at that time it was simply known as the Andrew Project).

Meanwhile, Thomas Fine had a different idea:

Here’s my opinion. The best way to do images in WWW is by using MIME. I’m sure postscript is already a supported subtype in MIME, and it deals very nicely with mixing text and graphics.

But it isn’t clickable, you say? Yes your right. I suspect there is already an answer to this in display postscript. Even if there isn’t the addition to standard postscript is trivial. Define an anchor command which specifies the URL and uses the current path as a closed region for the button. Since postscript deals so well with paths, this makes arbitrary button shapes trivial.

Display Postscript was an on-screen rendering technology co-developed by Adobe and NeXT.

This proposal was never implemented, but the idea that the best way to fix HTML is to replace it with something else altogether still pops up from time to time.

Tim Berners-Lee, March 2, 1993:

HTTP2 allows a document to contain any type which the user has said he can handle, not just registered MIME types. So one can experiment. Yes I think there is a case for postscript with hypertext. I don’t know whether display postcript has enough. I know Adobe are trying to establish their own postscript-based “PDF” which will have links, and be readable by their proprietory brand of viewers.

I thought that a generic overlaying language for anchors (Hytime based?) would allow the hypertext and the graphics/video standards to evolve separately, which would help both.

Let the IMG tag be INCLUDE and let it refer to an arbitrary document type. Or EMBED if INCLUDE sounds like a cpp include which people will expect to provide SGML source code to be parsed inline — not what was intended.

HyTime was an early, SGML-based hypertext document system. It loomed large in many early discussions of HTML, and later XML.

Tim’s proposal for an <INCLUDE> tag was never implemented, although you can see echoes of it in <object>, <embed>, and the <iframe> element.

Finally, on March 12, 1993, Marc Andreessen revisited the thread:

Back to the inlined image thread again — I’m getting close to releasing Mosaic v0.10, which will support inlined GIF and XBM images/bitmaps, as mentioned previously. …

We’re not prepared to support INCLUDE/EMBED at this point. … So we’re probably going to go with <IMG SRC="url"> (not ICON, since not all inlined images can be meaningfully called icons). For the time being, inlined images won’t be explicitly content-type’d; down the road, we plan to support that (along with the general adaptation of MIME). Actually, the image reading routines we’re currently using figure out the image format on the fly, so the filename extension won’t even be significant.

I don’t really know why I wrote this. It wasn’t what I set out to write. That happens. But I am extraordinarily fascinated with all aspects of this almost-17-year-old conversation. Consider:

  • HTTP still exists. HTTP successfully evolved from 0.9 into 1.0 and later 1.1. And still it evolves.
  • HTML still exists. That rudimentary data format — it didn’t even support inline images! — successfully evolved into 2.0, 3.2, 4.0. And still it, too, evolves. HTML is an unbroken line. A twisted, knotted, snarled line, to be sure. There were plenty of “dead branches” in the evolutionary tree, places where standards-minded people got ahead of themselves (and ahead of authors and implementors). But still. Here we are, in 2009, and web pages from 1990 still render in modern browsers. I just loaded one up on my Android phone, and I didn’t even get prompted to “please wait while importing legacy format…”
  • HTML has always been a conversation between browser makers, authors, standards wonks, and other people who just showed up and liked to talk about angle brackets. Most of the successful versions of HTML have been “retro-specs,” catching up to the world while simultaneously trying to nudge it in the right direction. Anyone who tells you that HTML should be kept “pure” (presumably by ignoring browser makers, or ignoring authors, or both) is simply misinformed. HTML has never been pure, and all attempts to purify it have been spectacular failures, matched only by the attempts to replace it.
  • None of the browsers from 1993 still exist in any recognizable form. Netscape Navigator was abandoned in 1998 and rewritten from scratch to create the Mozilla Suite, which was then forked to create Firefox. Internet Explorer had its humble “beginnings” in “Microsoft Plus! for Windows 95,” where it was bundled with some desktop themes and a pinball game. (But of course that browser can be traced back further too.)
  • Some of the operating systems from 1993 still exist, but none of them are relevant to the modern web. Most people today who “experience” the web do so on a PC running Windows 2000 or later, a Mac running Mac OS X, a PC running some flavor of Linux, or a handheld device like an iPhone. In 1993, Windows was at version 3.1 (and competing with OS/2), Macs were running System 7, and Linux was distributed via Usenet. (Want to have some fun? Find a graybeard and whisper “Trumpet Winsock” or “MacPPP.”)
  • Some of the same people are still around and still involved in what we now simply call “web standards.” That’s after almost 20 years. And some were involved in predecessors of HTML, going back into the 1980s and before.
  • Speaking of predecessors… With the eventual popularity of HTML and the web, it is easy to forget the contemporary formats and systems that informed its design. Andrew? Intermedia? HyTime? And HyTime was not some rinky-dink academic research project; it was an ISO standard. It was approved for military use. It was Big Business. And you can read about it yourself… on this HTML page, in your web browser.

But none of this answers the original question: why do we have an <img> element? Why not an <icon> element? Or an <include> element? Why not a hyperlink with an include attribute, or some combination of rel values? Why an <img> element? Quite simply, because Marc Andreessen shipped one, and shipping code wins.

That’s not to say that all shipping code wins; after all, Andrew and Intermedia and HyTime shipped code too. Code is necessary but not sufficient for success. And I certainly don’t mean to say that shipping code before a standard will produce the best solution. Marc’s <img> element didn’t mandate a common graphics format; it didn’t define how text flowed around it; it didn’t support text alternatives or fallback content for older browsers. And 16, almost 17 years later, we’re still struggling with content sniffing, and it’s still a source of crazy security vulnerabilities. And you can trace that all the way back, 17 years, through the Great Browser Wars, all the way back to February 25, 1993, when Marc Andreessen offhandedly remarked, “MIME, someday, maybe,” and then shipped his code anyway.

The ones that win are the ones that ship.

Footnotes

Updated: .  Michael(tm) Smith <mike@w3.org>