Kennis W3Conf 2013 - Day 2

W3Conf 2013 - Day 2

Thursay Febuary 22nd, San Francisco CA

W3Conf is W3C’s an­nual confer­ence for web pro­fes­sion­als who want­ to hear the lat­est news on HTML5, CSS, the open web platform and their place in it...

See day 1 resume here

Yesterday was a very interesting day… so expectations are high for today! Here we go!

Beyond Play: The Art of Creative Coding
Joshua Davis (@joshuadavis)

M. Davis is a creative coder and artist that has been involved with web technologies from the very beginning. Amongst other things, he was inducted into the Smithsonian digital museum and he designed the face of Watson, IBM's super computer that was on Jeopardy (remember?). He writes programs that generate art. Specifically vector based creations. His talk is centred around the relation between work and play. Part of playing is not knowing if things will work out, but trying them out anyway… Playing is also about hunting for inspiration. Finding things that spark an interest and turning them into something creative. Play becomes inspiration which turns into work.

A few tips:

  • Give yourself projects. Usually the harder they are, the better the results will be.
  • Keep it simple. You have to like the process, try things and don't be afraid to fail. Breaking things, mistakes and failures often lead to new discoveries.
  • The type of work you make is the type of work you'll get hired to do. So make sure you do what you like.
  • Embrace collaboration. Working with others bring new ideas, new perspectives. Sometimes collaboration is not working with someone side by side, but simply interaction, like when the public has an impact on your creation.
An interesting quote:

"Work and play are words used to describe the same thing under differing conditions" - Mark Twain

I found this talk very interesting and inspiring. To have a playful approach is motivating and leads to new discoveries, enriches your creativity and helps you do things you like doing… Have to reflect on how I apply this more in my daily life.


Design like you give a damn: Practical accessibility for web professionals
Léonie Watson (@leoniewatson)

Léonie's talk centres on accessibility and is an accessibility consultant at Nemensa in the UK. Inclusive design is another word for it. She likes to say: Design like you give a damn… A few preconceptions: Accessibility kills creativity / it should spark it. Accessibility is hard / so is adapting your content to all platforms, you get used to it.

In her talk, Léonie reveals a lot of the issues that users with disabilities face. When designing try and see how you would navigate your site if you don't see well. Or try to navigate it without a mouse. Or with a screenreader. What happens then? Can people with disabilities access your content? Can they navigate the site? Can they fill in the forms? You have to take all these things into consideration when prototyping, designing and building. And then test as if you were one of your potential users.

Screen readers have evolved considerably in recent years. It used to be that you had to go from top to bottom through the whole content, which could be extremely long. Modern readers have shortcuts that allow for a quick identification of headers, lists, forms, etc. HTML5 landmarks and areas allow for further content identification which enable visually impaired visitors to quickly make a mental map of the website in front of them...

This talk really underlines how little I know personally about creating products that are accessible to all potential users. It is interesting to see that a lot of accessibility principals overlap with standard usability. I hope to get an opportunity to work on an accessible product sometime in the future to try and come up with creative solutions to some of the challenges presented by accessibility.


HTML5 Security Realities
Brad Hill (@hillbrad)

