W3Conf has industry leaders speaking on a wide variety of topics that every developer needs to know: HTML5, APIs and Javascript, graphics, accessibility, CSS, and much more.

We have selected speakers on an invitation-only basis to deliver the most educational and entertaining experience for our audience on the topics we felt were the most pressing for Web developers and designers today.

Focus on why developers are key to W3C and the future of the Web. W3C doing standards since mid 1990s – learned a great deal in that time: You have to have the right people involved. Who the right people are changes over time. Consensus building takes a lot of time, but you can’t let it go on forever – there is a balance. Royalty-free patent policy is important. Use cases and real-world developer stories are needed. Tests are needed for proper implementation. Developer buy-in is very important.

Community groups – important for bringing new work to W3C. This conference is a call for action – for web developers to get more involved in W3C.

Video of Tim Berners Lee (W3C):

Asks people here to have fun. Keep the Web open – use open standards. Do really exciting things – HTML5 and Web Apps – the platform allows you to do things that were only possible via native apps before.

Try to focus on Web Apps – not native apps. Being part of the Web is more powerful than creating siloed apps. Bit by bit – everything that you can do on a native app, you will be able to do via a Web Apps. By making Web Apps – you are helping to keep the Web open.

Keeping the Web open has always been a battle – we have to fight for openness.

Asks audience to raise their hand if somebody has ever logged a browser bug (very few people raise their hands). “How many of you expect the web to work?”. Laughs from the audience.

Shows a testing example on CSS – asks audience what’s going to happen. Nobody seems to know. Different browsers show a different result… 25% of browsers will not work. This is what we would like to improve. Replaces test DIV elements with SPAN elements… invalid document, but will still render, but not exactly the same.

When testing, you find yourself in a lot of situations where it’s difficult to tell what should happen. We are not testing one spec with HTML5 – we are testing CSS, HTML5, JavaScript APIs, lots of things. Different levels of stability – difficult to synchronize between specs. Need web developers to participate.

Is testing to perfection possible? No. Testing is an approximation.

Lots of it can be automated, but a lot of it cannot. We need help testing plenty of combinations – HTML, HTML+SVG, DOm manipulation, CSS combinations. We’ll never get 100% coverage – but we still need to set a goal. Who are we testing for?

We are testing for the people that use this technology – manufacturers, spec editors, content providers, people using the Web… etc.

We’re back with Doug Schepers, SVG, Web Apps, Audio, that will be talking about Web Education. “Who here has used the Web?”… “How many have programmed for the Web?”.

“How many people learned the Web via ‘view source’”? Just about everyone raised their hands. “How many of you still do that?” Most dropped their hands.

The Document Web was pretty easy to learn. In 2000, we started to get the application Web. Media Web, Social Web… you have to learn a lot in order to be able to do these things. People can’t read standards – they’re really difficult to read.

WebMoney came early on. W3Schools, W3Fools.com is a good site. Opera Web Standards Cirriculum, SitePoint, MDN, Google’s “Ground Up” Videos. Tons of other sites – not just HOW-TOs, but help more.

At universities you learn serious programming languages like “lisp”. Laughs from the audience. Web Standards Project is great, InterAct Cirriculum is great – teachers can take these cirriculumns and plug them into their classrooms.

W3C has tutorials and primers, podcasts and videos. The W3C wiki has a bunch of resources, HTML5 reference guide, CSS reference guide. The problem with W3C’s documentation is that it’s scattered everywhere. Internationalization documents on W3C site.

Web Education Community Groups – launched to focus on learning material, curriculum, outreach, training, international resources. Trying to improve teaching resources at W3C. Why should people get involved in Web Education? Many eyes, pay it forward, reap what you sow.

How to help: write articles, review articles, help write curricula, help translate.

We started the Web as a hobby. We need to change it from a hobby to a craft. Make it easy to learn the basics, need smooth transition from casual development to career. Web developers learn throughout their lives – we hope these resources will persist and keep getting better.

