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.
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:
My fourth letter is awesome.
#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
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.
Group Product Manager, Adobe Web Platform. Career Giggler. 
No comments:
Post a Comment