Contrary to what a lot of security people seem to think (, HTML5 is a big step forward in securing the web. It is true that HTML5 adds a lot of new features, which of course lead to new attacks. So because of this, it may seem like HTML5 is less secure than HTML4, but then you are actually comparing apples and oranges... To be fair, you should actually compare HTML5 with HTML4 with all the different plugins that are used out there (ActiveX, Flash, Java, etc..). Since plugin vendors want as many developers using their plugins as they can get, they will let developers do pretty much anything, even if it makes the web less secure. On the other hand browsers compete for users, so they try to make the browser as secure as it can be.

Script injection is one of the biggest problems on the web. 'If someone else's code is running on your web app, it's not your web app anyone'. Current defences include input filtering and output escaping. But Brad explains how XSS filters were doomed to begin with. They all work by simulating the HTML parser in the browser. So you need to keep your XSS filter up to date when browsers change. Brad also shows a XSS example from the 'Web Application Obfuscation' book which fails in most XSS filters.

Luckily with the new 'X-Content-Security-Policy' header XSS can be something of the past. This new security feature is actually quite simple. It tells the browser what resources it should trust and which it shouldn't. Since this works by whitelisting certain URL's, you can't use inline JavaScript or CSS. Another great benefit of this new feature is the possibility to report any XSS implications to an URL you specify. So if someone tries to inject a script you will know where it happened and can act on it. Besides XSS filters, templates are also simulating the HTML parser. Currently there is no fix for this, but there is work going on with native template support in browsers.

Cross origin resource sharing is another big security problem. A lot of sites include snippets from other websites, for example all the social media widgets. You might trust the big companies like Google, Twitter and Facebook and allow their scripts on your site. But even their scripts may not always be secure. Like some time ago all sites that used Facebook integration broke because of a bug in the Facebook JavaScript code. Combine this with the recent hack at Facebook and you can imagine the great security risks. A solution to this problem is Cross-origin resource sharing (CORS). CORS allows you to make XMLHttpRequests to another domain, which would otherwise be forbidden by web browsers. This means we don't have to use the insecure JSONP anymore. Besides CORS you can also use sandboxed iframes and use postMessage to communicate between them. All of these features are a great way to improve web security...


Fluid User Interface with Hardware Acceleration
Ariya Hidayat (@ariyahidayat)

Current smartphones are very powerful and allow for complex and smooth graphics. But even simple animations perform poorly in the browser. So what causes this difference between native and web application performance? The answer is actually quite simple, browsers don't use the GPU enough. As you might know CPU's aren't very good at rendering animations, this is what we have the GPU for. If you want to force the browser to use the GPU, then the oversimplified answer is to use 'translate3d' (luckily some CSS properties (CSS animations/transiation) already force the use of the GPU).

Even though GPU's rock at rendering animations, they also have their limitations. Ariya gave a great comparison; You might have a super fast car, but when you are in a traffic jam it won't go fast at all. The same applies to a GPU, if you 'upload' to many render jobs to the GPU it will eventually bog it down. Ariya suggested to look at the GPU as a cache, prepare and reuse. If you want to do this you need to know which CSS properties cause the browser to re-upload a job to the GPU:


  • No re-upload, opacity, position, size, filter
  • Re-upload, everything else

So lets take a simple sprite animation. One way to make this work is to change the sprite background image every 100ms. This means the GPU will need to render the image every 100ms, indefinitely. Another way is to put all the parts of the sprite on the same position and use opacity to switch between them. This causes every sprite part only to be rendered once.


Device (dis)orientation?
Luz Caballero (@gerbille)

Luz used to do developer relations at Opera. The talk is about device orientation. Orientation is not about landscape or portrait as you may think, but about the angle of the device (think of the pitch, yaw and roll properties of an airplane). HTML5 gives us some new API's to not only work with device orientation, but also motion (acceleration). The actual new events (on the window object) are;

  • deviceorientation
  • devicemotion,
  • compassneedscalibration,

The DeviceOrientation event returns three bits of data;

  • alpha, the direction the device is facing according to the compass
  • beta, the angle in degrees the device is tilted front-to-back
  • gamma, the angle in degrees the device is tilted left-to-right

Using this data requires some advanced math, luckily many libraries abstract this away for you and allow you to pass values as parameters (for example three.js allows you to rotate an object by invoking a method with the three values).

Support for this feature seems good, but in reality there are many differences between browsers. When Luz compared the different browsers that implement this feature (according to with the specification, it  became clear that not all browsers implement the specification correctly. There are even differences between browsers on how to correctly hold your device in landscape mode (plug to the right or to the left?). Some browsers think that the top of the phone should be on the right, others on the left.

The only way to work around these differences is to hardcode the differences in your application and use it to transform the event data. But this of course backfires when the browsers update their API. Another solution is to build your own calibration system, but this is a lot of work. So it seems we need to wait a bit longer until we can use this new API effectively.


Mobile Web: Real Life Examples of HTML5 for Mobile
Tomomi Imura (@girlie_mac)

Tomomi is a front end engineer at Nokia (she's also a HTML5 evangelist there). Smart phones have evolved incredibly in the last 10 years. Processors, displays and memories are now better than desktop computers were back then. We use our mobile devices today to communicate, read, play games, take pictures, locate yourself or things, paying with NFC and more (music, browsing, taking notes, chat, video calls, scanning, translating, etc.).

Tomomi shows an app she made to showcase the HTML5 features that can be utilised for mobile. The app is a sort of instagram where you can call upon the camera and then do some pixel manipulation through filters. She then proceeded to give a lot of details about browser support (or more adequately: lack there of) and specific code choices so that performance is optimal.

I don't know, maybe it's just me getting tired but ZZZZZZzzzzzzzzzzzzzzzz

I guess what we have to take out of this talk is the great possibilities HTML5 is giving the mobile platforms. Support is not yet universal for many of the most interesting features, but it is evolving. If you want to check the presentation out in detail, by all means:


Questioning best practices
Nicolas Gallagher (@necolas)

Works for Twitter and will talk about the purification of web development. Coming originally from the realm of anthropology, Nicolas likes to look at assumptions and the history of ideas. Nicolas exposes us to the thoughts of some little known early greek philosophers and how their ideas where forgotten until recently. Plato and Aristotle rejected their ideas because they didn't make sense to them, but some of those ideas make sense now (one of those ideas was that everything in the universe is dynamic vs. the thought of the time which tended to describe mater as static).

Best practices are based on the idea that there's a universal truth and this idea fails to reflect the reality that context changes all the time.

When CSS1 was added to HTML the idea was the HTML should never change but that the CSS would make the change. Nicolas gives example of how the original rules that applied to the first generations of visual websites do not make sense today since so much as changed.

Several specific examples are given… for example the lower case and hyphen standard might become very difficult to read since components, component modifiers and component child are not obvious at fist glance. An 'ugly' name class can indicate clearly what the intent is. This is especially practical when there are very many to deal with.

The message is to revisit what you assume to true once in a while, because in our industry, context changes so very quickly. It is simply wrong to assume that the 'best practices' of years ago still apply at all.


The Era of Intentional Layout
Eric Meyer (@meyerweb)

In the beginning, Tim said "Let there be markup.", separating structure and styling.

Back in the days of Mosaic, users could change they way HTML was displayed themselves (for example the font size of headings). This wasn't possible for developers. Even the HTML specification didn't require any specific styling, it only said how a typical heading (or any other element) would look like.

When Netscape came around, it added a lot of visual extensions; size, alignment, etc. Which broke the separation between structure and styling. These visual extensions didn't allow for an easy way to do layout, thus the only thing developers could use for layout were tables…

"Why did the web designer leave the restaurant, he couldn't stand the table layout"

Luckily with IE5 we got the first browser with (almost) full CSS1 support. Though it did not have support for layouts.. Yes we do not count floats, since they were never designed for layout (meant for images to float to a side and text flow around it). But the time without a good way to do layout is almost over! In the coming time we are getting not one, but multiple great CSS features to do layout (with Flexbox around the corner first);

  • Viewport units
  • Flexbox
  • Grids
End of day 2
So that was day two. Today was also quite interesting. We got to think about the place of 'play' in our work and how we could benefit from it. We got to reflect on how to make our work accessible to all. We had an in depth look at security implications surrounding HTML5. We got a wealth of information on the intricacies of designing content for mobile devices. The case was made for questioning best practices in our rapidly changing industry. And finally, we got a glimpse into the future of web design with actual layout features coming to HTML5. Not a bad day!
The conference was very interesting in general with all the talks being high level. I guess what I take away from the conference most of all is the fact that two currents are presently clashing... on one hand desktop browsers are submitting more and more to general standards and information is more and more concentrated and accessible. But on the other hand mobile devices are changing everything and are sending everyone to square one again, in a manner of speaking.
A few other things I took away, in bullet list form:
  • The type of work you make is the type of work you'll get hired to do. So make sure you do what you like.
  • The web community is strong and getting more unified. Together we can impose change.
  • The web is still a new medium and we are just seeing now the appearance of an 'optimized' reading experience that includes so much more than just text.
  • HTML5 and CSS3 allow for pretty much anything you want to do, as long as you have the creativity and time to see it through.
  • Accessibility is just good usability with a little bit more effort thrown in.
If you're interested, you can view all the presentations here


Oh yeah... and look who was sitting accross from us... Mr Tim Berners-Lee!