Improving Web Standardization
W3C
Improving Web Standardization
plh@w3.org
Improving Web Standardization
- Producing Specifications
- Achieving Interoperability
Part 1:
Producing Specifications
Goal: The Technical report page (/TR) should represent the Web
- Improving our editorial workflow
- Managing our repository of specifications
Editing the specification
Use a pull request workflow for editorial and substantive changes
- Facilitate discussions and reviews
- Merge when support
- Easier to switch to auto publish if your ed draft has builtin consensus
- Helps with testing (see later)
- See Workflow for editors and other contributors (work in progress)
Managing our repository of specifications
- over 6000 drafts on w3.org, including ~300 Recommendations
- Automatic outdating previous versions
- Managing versioning and links
Managing versioning and links
Note: this is work in progress. Report errors to webreq@w3.org
Future of /TR
- Incorporate the new links into our pubrules: what would you want to see on
the spec?
(see proposal)
- Revamp the main /TR page: allowing different views, tag filtering, etc.
- Next specification redesign in 2018
Reminder: Get Your Wide Review
- Start early to get reviews (shortly before CR is often too late to fix things)
- Publish often to get more eyes (don't let /TR decay)
- Put feedback questions in your specifications
- Leave enough time for the reviewers
- Use the "wide review" in your WD SOTD. Our tools will pick that up.
- Get your horizontal reviews (TAG, security, a11, i18n, ...)
Part 2: Achieving Interoperability
- Web stakeholders: Implementors, Specifications Writers, Documentation (eg MDN), Developers
- web-platform-tests, the testing open source project, is intended as a new stakeholder of the Web
Prior to 2014
- Groups were testing only to make the W3C Director happy
- Test suites were not maintained and abandoned after the W3C Recommendation release
- Browser vendors were testing in isolation... at best
- Difficulty to tell how well the Web was implemented
Testing Goals
- Improving the reliability of Web technologies by developing more complete tests suites both for a given technology and across several technologies
- Improving the quality of implementations of these technologies by helping vendors to detect bugs in their products
- Improving the data available to Web developers on known bugs and deficiencies of Web technologies by publishing results of these tests
- Open-source effort to build a cross-browser testsuite for the majority of the web platform
- Use GitHub for submissions, reviews and infrastructure deployment
- One repository for tests and tools
- WPT has been adopted by W3C, WHATWG, and ALL major browsers
Why use web-platform-tests?
- WPT folks know how to test the Web
- WPT folks want the Web to work, no exceptions
- A growing number of browser vendors are running the tests
- WPT folks have a lot of test infrastructure ready to use
- Your lifespan is too short to reinvent it
Current tests
- ~180 specifications are being tested
- Generate around ~1.3M results per product run
- encoding: ~900k
- editing: ~90k
- html: ~89k
- dom: ~59k
- WebCrypto: ~38k
W3C and Implementation Experience
(aka Candidate Recommendation phase)
- Is each feature implemented?
- Are there independent interoperable implementations?
- Is there experience at all levels (authoring, consuming, publishing…)?
Testing at W3C
- Don't wait for CR to worry about testing, otherwise your backlog will be too high
- Consider adopting a healthy testing policy, such as:
all changes made to specifications should have tests
- Using pull requests to edit your specs? link your edits with your tests
- web-platform-tests.org is our platform for testing so use it
Following-up
- /TR breakout session (by PLH)
- Testing session (by foolip)
Thank you,
and let's keep making the Web better!