At State of the Browser in London, a one day event in Conway Hall, organised by the London Web Standards team, eight speakers talked about recent developments in the web and web browsers. Topics included Service Workers, performance, responsive images, web ‘apps’ and new CSS features for responsive web design.

These are my notes of the day.

Fernando Campo & Borja Salguero – Firefox OS: not only promises

In their talk, Fernando and Borja of Telefónica’s Firefox OS team discussed what they have been working on and what their priorities are in terms of new features.

They said the phone is slow, as they focused first on getting it launched and focus now on making it better. It also has few apps, missing features and is hard to debug, but the team is working hard on making it better, faster and stronger.

Recent improvements

What they’ve been doing in the last half year to improve Firefox OS:

• There is an app manager which can be used from Firefox nightly. It helps to check the manifest file amongst other things. There is also a simulator, debugger (which works with either the simulator or a real device if you have one) and profiler (with which you can profile actions).
• In addition to that, two new measuring tools were launched that can help Firefox OS devs to improve performance: Datazilla and Eideticker (with which you can analyse ‘real’ fps)
• They have also introduced more APIs.

Ideas behind Firefox OS

Firefox OS is a project to push the web forward

Firefox OS, Borja explained, is really a project to push the web forward. To do this, Mozilla/Telefónica work together with a lot of partners. One improvement they want to achieve is the exchange of information between apps. Their solution for this is “Inter App Communication”, which helps apps ‘talk to each other’.

In the newest version, your phone will not be a thing you install apps on, it will be more like a browser. Because that is what Mozilla is good at, making browsers. The OS that doesn’t require you to install apps, completely changes the way we work with devices.

More is coming from the makers of Firefox OS, including FirefoxAccounts, your settings in the cloud, and project ‘Loop’ that employs WebRTC to let users call for free. There is also Project ‘Mulet’, which allows developers to do all things related to Firefox OS from the browser.

If we want to know more, Borja explained, there is a lot of documentation available on the Mozilla Developer Network, including screencasts.

At the end of the year new 25 USD devices will be introduced, with all the power of the web, aiming to open the web to people that could previously not afford devices with the same acces to the web.

Andreas Bovens – Intro to @viewport & other new Responsive Web Design CSS features

Andreas discussed some of the lesser known features for responsive web design that are in browsers already, but not used so much yet.

First, Andreas showed the various different browsers that Opera currently offers. There are Chromium-based browsers for Android, Opera Mini based on Presto and the experimental UX of Coast for iOS.

He then discussed four CSS features that are ideal in responsive design.

1. @viewports

The web started off fluid, there was hardly any way to do fixed layouts. Then table layouts came in and fixed CSS widths. Some years later, liquid layout made a comeback, using percentages, max-widths and min-widths. Then, along the lines of the fluid trend, came responsive web design, employing use of media queries and encouring thinking more about different devices. It is now an established way of working.

Karl Gernstner introduced the notion of ‘design programme‘, a set of rules for constructing a range of visual solutions. See also: Lupton, Thinking with type; Kerstner, Programme entwerfen.

Two technologies make RWD possible: media queries and the meta viewport tag. Media queries allow developers to apply CSS rules conditionally, the meta viewport tag allows setting the zoom level (most browsers ‘zoom out’ to display legacy, non-mobile-optimised ). With the meta viewport tag in a page, media queries work as intended.

The whole zooming out to the page width thing started in mobile Safari, and they added the meta viewport tag to allow developers to circumvent the zooming. Soon after, it got implemented in most other modern browsers.

Not a standard

A bad thing about the meta viewport tag: it was not a standard, so people started confusing syntax, e.g. adding semicolons instead of commas (eventually both ended up being supported). As there was no standard, edge cases are now handled different by each browser. Some features are not supported everywhere, e.g. user-scalable=no, so you’re never sure whether things will work or not. Android added target-densitydpi, which Opera also added. Internet Explorer implemented device-width as 320px as that was the original iPhone width. Safari zooms in 1.333% in landscape mode, which could be avoid by (their propriety) initial-scale:1 rule. Then Apple came up with minimal-ui properties. Anyway, end of rant, Opera decided to write a spec for viewport.

To standardise the things the viewport meta element did, Opera wrote @viewport as a CSS spec. Settings that you can set with the meta element can now be set in CSS. [Sidenote Yoav Weiss added to his talk: if you use @viewport in CSS, set it an inline <style> -element, as otherwise it will mess with things, including responsive images].

Example:

@viewport {
  width: auto;
}

In some senses @viewport is better than the original meta tag, and for sure it is better documented as it is a standard.