Canvas – pixel-based, you write scripts to draw what you want. You create a context, set it to 2D or 3D, then you specify drawing commands (draw an arc, fill with color, etc)

Canvas – more difficult to detect where events happen in your object – you have to write that code. SVG – events are tied to graphical objects. Easier to do event inputs via SVG – but both allow you to have very fine grained control over your graphics with either.

Scripted animation is still in the works – but you have scripting APIs today. Canvas uses scripts for animations. With SVG you can use CSS animation, scripts, and declarative animation with SMIL. All browsers except IE support SMIL. Declarative animation allows you to morph geometry between objects.

Timing – you can time animation events and chain them together via SMIL pretty easily. You can style SVG using CSS, just like any other HTML document.

Multimedia integration –

You can also do video in SVG – Video element embedded in SVG document, you can apply filter effects to SVG – filter effects apply in real-time. Foreground decorations with SVG – looks really nice.

Why two different models? Canvas is low-level, pixel access. SVG is very high-level, nice API, DOM events, etc… but no pixel access, can be limiting. There are good reasons to have both. Graffiti Markup Language – uses SVG and Canvas together.

Page Visibility API – helps you figure out of the page is visible or not – helpful to know if you need to keep running animations/etc. Ready in March 2012. In use on Google Analytics (count impressions correctly – page isn’t counted if page is opened in a tab that is never looked at), YUI Idle Timer, Google.com Instant Pages loads pages if it can predict if you’re going to click on a link (loads in the background).

Question on Usability Testing and improving the browsing experience. Yes, the Timing APIs can be used to figure out how long it takes for someone to click on a piece of a page.

Question on using image bundles or not. Google performance testing has shown that it depends on the types of images – large image bundling is bad. Tiny image bundling is good.

Great criticisms of the Web – it only works when you’re online. Not necessarily true.

For Appcache to work – create an appcache manifest file and link it to your HTML file. You have a file with a .appcache extension – appcache file has sections for cache, fallback and network.

Cache section – which resources must be cached.

Network section – which resources must NOT be cached.

Fallback section – which resources should be used for anything that is not cached and when you’re offline.

Gotchas: Appcache manifest must be served with text/cache-manifest. New-ish technology. Cache failure if one resource is not available – must verify your cache. Appcache is cached forever – when developing, don’t use appcache. Only things that are explicitly cached are available – must be explicitly included. There is lazy-caching, other cache controls in use in the browser may cache other files.

Do not develop with app-cache turned on.

If you change the contents of the appcache, it will be refreshed. Use #version 1.0. Some browsers limit to 5MB-10MB.

Appcache is supported in all modern browsers.

ManifestR creates a manifest file for any web page you visit – helpful for starting with AppCache development.

Up now, the Great HTML5 Divide by Ray Bango of Microsoft. Works on jQuery, HTML evangelist. HTML5 is great, it’s definitely the future, but there is a divide. Talking about browser fragmentation today, feature detection, polyfills and shims. How do you leverage HTML5 and CSS today? Solutions will be provided.

Biggest problem now is non-modern browsers. caniuse.comis a good resource for figuring out which browsers support. Lot of browser fragmentation, across browsers, within the same browser, different versions.

Feature detection is a good thing – do it. Don’t do browser-based detection.

Modernizris great for feature detection – detects all major features for CSS3, HTML5, etc.

Polyfills and shims – polyfills are used to fill in cracks – shims fill in cracks. SVG support, Web Storage, WebSQL, WebSockets, etc. Consider 3rd party library– developers may not want to support it anymore.

Next up, Christopher Slye from Adobe to talk about Web Typography. Involved in WOFF standards group. Two real font formats – TrueType and PostScript. Going forward, quality will be about the same. EOT is Microsoft’s font container – been exclusively for Internet Explorer. WOFF is new Web font format – will be the first interoperable Web Font Format.

