Meeting!

[eeeps]

RICG members and various representatives from IE, Firefox, and Chrome met in Redmond to talk about where we go from here. It was action-packed:

Respimg

• IE is planning to implement srcset w and sizes, along with the already in-development srcset x
• IE is planning to implement image-set
• img will be getting a read/write DPR property, accessible via JS (relevant GitHub issue)
• The respimg use-cases doc will be updated with at least two new cases – art directing down to no image at all and a non-JS way to do Low-Quality Image Placeholders.
• A racy suggestion: maybe Blink will override (or allow authors to omit) sizes, and use post-layout, measured image dimensions instead?

Element Queries

• We’re gonna use the polyfill to flesh out the use-cases doc.
• Tab Atkins has some good ideas and is going to turn them into a concrete spec. Something something “layout boundaries.” Can someone who was at the meeting take a shot at a one-sentance explanation? I’m failing to grok it from the minutes

Comic relief interlude: hot bot drama

Client Hints

• Yoav is implementing the resource-width and DPR hints in Blink behind a flag
• Factcheck Client hints, while they grew out of respimg and will first be used for those two hints, will provide a general architecture for clients and servers to exchange hints about resources and environments in a structured and minimally-overhead-y way.
• Factcheck Part of that architecture is smarter cacheing
• Factcheck Another part of it is allowing page authors to opt-in to specific HTTP headers
• The next steps: 1) solidifying the spec for the RW and DPR headers and 2) convincing other browsers to follow in Blink’s footsteps.

Pre-* and Resource Hints

• Pre-things via Resource Hints Are these headers, like Client Hints??
• Pre-connect: establish an HTTP connection with a host ahead of time - coming in Chrome 43
• Pre-load: download scripts and styles without applying them (yet) - very early days, and there was a lot of discussion about how to prioritize them, possibly via lies.
• Pre-renders - actually (and optionally, for the UA), apply some of those resources
• Something something NetInfo API

This’ll take another round of summarizing to fit into a newsletter, but please tell me if I’ve misconstrued or simply outright missed anything important! I know I’m at least missing a short/coherent summary of Tab’s elquery proposal.

[igrigorik]

@eeeps thanks for putting this together. Some notes + comments from this end...

Client Hints

Factcheck Client hints, while they grew out of respimg and will first be used for those two hints, will provide a general architecture for clients and servers to exchange hints about resources and environments in a structured and minimally-overhead-y way.

CH defines DPR, Content-DPR, and RW request headers (hints) to help respimg optimization. That said, CH is simply a registry of headers that aims to standardize common hints such that we can achieve better interop between clients & servers: naming of hints, formatting rules, guidance on how to optimize for caches, etc.

Factcheck Part of that architecture is smarter cacheing

Yep. CH provides guidance on how to best name + format hints to get best interop with existing caches, plus upcoming standards (e.g. Key response header).

Factcheck Another part of it is allowing page authors to opt-in to specific HTTP headers

Yep. We define a common mechanism to allow the site/developer to indicate which hints the user agent should send on subsequent requests. In the future we can imagine having dozens of different hints.. and its impractical to send all of them on every request, hence the opt-in mechanism.

The next steps.. (snip)

• We're still iterating on ideas for various opt-in vs on-by-default strategies. This is a non-blocking discussion.
• Yoav is implementing DPR, Content-DPR, and RW hints in Blink. For performance reasons, these hints need to be implemented natively by the UA, whereas most others can be implemented directly by site authors via ServiceWorker. See: https://docs.google.com/document/d/1SnRhnR_oWQ4Rivb7InJ9a_0T2k9CnuhNcMkd9xtLrKY/edit?usp=sharing
• FF and IE have shown "positive signals" for implementing same hints. ETA for both is TBD.. :)

Preload + Resource hints

• Preconnect: Blink and FF implementation is in progress.
  • https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/CM5BaP6uVvE - our current goal is to enable this in M43, barring unexpected complications.
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1135160
  • IE: indicated that it's on the backlog.
• Preload: Yoav is working on Blink implementation.
  • http://w3c.github.io/preload/ - decouples fetching from execution.
  • Examples + use cases: http://w3c.github.io/preload/#use-cases
• "Resource Hints" spec standardizes "prefetch" and "prerender" behaviors that some browsers have currently implemented (in incompatible ways ;-)). This spec covers "speculative" fetching: resource you might need for next navigation.
  • http://w3c.github.io/resource-hints/
• NetInfo API: Chrome and Firefox both support new version of NetInfo API
  • Chrome is working on enabling new downlinkMax attribute. FF is planning to, but no ETA.

... phew, think that covers most of the above points. If anything is missing, let me know :)

[tabatkins]

Layout Boundaries: To make EQs work, need a way to make an element stop paying attention to its children for layout purposes. This is also helpful in general for more predictable component performance - no more accidental full-page relayouts.