Pushing the Cutting Edge Forward with Web Standards
A little story
My first website
Looking at my code
What I learnt
- Cut down debug time
- Better evaluate frameworks
Influence Web Standards
- Speedier Specification process
- Stop others from making the same mistakes
- Get the features you want
- More tests = Fewer Browser bugs
- Writing tool extensions, polyfills drive adoption
Make the web easier for you
Be involved in the direction specifications are taking
Compliant User Agents must implement.
Each feature has restrictions on what kinds of values it can have.
Browser Conformance Requirements ≠ Author Conformance Requirements
Who writes these specs?
Specs developed within Working Groups
Each Working Group officially consists of representatives of organizations
Sometimes, an Invited Expert is asked to contribute
Most activity occurs on emails, IRC channels, weekly teleconferences or quarterly face to face conversations.
In the Open
- Everyone can give feedback
- Everyone can read emails, or hang in the IRC channels (especially during weekly teleconferences)
- Your opinion (if expressed with right intent) is valued
When is a spec ready to use?
Officially when a spec is a recommendation
First Working Draft
→ (discussions/iterations on Editor's Draft)
→ Candidate Recommendation
→ Proposed Recommendation
- Namespaces: 1999 → 2011 (2002: Mozilla 1.0)
- Colors: 1999 → 2011 (2008: Safari 3.1)
- Media Queries: 2001 → 2012 (2008: Safari 3.2)
- Selectors Level 3: 1999 → 2011 (2008: Safari 3.2)
- Backgrounds & Borders: 2001 → 2012 (2008: Safari 3.1)
It gets better!
- Regions: 2011 (2011: Chrome 15)
- Grids: 2011 (2011: IE 10)
- Variables: 2012 (2012: WebKit Nightly)
- Device Adaptation: 2011 (2011: Opera Mobile 11)
(in my view)
- Stable Syntax
- Stable implementations in 3 or more rendering engines
- Consistent behavior in all of them
- Minimal failure in non-compliant browsers
(or a good fallback story)
How to participate
- Read specs & ask questions
- Document what you have learned
As a Web Developer
If you do not understand what the spec intends or means
If you find some feature hard to use
If some feature does not cover an obvious use case
Test features and verify if they work as intended
As an API Designer
'This API sucks!'
Look at HTML Design Principles and see if the API can be made better within these restrictions
'This should have an API'
'This syntax is contrary to everything a good syntax should be'
Ask on mailing list noted on the spec in the Discussion on top of the spec.
How to ask such that you get a response
Search mailing list archives
Write in plaintext (seriously)
Inline quote your response within the context of what you are responding to
Always cite reference to any assertion you claim as a fact
Show you have done the work to find a solution
Found a bug?
Is this a bug in the specification or the browser?
Has this bug been reported?
Manage your time
Filter all emails from standards mailing lists
- File a bug report
- Write a test case
- Give Feedback on a feature/spec
- Document one property/API completely on webplatform.org
- (stolen from @hober)
Document the Web
Join webplatform.org & start contributing.
Questions? Ask on IRC #webplatform on Freenode
What can you do?
- Read the Editor's Drafts
- Test features of the bleeding edge
- Write about what you learnt
- Give feedback to Specification authors
- Write tests
- Participate in hackathons like@testthewebfwd!
Follow on Twitter