WOFF is a compressed font container, has font metadata. CSS3 Fonts Module – contains entries for properties size, weight, style. OpenType has nothing to do with the Web. Kerning, ligatures and alternates.

Next up, Paul Irish from Google talking about The Foundation of the Web Platform – HTML5. Talking about HTML5 underpinnings – on the jQuery team.

Explains that came about because browsers don’t really care about all of the variations and that all of the variations are difficult to understand for Web developers. was introduced because of a security vulnerability in UTF-7 and script tags.

Browsers used to parse broken markup in a different way. Now they all parse broken markup in the same way. There are optional tags – html, head, body, etc.

You can not use quotes in HTML5 attribute IDs, you can use many UTF-8 characters (like hearts and the unicode value for a snowman).

The HTML5 spec is a repository of valuable browser knowledge – acquired through copious reverse engineering.

Current presenter is Giorgio Sardo, doing a great job showing off the power of HTML5 today. Showing off the need for multi-touch events – talking about mobile phones or large screens shared among different people, running HTML5 Apps.

Moving on to WebApps and the File API. Showing drag-drop of files from the desktop to the browser window. Drag-Drop API allows you to take files from the desktop and drop them into a web page – file information and the byte stream is made available to the browser. Web Performance API allows you to know when someone isn’t viewing a page and allows you to shut down processor intensive or battery draining portions of Web Apps.

Mike Bostock is up now, talking about Data Visualization with Web Standards. We should not put a focus on charts and graphs, but rather visualizing information in a way that is closer matched to the data we’re trying to understand. D3.js – Data Driven Documents.

D3.js looks at data visualization as a document. Map a quantity/value to a symbol then render. decoupling data from visualization. D3 mixes SVG, CSS and HTML togetherto build beautiful visualizations – for example hierarchical data sets can be visualized as hierarchical bar charts, or bubble graphics, and smooth transitions between them.

Showing off how D3 also allows you to do interactive visualization – select part of the data set, see highlights elsewhere in the data set. The tools we create don’t exist in isolation – combining SVG + Canvas + CSS allow us to create very compelling visualizations.

Issues with Accessibility – Vision issues, Mobility issues (not everyone is able to use a mouse), temporary disability, learning disabilities, hearing disabilities, age. Eventually all of us age – every one of us will have accessibility issues.

Why care about Accessibility? Government/legal reasons, monetary reasons (1.75B of disposable income from people with accessability issues), independence, altruism – it’s the right thing to do. People with disabilities don’t want a hand out, they want your respect.

Enabling Accessibility. Use semantic HTML, use alt-text on images, label form elements, add keyboard support, use tabindexes, support high contrast mode (all background images are removed).

ARIA Roles landmark the main roles on the page – banner, main, navigation, search, form. Popular screen readers support landmarks. ARIA Presentation role – preferred way to say that something is being used to present some information?

ARIA states and properties. ARIA allows one to specify that a region of the page has been updated and how one should be notified that it’s been updated. For example: “aria-live=”assertive” aria-atomic=”true”. aria-required indicates that a field is required. aria-invalid tells us that something someone has entered is invalid.

The future – mobile – VoiceOver screen reader and ARIA support is in Safari – iOS has the accessibility advantage right now. Intent-based Events – how do you do generic events?

Up on stage now – Brad Hill from PayPal and Scott Stender (iSEC Partners) talking about Web App Security. We need a way to protect information from prying eyes on the Web. New threats are client-based – Cross-Site Scripting and Cross-Site Request Forgery.

Same-origin policy guards against most attacks. Most attacks can be prevented on the Server-side. Conventional wisdom: Never trust the client – Defend the server, at the server. Web Security 1.0 puts up defenses at the server. Client Code Injection – DOM Cross-Site Scripting – you can use fragment identifiers to attack sites now because of JavaScript running on a page.