If you want to try it out now, you turn it on in Opera or Chrome flags and you can play with it. Currently, it would be advisable to use both as support for @viewport has hardly landed in browsers.

2. Resolution media queries

When devices with higher pixel densities came about, they started interpreting 1px in CSS as 2px on the device, for example iPhone 4 interpreted 1 CSS-pixel as 4 device-pixels. This makes fonts and vector graphics look very pretty, but can make bitmap graphics look blurry.

Resolution media queries can use ‘dots per px’ units (dppx).

Example:

@media (screen and min-resolution: 2dppx) {
  .thing {
    background-size: 50%; 
  }
}

@media (screen and min-resolution: 3dppx) {
  .thing {
    background-size: 33.33%; 
  }
}

<p>This technique is similar to <code>device-pixel-ratio</code> that works in some browsers, except this one is standardised. It is in some browsers, and not behind flags so can be used today (but it is not available everywhere yet). </p>

<h3>3. object-fit</h3>

<p>New <span class="caps">CSS</span> rules: </p>


```css
object-fit: fill;

object-fit: contain;

object-fit: cover; 
overflow: hidden;

These features are very useful to make small adjustments to images. They were already possible on background images, but not on inline images.

4. Viewport percentage widths/heights

Units: vw, vh, vmin, vmax

Think of your canvas as a 100 by 100 units, then vw and vh are those units, e.g. 50vw would be half of the width of your canvas.

Opera was heavily involved in all four, both at spec level and implementation level.

Ruth John – Browsers at play

Ruth builds interactive prototypes at 02. At State of the Browser, she showed some great things she built.

VJ’ing with CSS Animations and WebAudio API

When she was at uni, Ruth used to be a VJ. Recently, she thought, with all the cool things now possible in the web (CSS animations, WebAudio API), can I recreate the visuals of those days in the browser?

Ruth showed various demoes, including one that heavily used the Web Audio API (recommended reading: O’Reilly’s book on this subject). It allows you to control volume, create sound and analyse sound. The latter, Ruth used to create graphics that responded to changes in a music file.

With getUserMedia, microphone input can be analysed in JavaScript, using the Web Audio API. Ruth showed a cool demo in which graphics responded to her voice.

Demoes online: dancing.rumyra.com/shake-n-track dancing.rumyra.com/vibrate

Jake Archibald – Network connectivity: optional

The web is in a state where developers do dirty tricks to get you to go to download their native apps. “Why is that, why are mobile apps still preferred to the web versions?”, Jake asked.

Some reasons:

• availability offline
• server push
• background synchronisation
• geo fencing
• payments
• performance
• ‘app presence’

The web is really exciting, said Jake, as people are currently working on implementation of all of the above.

To improve performance, the 300ms double tap delay was removed from Chrome and Opera (soon to be removed in Firefox), for whenever a screen is small and the device-width meta tag is used.

To improve presence, so that the app can be in start menus, home screens, status bars, etc, the app manifest spec is being written at the moment, describing a way to have a json file with properties of apps, to make all the different <meta> elements that are currently used to do the same, obsolete.

Service workers

To improve offline availability, service workers are coming! There was, of course, AppCache. It tried to create shortcuts for a destination it didn’t know, it was hard to know what to expect from it and its API was too complicated.

We should treat online as a progressive enhancement to offline, and work ‘offline first’. That way, cached content is shown first, whilst making a request to the network for fresh content. When that network request fails, the cached content will still be there; if it succeeds, there will be fresh content.

Service Workers are reactive, not predictive, as AppCache was. It will try stuff and see what happens. The advantage of that is: if the thing it tried does not work, fallbacks can be added, making it very suitable for progressive enhancement.

What the web can do vs what apps can do

Native app developers can do everything, the web can sometimes feel like a massive can’t. Packaged apps are not the solution, they are interim, until the web has improved and become better. Native will always be better on their platform, the web will not win on that front. But it will win in being more accessible and much more widely available.

Martin Beeby – High-performance web platform

Martin Beeby, developer evangelist for Microsoft’s Internet Explorer, explained how to improve performance of websites, and what to keep in mind when building for Internet Explorer 11.

Things limiting speed on the web are bandwidth, latency and data plans.

Perceived performance is the most important to optimise. An important part of this is the use of memory. Inefficient use of memory can be a problem for performance, but also for the user’s hard drive life expectancy. Most of the memory websites take up is taken up by images.

Power consumption is something to think about as well, as it is about the user’s battery.

New website: status.modern.ie to give community more insight in what features the IE team considers supporting, as well as what’s already built in.

Microsoft built two tools to measure performance: the F12 dev tools, in IE10 and more even in IE11 this has improved a lot. There is also the Windows Performance Toolkit, which can be used to measure any app on Windows.

Performance improvements that can be made:

• One of the most important performance optimisations are in images: often images for mobile do not have the right size and this can take a long time (not only downloading the images, but also image decoding).
• Defer script execution: put scripts in the footer, or, if you put them in the top, add the async/defer attributes.
• Reduce number of frameworks: not only because they would have to be downloaded, but also because they have to be garbage collected
• To fix items don’t add timers or events, they fire at the wrong timing or too often (e.g. scroll), use requestAnimationFrame (fires whenever the browser is ready to paint the screen, and can therefore be a lot smoother than something that fires each time the user scrolls)
• use CSS animations, not JS animations where possible
• use JPG instead of PNG where possible, JPGs have a huge performance benefit
• keep in mind: download size vs memory size. Memory size needed to store an image is often bigger than the image download size: width * height * 4, roughly. Copying an image from memory to gpu can relatively take quite a lot of time. In IE11, JPGs are hardware accelerated.
• when you develop on mobile, use a ‘low end first’ approach.

Yoav Weiss – Brace yourselves – responsive images are coming

Responsive images is to ‘efficiently load propertly dimensionsed images that fit the pages design’. My main concern is with performance here, we cannot be developing websites for 550$ smartphones only.

vs srcset

<picture> was thought up by the responsive images working group, Hixie of WHATWG did not like it and added, without much public discussion, the srcset idea. Two years later, both will be implemented.

Tab Atkins came up with src-n, apparently over a bottle of wine. It was great for discussion, this time amongst browser vendors, which was good. Then, the original picture syntax was redefined, with a new proposal that can make everyone happy. Now the Responsive Images Community Group and WHATWG are working on it together.

Yoav is implementing it in Blink, Mozilla are also working on implementing it it. Should be there in a couple of months.

picture 2.0

Usecase 1: bigger images for high resolution devices / the ‘retina’ use case

<picture>
  <source media=”mq” srcset=”/path”>
  <img/>
</picture>

There can be multiple <source> elements, the srcset attribute can have more than one image.

In Chrome, the srcset attribute works on <img> elements today.

Use case 2: art direction, in case you need multiple images to be properly cropped for different layout)
Use case 3: mime type fallbacks (jpgr, webp, jpeg2000 are formats that only work in some browsers, they would need a fallback)

An image element is always required, otherwise the picture will not display.

The sizes attribute, variable widths

Use case 4: variable width images

‘Picture is a magical span, nothing more’ said Tab Atkins. You should not try to style it using CSS.

When looking up what ‘w’ means, look at the picture spec, as the ‘old’ syntax is quite different.

If you want to play with <picture> and srcset today, there is a polyfill available: Picturefill 2.0 was released by the Filament Group, it is officially spec compliant.

Dan Donald – What it means to be flexible

Dan Donald explored what it means to build websites in a flexible manner.

Responsive web design is a recipe for managing and constraining the fluidity of the web. It is a recipe in the sense that it leads to a lot of improvements to the web, like responsive images.

An example of flexibility: the nature of breakpoints. They are a tool to describe change. Are we designing for content or devices? One can use device-oriented breakpoints, but they make the assumption that we can rely on devices having the same widths. Another option is content oriented breakpoints.

When using device breakpoints, we get a conflict with the universality principle of the web. There’s little to no correlation between viewport width alone and devices.

We have a breakpoint purpose mash-up. We work in a world of assumption, but what do we really know? E.g., the user agent string we get on the service side, is full of lie.

An important concept within building flexible pages, is the ‘element media query’. It does not currently exist in a standardised form or in browser implementation, but that did not stop various developers from building their own JavaScript solutions. Dan showed us his.

Chris Heilmann – Open web apps

Chris talked about the open web, and about what Firefox OS can mean within the context of the open web.

Open Web Apps: manifest file that says what your app is/does. Apps are a better form factor for devices (then URLs).

What makes a good app? Why do people download a calculator app, rather than typing their calculation into an online tool like Google?

• focused (it is full screen)
• mobile (it works offline)
• contained (you can delete the icon to delete the app, you can send it as one thing)
• integrated (it works together with the OS and has hardware access)
• it is responsive and fast

Can all of the things that make apps great be done in HTML?

A great app does one thing and do that one thing well. Simplicity is what makes app so popular.

Service workers is the most important thing at the moment, offline viewing is a very important thing that needs to be solved.

Go low in your testing, do not test on too fast connections, as the web is universal and it would be bad preventing people with low bandwidth connections from accessing your website.

Everyone with an FTP connection and text editor can work on Open Web Apps, not just rich kids in Sillicon Valley that can pay 99 dollars and buy the newest devices to test on. That’s not the web!

Q&A

Throughout the day, attendees could ask questions via Twitter and to the organisers. After the last talk, Daniel Appelquist confronted the speakers with some of the questions that were asked.

(Answers are based on my notes, and should not be considered to be literally what the panelists said).

Q: How will HTTP2 change any of the thinking about responsive web design thinking?

With HTTP2, combining all your JS into one file will become an anti pattern […] the same goes for sprited images

Jake: HTTP2 will turn a lot of good practices into bad practices, for example, starting a new request would be less of a deal. Combining all your JS into one file will become an anti pattern, lots of small files will work much better. The same goes for sprited images.

Yoav: Today, the browser has to download everything to get started, which today is good because it saves HTTP requests, but if that is no longer needed, it will be better to have many small files.

Andreas: I agree, best practices like sprites will have to be rethought. This will mostly be an education problem, we will have to ‘unevangelise’.

Chris: Most people use build processes nowadays, and an advantage of that problems like this can be solved by adjusting those tools. These things are already abstractions, so we only need to adjust the abstractions.

Q: How can we be a web industry that women don’t feel alieniated in?

Martin: All I can do is not be a dick, that is the only thing I can have control over.

Ruth: It is an issue. I have been lucky, as in most places where I worked, people weren’t dicks. I think it is mostly a social problem. I’ve had sexism and it isn’t nice, but there are worse problems in this world.

Chris: Sites like Codebabes are blatant trolling, they’re not much more than a clickbait. We are not going to solve social problems on the internet by clickbaits. We should not give them a lot of attention in tweets.

Ruth: listen to ‘the science of the sexes’ podcast, it is a great resource.

Q: Everyone keeps talking about “the web platform“, what is a platform and should we want the web to be a “platform”?

Chris: The web is an opportunity for people to publish on, it is a way to spread information in a world wide manner. It is a set of technologies.

Andreas: It is just a matter of naming. We have called it ‘web standards’, and later internally at Opera we called it ‘the web stack’. Some use the word ‘HTML5’, maybe ‘platform’ is a better term for it all. Whether it means something deeper than that, I’m not sure.

Q: How can we make the web platform a better platform for games?

Ruth: That’s a really good question, but very difficult to answer. We already have things that are amazing at games, like Xbox and Playstation. I think we need to build a lot more to show what is possible. The Audio API and Vibration API i talked about seem great for games.

Martin: we [at Microsoft] go to lots of game developers, at big companies, but also indie game developers. I don’t know much about game development, it is a very different world. Interesting is what is happening with WebGL, not just for games but for parallel computing in general, it it has implications for lots of things outside gaming as well. It is very complicated though, hard to learn.

Chris: It is a different world, like native vs web. Gaming is a speed test, if we can get games running on web technology, we can learn from it for other applications of the web.

Q: How will Web Components change the way we work on the web?

Chris: Web Components are an amazing opportunity, they allow us to write proper widgets on the web. Whatever HTML you were missing, you can now actually write and publish yourself. It allows for widgets that are running with the browser and not against it. They becomes part of the browser. Jake had a talk about a tabs component some years ago, that is one to watch again. [I think Chris meant Jake’s talk ‘Reusable code: for good and for awesome’ at Fronteers 2010. Video / transcript and slides

Jake: Web Components are an important part of the extensible web. For someone new to HTML, it was weird that

and

looked different — CSS helped to explain why this is. Developer tools in modern browsers to this with things like performance waterfalls. Service Workers does a similar things to help understand the network. Web Components will help to show why things render the way they do. Libraries like jQuery UI that change a <div> into a widget will no longer be needed, you could just have a new element doing a widget.

Yoav: I’m slightly worried about performance of Web Components, for example in terms of blocking rendering. The browser has to download the import and files within that file and files within that file. We have to make sure it will not become the next @import of CSS.

Q: What is the future state of deep linking from web apps? And into web apps?

Barjo: Haida does that for Firefox OS, it will make the flow more natural for the user, linking will feel more natural like it is in the native OS already.

Jake: We can’t lose the URL.

Andreas: I agree. URLs are the power of the web and an advantage of the web over native apps. The web can link to apps, but URLs can also be used to link from an app to the web.

Conclusion

I’ve had a great day in London, and enjoyed this very affordable conference a lot. There was plenty to learn and it is exciting to know that a lot of the stuff presented today, will be in browsers in the not too distant future.

Thanks Krijn and Mathias for pointing me at spelling errors in previous drafts of this post.