TPAC 2016 report

Oct 04 2016

A couple of weeks ago I attended TPAC, the annual week-long W3C festivities meeting, and I'd like to share my notes and impressions from a few of the sessions we ran.

# Responsive Images

While most days at TPAC are split into Working-Group-specific meetings, Wednesday is traditionally filled with breakout sessions that aren't necessarily affiliated with any WG in particular. As part of that, we ran a session about responsive images and their aspect ratios.

The subject was actually triggered by an email sent by Jason Grigsby that very morning to the public-respimg mailing list pointing out that aspect-ratio info is becoming a issue in real-life deployments of responsive images. The email stated that more and more frameworks and blog posts are advocating for developers to include explicit fixed width and height attributes on their images, in order to avoid content re-layout when the image dimensions are downloaded. Such re-layouts cause the content to "jump around", and are rightfully considered bad UX on mobile.

While the original email advocated for adding aspect-ratio info into sizes, it is not really necessary, as the browser needs to know the aspect-ratio info at initial layout time and not before that. Therefore, just adding an explicit aspect-ratio to CSS might be enough to resolve the problem.

At the same time, there are current CSS methods to achieve that, as Simon Pieters pointed out during the meeting (specifying explicit dimensions per image breakpoint, or using padding percentage based hacks). Based on that, if we want to encourage authors to define aspect ratios, we may need to add a markup equivalent. In some scenarios (e.g. CMS), the people adding the images may have little control on CSS, and adding HTML controls equivalent to height/width may be helpful.

One slightly tangent, but extremely relevant point that was raised during the meeting was that MPEG recently standardized a new image format container called HEIF, which enables (in more or less the same way) many of the ideas I prototyped when I discussed a Responsive Image Container. Having that in standard form (and in a codec agnostic container) may increase the chances of such an image format getting implemented in browsers. That would enable a single image resource to serve multiple resolutions and cropped versions, with the browser downloading only the required bytes. Exciting stuff!!

Afterwards, the meeting went on to discuss the future h descriptor, and use cases for it.

We concluded that we need to gather up use cases for aspect-ratio definition on elements, on images (and the impact on their loading) as well as use cases for height definition in sizes.

Full minutes for the meeting.

# WICG

Later that day, we ran a session about the WICG and the process around it. The session followed some contention the day before, so we spent a large part of it explaining the goals of the WICG: getting more people involved in Web standards, and using a bare-minimum-red-tape process in order to facilitate that.

We talked about the need to get early feedback on standards from outside of the standards echo-chamber, which is the main motivation of passing standard proposals through an incubation phase, even if we're pretty certain they'd end up being worked on in a certain WG.

We discussed getting more people involved, and the fact that any proposal needs to be pushed and championed. No one is sitting around waiting for your proposals, and if you want to see new features and capabilities get implemented, you need to find the right people and get them interested. This is also something that the chairs can help with, by making sure that the right people are on the discourse proposal threads.

Another point raised was that in order to push a proposal through incubation you need to get positive feedback from the community, whereas WG work just requires lack of negative feedback, so once a proposal gets through incubation, you know that there's interest for it, rather than just lack of opposition. That helps to make sure that the right things are being worked on.

We talked about the meaning of "incubation" and how it can be done within the WICG or outside of it. Chris Wilson defined it as:

• Ability to fail gracefully, rather than continue to work on a proposal because work started and it's in the charter
• Open process which can include many people from many organizations.

Finally, we agreed we need hard metrics to make sure we measure success properly, and achieve the WICG's goals of wider participation, better feedback loop, and mature proposals by the time they graduate.

Meeting minutes.

# WebPerfWG

The 2 days of the Web Performance Working Group meetings were extremely exciting and filled with new proposals for things that can improve our capabilities to monitor and accelerate our sites. The meetings were already summarized in detail elsewhere, so I'll just give a brief overview of the different exciting proposals:

• Long Task Observer is a new proposed mechanism that would enable you to know when the main thread was too busy with a long task - a long-running script, heavy layout operations, etc. That can give you a good indication of your app's responsiveness to user input, and can indicate a problem in the wild with certain user interactions that you won't necessarily see in the testing lab.
• First paint metrics is a proposed API that will finally expose a standard way to know when the user started seeing content on screen. Current RUM performance metrics lack any indication of visual metrics, so this proposal is a huge step forward.
• The Hero Element API and declarative User Timing marks would both give us a way to report the "First Meaningful Paint" and answer the question "when was the page at a stage where the user saw meaningful content?". One of the downsides of current User Timing API is that it only allows you to mark milestones that have a JS event attached to them. These proposals would enable us to apply the user timing concept to markup based elements, which could significantly increase its usage.
• The Memory Pressure API would enable sites to know that the device is running low on memory and is likely to evict their tab soon. That can enable sites to reduce the memory usage in such dire times, in order to try and avoid being evicted. Related to that, we also discussed crash reporting for cases where the site ended up being evicted from memory, which is an event that's currently largely invisible to developers.

# To sum it up

TPAC this year was fun as always, and was filled with exciting new developments. It was great to discuss the next steps on the responsive images front, and seeing that a file format solution might not be that far off.

The WICG discussions left me optimistic. I believe we'd be able to unite the standards community around the concept of incubations and would be able to get more people involved, resulting in better Web standards.

And finally, it was exciting to see so many proposals for new performance standards that would help making the web significantly (and measurably) faster.

Till next year! :)

← Home