Big security vulnerabilities are now showing up in native apps that wrap HTML containers. When there are no servers, and you have stuff running on your local system, a script-injection attack can take files on your hard drive and send them across the network without your knowledge. Demo of Skype window sending passwords to attackers based on a JavaScript attack.

Old clever tricks – like script tags, iframe elements, JSONP are mature, but you have to understand what security model you’re signing up for– you’re effectively giving the source of a JSONP data/iframe check-in rights to the code on your page. So, if you use these clever hacks, be careful how you do it and who you do it with.

New features coming up that help web security – CORS, XHR2, WebSockets – powerful tools. Auditing is more difficult with these new technologies. postMessage (communication between two tabs in the same browser) and Web RTC (real-time data/media streams). These technologies, while very cool, open up the attack surface on the Web App.

Assets and attack surface are moving to the client, but the focus is still on securing the servers. Future of Web App Security is in the client, not the server. We are falling behind on making sure we’re securing our Web Apps.

What can we do to mitigate these threats? Comprehensive testing/verification, do tests on production code. Get rid of built-in “Game Over” security threats – JSONP is bad, plaintext HTTP is bad. Create code that is designed to be securable– compartmentalize the code, decouple the code, be explicit, do test-driven design.

Grant Goodale up now from Massively Fun (@ggoodale) to talk about touch events. First touch API appeared in iOS 2.0, now a part of the HTML5 spec.

Many differences still exist between vendors – many of the browsers don’t support it yet, but there are lots of mobile browsers that do support touch events. Many different types of input, you want native-like behavior. Firefox supports touch events.

Traditionally worked with Flash – moved to working with HTML5. Games on the Open Web today and in the future.

What do you need to make a great game? An idea – you can be inspired by the technology you have available to you. Can we design games designed for the Web? Loading – critical piece, how do you get the game onto the client? Monitoring progress is difficult in games (no clear standards to see how long it’ll take to load everything).

XHR2 is great because it has progress events – ability to load in binary assets. caching – minimizes bandwidth/connections – cache manifest is good, but it’s an all-or-nothing solution. If you change the cache manifest, everything downloads again. HTML5 local storage is good, tricky to store non-text assets, low-level way of supporting cached data – lots of custom implementation work.

Graphics – lots of options. DOM and SVG is good – interaction model is good, ubiquitous, hardware accelerated… but high overhead (can be a performance killer). Hardware acceleration works really well for Canvas, not so great for SVG and the HTML DOM. WebGL (based on OpenGL ES2) – fast, low-level hardware graphics, 3D vertex shaders, extremely sharp learning curve – Three.jsmay help, but still very difficult to use. Canvas 2D is broadly available, including mobile, consistently implemented, easy to get started with, increasingly performant.

Combining surfaces is good– combine Canvas and SVG and DOM. HTML DOM does the UI very well – all UI in their games is done with HTML – use Canvas/SVG for graphics. Using pluggable renderers – you can switch between three.js, EaselJS based on your platform – write the content once, pick the renderer based on the device.

Sound is a little more challenging in games right now– audio tag is broadly supported, but suffers from browser-specific issues, latency, codec support, maximum number of audio elements (arbitrary). Using solutions like Flash, SoundJS, SoundManager2 allow you to launch with good audio today. Sound sprites, like image sprites – one very long audio clip with gaps, use JavaScript to see and play different parts of the audio track.

The Web Audio API is coming– very powerful API for real-time audio manipulation, runs at native speed, synthesis, analysis, mixing – limited support now, but will solve a ton of problems.

Basic interaction – keyboard capture is incomplete, but mostly adequate. Mouse interaction is fine for point and click games. WebGL and Canvas require custom handling of mouse events. Full-screen and interaction API is a bit quirky. mouse lock and synthetic mouse events are necessary when you want the cursor to go off-screen and still generate mouse events (which you need to do in first-person games when walking, running, navigating).

