Web Platform Team Blog



Making the web awesome

Adobe WebKit Hackathon Summary

At the beginning of March, the Web Platform team at Adobe hosted a 3 day internal WebKit hackathon which focused on prototyping new features, fixing bugs and adding tests. We had a ton of fun stretching our WebKit development muscles! Over 7 different product teams participated and participating engineers delved into a broad number of WebKit feature areas including investigating enhancements to existing CSS features and improving code coverage and testing workflows for WebKit developers.

Given how much fun we had with this hackathon and how useful we think it was, we are starting to think more broadly – including hosting regular hackthons that can be open to the general public. Keep an eye on this blog for more details about upcoming hackathons and how you can participate.

Below I give a brief summary of what each hackathon team investigated and the changes that landed into WebKit trunk. For some of these topics, we haven’t determined how to take the prototype forward (or whether we should at all). This is where your feedback is incredibly important! Are there hackathon topics that particularly pique your interest? Do you have suggestions on how to mature these prototypes or support certain requirements? Don’t be shy – leave a comment in the entry with feedback on any of these hackathon topics and we will get back to you.

Nth letter CSS

Here, the hackathon team focused on creating a feature which was a generalization of the :first-letter pseudoelement, such that you could create styles that apply to any letter of a text item, not just the first. This approach is covered in the Selectors Level 3 W3C specification here.

The desired syntax was :nth-letter(), where the argument would (ideally) take the same values that :nth-child can (e.g, a simple index, “even”/”odd”, or an expression like “2n+4″).

The approach was to take the existing :first-letter code in WebKit and try to generalize it to handle different letters. While coding, the team ran into a number of issues: there are several limitations in the :first-letter spec (e.g. block styles don’t apply to the first letter unless you float it) as well as some bugs in the codebase (e.g. CSS transitions don’t work on :first-letter properties). Also, because the existing code assumed you were only looking for the first letter, it didn’t have a way to traverse the tree to look at multiple text items within a single container or to deal with splitting up a text item into multiple pieces.

Still, the hackathon team made great progress! They got as far as being able to handle :nth-letter() on a single letter specified by simple index, parsing the pseudoelement syntax and applying it to the proper letter in the text item. Check out the progress made below, where this code:

<p id="sentence">My fourth letter is awesome.</p>
#sentence:nth-letter(3) {
color: red;font-family: "Comic Sans MS";
font-size: 3em;
font-weight: bold;

using the :nth-letter() prototype produced this result:

We’re pretty excited by the progress made and the power this change provides developers. Given that, the Web Platform team is determining how to take this feature forward for full inclusion in WebKit.

Inspect My Web Inspector

Web Inspector is incredibly powerful and developers on the Web Platform team are often thinking about how to improve it to benefit rapid development & debugging. The hackathon team worked on being able to show the source code line or the API call at the origin of DOM elements directly in the WebKit Web Inspector. For example, a <div> element could come from line 5, column 20 in test.html or from parentDiv.appendChild(myDiv) at line 150 in test.js. Exposing this information directly in WebKit’s Web Inspector was the goal and the hackathon team succeeded – check it out!

Bugzilla 75483: Better Exposing XHR Progress Events in Web Inspector

Currently, when XHR progress events run (loadStart, loadEnd, progress), you can see in the Web Inspector which corresponding scripts execute. However, except for the load event, you can’t tell that those scripts are triggered by the proggress event listeners. As such, the hackathon team focused on adding this transparency to the Web Inspector for all progress events. They are working on cleaning up the patch such that it can land in WebKit trunk sometime soon. Keep an eye out on the bugzilla bug to track its progress into WebKit.

CSS Blending

This hackathon team prototyped the implementation of the blend-mode CSS property as proposed in the CSS Compositing draft here. The Web Platform team is aiming to take this prototype forward in the coming months including discussing the topic further at an upcoming CSS Working Group meeting. Keep an eye on this blog for an update on our work around CSS Compositing but till then, here is a quick screenshot of a video being blended.

CSS Regions Integration with Web Inspector

This hackathon team focused on how the WebKit Web Inspector could be enhanced to show more information about the regions used in a layout taking advantage of CSS Regions. This included displaying the semantic name of flows and regions available in a document and providing visual indications when interacting with the layout (e.g highlighting the regions flowing into a particular flow). For example, below you see that regions are visually demarcated with boxes when using Web Inspector:

And here as the user hovers over elements in Web Inspector, the corresponding regions visually highlight with more information in the tooltip:

The team made great progress and we plan on contributing to Web Inspector to better expose CSS Regions for easy visual debugging.

Auto-sizing in CSS Regions

The W3C CSS Working Group has been discussing how to make it possible for a CSS regions’ height to automatically size to the content included within it. When content flows through a chain of regions, it would be nice to allow a regions’ height to automatically shrink wrap to the segment of content it receives. We prototyped a proposal based on this idea (described further here). We plan on moving forward with this auto-sizing prototype and discussing it further at an upcoming CSS Working Group meeting.

WebKit HUD (Heads Up Display) in Adobe DreamWeaver

This hackathon team showed a two-way relation between the Live View panel and the Source Code panel in Adobe Dreamweaver. To do this, they leveraged some of the features in Web Inspector. They prototyped getting a tooltip to appear within Dreamweaver as the user hovered over HTML elements. This tooltip would display the tag name of any associated class, id and corresponding width and height of the element being hovered over, check it out!

WebKit Code Coverage Dashboard

