The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the Web. Read about the W3C mission.

Ideas for GSOC 2015

The timeline for GSOC 2015 indicates that the ideas must be submitted by February 20.

Adding a Proposal

For a list of examples, please see KDE Ideas for GSOC 2011

(for testing, make sure you link your proposal from the etherpad).

Goal

Brief explanation

Expected results

Knowledge Prerequisite

Mentor

When adding an idea to this section, please try to include the following data:

if the application is not widely known, a description of what it does and where its code lives a brief explanation
the expected results
pre-requisites for working on your project
if applicable, links to more information or discussions
mailing list, githut repo, or IRC channel for your application/library/module
your name and email address for contact (if you're willing to be a mentor)
If you are not a mentor but have a good idea for a proposal, get in contact with relevant parties to find one.

[add your project below]

Test the Web Forward: Test Results Progress Dashboard

Goal

A website that can be used to compare the results of running web-platform-tests across multiple different browsers.

Brief explanation

The Web Platform Tests project is a cross-browser testsuite for the web platform. It is designed to improve interoperability between different web browsers by allowing them to check their implementations of various specs against a testsuite.

In order to run web-platform-tests in browsers a couple of tools have been developed. The first is a semi-automatic in-browser runner that produces JSON output by default. The second is wptrunner, a fully automated runner that produces mozlog format messages as output by default. The latter is being used to run the test in several browser CI systems (notably those for Gecko and Servo).

At the moment there isn't a good system for visualizing the results of a specific test run (e.g. to tell where a browser is not matching the spec) or for comparing between different browsers (in order to tell where tests are broken across many browsers possibly indicating a test bug or a spec bug). The Test Results Progress Dashboard project is to develop a Web dashboard that can ingest the output data from wptrunner and allows comparisons between multiple result sets (e.g. between Web browsers).

Expected results

A server-side component that can ingest data from a wptrunner run (and perhaps an in-browser runner run) and store the results in a database, retaining the information that is required for the subsequent display. Initially this can just require manual specification of the log files (note that in the case of e.g. gecko there is > 1 log produced per run due to test chunking; this needs to be supported). Some consideration needs to be given of the metadata required to identify the browser version that was being used and the version of web-platform-tests that the browser was being run against.
A web front end that can display the results of a particular run in a specific browser. This must be able to work efficiently with a subset of the data i.e. it must not be necessary to download and display the results of all the tests in order to see the results of a subset of tests.
Extensions to the web front end to allow comparisons between various sets of results e.g. to see results that changed between two different runs, or all tests that fail in 2 or more browsers from a given set of runs.

Knowledge Prerequisite

Server-side web programming (Python)
Some database knowledge.
Client side web programming (HTML, Javascript, etc.)

Mentor

Philippe Le Hegaret and James Graham

We use IRC #testing and public-test-infra mailing list for communication.

Test the Web Forward: Automated JavaScript API Test Suites

Goal

Automate the generation of JavaScript APIs test suites from W3C specs.

Brief explanation

In W3C specs, JavaScript APIs are described using an interface definition language called WebIDL. WebIDL snippets found in specs are already used to manually generate test suites thanks to a WebIDL parser and a dedicated test harness. However, these test suites are generated by hand, and need to be manually updated every time the spec changes. This is of course error prone. It's not uncommon to see specifications and test suites drifting apart. Oftentimes, test suites aren't generated for certain specs because editors just lack the knowhow to build them.

Through automation, these test suites can be programmatically generated and kept up to date provided minimal initial input. This project consists in setting up this system on top of existing infrastructure build in node.js and improving the current test harness.

Expected results

A node.js application which generates Web IDL suites from a database of WebIDL snippets and keep these test suites up to date as the WebIDL snippets evolve over time.
A standardized system for communicating the minimal data needed for these test suites to be generated (in spec, through a manifest file, tbd).
Improvements to the test harness to provide more thorough testing and make the results more palatable.

Knowledge Prerequisite

JavaScript & node.js
HTTP APIs
Manipulating ASTs
Git and GitHub

Mentor

Philippe Le Hegaret and Tobie Langel

We use IRC #testing, public-test-infra mailing list and GitHub Issues for communication.

CSS Validator calc() support

Goal

Implement the cacl() expression in the CSS Validator

Brief explanation

The current version of the CSS Validator does not yet validate calc() function. Doing so would be helpful as the use of calc() in real-life CSS style sheets is becoming more common. The work requires finishing the type checking capabilities of the CSS Validator, as there are checks for type compatibility in an expression, and implement the validation algorithm in the parsing code (The parsing stub is already written, using JavaCC). Once it is implemented, the calc() value should be allowed in many CSS properties, for CSS Level 3 and above.

Expected Results

Be able to correctly parse assertions, and report meaningful errors (There will be positive and negative testing).

Knowledge Prerequisite

Java Programming (skill level: High)
CSS

Mentor

Yves Lafon. We will use IRC and www-validator-css@w3.org mailing list for communication.

Alignment of Cordova APIs with W3C APIs

Goal

Aligning APIs used in the official Cordova plugins with their equivalent APIs standardized in W3C.

Brief explanation

Cordova is an hybrid application development framework: it allows developers to write a single code base in HTML and JavaScript and compile it into native applications on a variety of native platforms (iOS, Android, Windows, etc).

One of the stated goals of the Cordova project is to serve as a stop-gap solution to the development of pure Web applications targeting mobile browsers.

To ensure a smooth transition between hybrid and pure-Web development approaches, it is important to keep the APIs for advanced capabilities provided by Cordova aligned with the equivalent APIs standardized in W3C.

To that end, a collaboration effort between the Cordova project and W3C has started, with a known list of opportunities for alignment.

The goal of this project would be to provide patches to the main Cordova plugins to get them aligned with W3C APIs.

Expected Results

one or several official Cordova plugins aligned with W3C APIs
documented approaches to facilitate further alignment

Knowledge Prerequisite

JavaScript
Basic knowledge about Cordova as a development framework
ideally, some experience with one or more native development languages (Objective C, Java, C++)

Mentor

Dominique Hazaël-Massieux <dom@w3.org>. We will use IRC, github and other online communication systems for communication.