Code authoring – JavaScript performance has gotten faster, IE has improved the most, but many browsers are doing great work with JavaScript performance. ECMAScript 5 is good – strict mode should be used. New features in ECMA5 – seal, freeze, prevent extension for objects, property descriptors allow you to specify when a property should be writable, readable, etc. There are still challenges: no type safety, no interfaces, limited inheritance, no super() – difficult to write a big game engine w/ JavaScript. JS is great for hacking together a game. Some solutions – Google Closure is neat and a good IDE, cross-compilers – Haxe, CoffeeScript, Jangaroo– compile down to JavaScript.

Tools – good dev tools – WebStorm, debugging tools are good, profiling is good for JavaScript – not so good for profiling graphical processes. WebGL inspectoris really neat, lets you see where a single pixel came from in the code.

Chaals (Opera) bad authoring is worse, so is bad Web teaching, we need a mechanism for innovation – vendor prefixes are terrible, except for all of the other things we tried, which are worse – sunset the vendor prefixes.

Paul Cotton (Microsoft) we want vendor prefixes to be taken out when we go to Candidate Recommendation status – we need to get to CR faster, we need to do our specs in a much more modular fashion. Part of the standards process is at fault here – standards need to move faster.

Tantek (Mozilla) The better that we can get about dropping vendor prefixes, the better. Vendor prefixes suck, but it’s the best we’ve come up with so far– we could do better – we’re all open to suggestions on this point.

Paul (Amazon) Vendor prefixes are a form of technical debt, you have to pay it down eventually.

Tantek asks why VIDEO element didn’t have a vendor prefix – but it still worked… why?

Chaals: It was easy to understand what Video should do.

John Allsopp: It had a good fallback.

Tantek: Video wasn’t easy, but we got it right – why was that? Arguing on stage

Chris (Google) – Chromebook is just the Web layer, you can replace the OS if you want to– there is choice there.

Paul (Amazon) having HTML5, creating a true application environment – maybe the model of using the OS as the browser is terrible.

How do most of the regular web developers know what should be used and what shouldn’t?

Chaals (Opera) All of us building the Web need to go out and learn and teach other people. There is nobody spoon feeding information to you – this field changes so quickly – look around to your peers, they will help you.

Paul (Microsoft) Browser vendors need to hang out with one another – we need to work together, get things done. Community Groups at W3C are going to be key – get groups going with least amount of overhead, understand what minimum required to get a spec done is needed. The way we’re dealing with the HTML5 spec is bad – it’s a flawed way of working on a standard. We will continue to work together at W3C. We have a real obligation to the community here.

Tantek (Mozilla) – it’s not sufficient for browser vendors to work together – we need to work together IN THE OPEN.

Is there any plans to replace JavaScript?

Chris (Google) One of the goals behind DARTwas to provide something simpler.

Chaals (Opera) it would be terrible if the solution was not interoperable.

Paul (Microsoft) JavaScript will become “copper pipe” in 5-6 years… it’ll be what we use just like we don’t think about processors and compilers today.

Privacy –

Chaals (Opera) different societies define privacy differently, difficult to start the work when you don’t know where you’re going.

Chris (Google) people should have the tools to control their own privacy, you can’t just leave it to the end user.

Doug (W3C) Good work on do not track, cryptography going on at W3C.

What about internationalization?

Paul (Microsoft) We need to be able to ship browsers worldwide – how to bring rest of the world into the conversation.

Tantek (Mozilla) There are 70 versions of localized Firefox browsers – built by the international community. Customized for specific locales and markets.

Women in browsers, why are they not represented?

Paul (Microsoft) I work with 2 women on my team, 3 men. More women attending at TPAC, this is a good sign.

Chaals (Opera) different societies have different levels of participation.

Paul (Microsoft) Women are certainly welcome here – we want much broader participation than we have now. I think some of the problem is societal, it’s not a social norm in the USA – we need to get better about teaching science and math to he smarter of the genders.