Currently WebKit exposes a mechanism to get code coverage data for development on Mac. This data is shared through a variety of files: files containing general CSV data with coverage data provided on a per-file basis and files with per-line code coverage data which is either annotated source code or HTML formatted. However, there is no easy way to review all of this data once you have amassed multiple code coverage reports. Browsing through the HTML gives you a detailed view of the data, but it’s still hard to get a clear view on the coverage for a source tree folder or to switch between different reports.

With this problem in mind, the hackathon team worked on a code coverage dashboard prototype that would parse the general CSV data file and present the data cleanly in a web front-end. The goal of the dashboard was to provide an easy way to parse and dive through code overage data from a high level (e.g source folder) all the way down to line-level for multiple runs. The team succeeded and we are currently brainstorming how to take this feature forward, including adding the ability to parse individual data files and showing the run data over variable units (e.g, over a number of days or interval of runs).

Below the prototype aggregates code coverage data for all the files in a source folder and visually represents the results in a bar chart to the right.

Bugzilla 80709: W3C Test harness in WebKit

The Web Platform team has been investigating how to make W3C tests more portable as well as bettering a WebKit developer’s life by allowing W3C tests to run automatically within the WebKit test infrastructure. The team demo’ed work in progress that they completed during the hackathon and in fact, just this week landed the patch in WebKit trunk. We will soon blog more details about this testing workflow and how a WebKit developer can take advantage of it, so stay tuned.

Bugzilla 80602: Convert CSS Regions Pixel Tests to RefTests

The hackathon team refactored 8 pixel-comparison tests (which tested the positioning of objects using CSS Regions) into reftests. Reftests are a fairly recent addition to the WebKit testing framework and are great because they are cross-platform, reduce test expectation bloat, work with the W3C test harness and are generally easier to maintain. This refactoring resulted in a reduction to the tests by 34 files.

The hackathon team is currently in the process of tidying up some of the documentation as requested by their WebKit reviewer; they will then re-submit the patch for landing in WebKit trunk.


  1. March 26, 2012 at 7:21 pm, WTF’s move, image-set() CSS Function and Cross-Origin Scripts « Peter Beverloo said:

    [...] interest in Adobe’s recent work on WebKit, they recently hosted a hackathon which yielded some interesting results. It’s a good [...]

  2. March 27, 2012 at 6:02 pm, Matthew David said:

    This is a great work! I am not sure which feature I am more excited about. Great hackathon!

  3. March 27, 2012 at 9:44 pm, Phil Haeusler said:

    Hi Deepa, a somewhat unrelated question, but am i correct in assuming that it is Adobe’s webkit that is bundled with the desktop versions of AIR and made available through flash.html.HTML? I’ve run into numerous issues largely around CSS3 rendering within AIR that seem to be solved by the latest versions of webkit shipped with Safari and Chrome. Is there plan to merge these changes from the main webkit into Adobe’s branch and bring up the level of CSS3 support in AIR?

    • March 28, 2012 at 8:09 pm, Deepa Subramaniam said:

      Hi Phil – The version of WebKit that ships in AIR is different from what is in WebKit trunk. As such, it does not have the same features or fixes that are currently in WebKit trunk. The runtime teams will be sharing their plans around AIR, including the evolution of HTML support within AIR, this year. Till then, I’d recommend using the StageWebView API in AIR. SWV gives you the system browser control – which is oftentimes more advanced then the version of WebKit currently embedded in AIR. There is a fair amount of documentation and tutorials online about SWV – give that a look.

  4. April 06, 2012 at 5:37 am, Bobert Downey said:

    Was the nth-letter work really checked-in? It’s not working in the latest nightly.

    • April 12, 2012 at 3:21 am, Deepa Subramaniam said:

      Hi – It was not checked into WebKit. We simply prototyped the start of the implementation to give the proposal a spin.

      • May 03, 2012 at 10:38 pm, Bobert Downey said:

        Could you create a bugzilla bug and post the patch so someone else can possibly take up the task?

  5. April 12, 2012 at 6:23 pm, John Nack on Adobe : Look at the great stuff Adobe’s putting into WebKit said:

    [...] (typeof(addthis_share) == "undefined"){ addthis_share = [];}Seriously, look at it: Blending modes, better typography, Web inspector improvements, lots of CSS Regions improvements, [...]

  6. April 12, 2012 at 10:10 pm, Chris said:

    Love the work on blending! However, nth-letter is great and all, but a first-word would be really appreciated by some :)

  7. April 13, 2012 at 4:54 am, mark said:

    Did you fix Chrome’s ugly font rendering on Windows? I stopped using webkit based browsers on Windows.

    • April 16, 2012 at 11:40 pm, Deepa Subramaniam said:

      We didn’t do any work specifically around font rendering on Windows. I don’t believe the Chrome team has done much recently in this area this year.

  8. April 13, 2012 at 6:25 am, David Wilhelm said:

    I love that you are working on the WebKit inspector integration of new features… the code coverage analysis in the inspector is a great idea, and I hope it gets completed/integrated.

  9. April 13, 2012 at 9:42 am, Bart said:

    Now hope FireFox, IE and Opera pick this goodness up as well :p

  10. April 20, 2012 at 10:22 pm, Doug Schepers said:

    :nth-letter() would be nice, but brittle with changeable content. Why not a more general :regex() pseudoelement, that takes a performant subset of regular expression syntax, to allow more flexibility (e.g. whole runs of strings, each or every instance of a character, etc.)?

    That would meet a broader set of scenarios, and is familiar to most JS-savvy folks, with a bunch of tools and documentation around it.