IRC logs for #respimg, 2015-03-05 (GMT)

[00:02:05]* marcosc has joined #respimg
[00:27:42]* Wilto has joined #respimg
[00:47:41]* yoav has joined #respimg
[01:26:51]* bruceontheloose has joined #respimg
[01:28:27]* Wilto has joined #respimg
[01:36:04]* bruceontheloose has joined #respimg
[01:52:29]* bruceontheloose_ has joined #respimg
[02:02:32]* yoav has joined #respimg
[02:03:05]* marcosc has joined #respimg
[02:29:15]* Wilto has joined #respimg
[03:30:01]* Wilto has joined #respimg
[03:36:40]* Wilto_ has joined #respimg
[03:49:44]* joemcgill has joined #respimg
[04:02:51]* Wilto has joined #respimg
[04:13:00]* zcorpan has joined #respimg
[04:32:42]* Wilto has joined #respimg
[05:22:21]* zcorpan has joined #respimg
[05:33:27]* Wilto has joined #respimg
[05:43:49]* zcorpan has joined #respimg
[05:48:08]* zcorpan has joined #respimg
[06:16:19]* Wilto has joined #respimg
[06:34:19]* Wilto has joined #respimg
[06:47:36]* Wilto has joined #respimg
[06:52:45]<johns>Wilto: 229 Pass 6 Fail
[06:53:20]<johns>Remaining are silly things like gecko doesn't flag U+200A in front of "1x" as a non-standard integer
[07:14:54]* nemzes has joined #respimg
[07:16:37]* nemzes1 has joined #respimg
[07:25:24]* zcorpan has joined #respimg
[07:34:59]* Wilto has joined #respimg
[07:38:35]* bruceontheloose has joined #respimg
[07:42:16]* joemcgill has joined #respimg
[07:55:01]* ShaneHudson has joined #respimg
[07:55:51]<zcorpan>johns: nice work! what are the remaining 6 failures?
[08:35:44]* Wilto has joined #respimg
[08:39:36]* marcosc has joined #respimg
[08:47:24]<zcorpan>botie: inform yoav r?
[08:47:24]<botie>will do
[08:52:24]* darobin has joined #respimg
[09:28:14]* anselm has joined #respimg
[09:36:30]* Wilto has joined #respimg
[09:54:08]* darobin has joined #respimg
[10:37:16]* Wilto has joined #respimg
[11:19:22]* marcosc has joined #respimg
[11:38:02]* Wilto has joined #respimg
[11:38:09]* nemzes has joined #respimg
[11:47:36]* marcosc has joined #respimg
[11:47:49]* yoav has joined #respimg
[11:47:49]<botie>yoav, at 2015-03-05 08:47 UTC, zcorpan said: r?
[11:59:47]<yoav>zcorpan: +100 on the blocking style issue. I'd chime in if I thought it'd help
[12:02:13]<zcorpan>i suppose if you have only one external stylesheet, it would be better with an attribute on <link> that makes it not block rendering even if it's in <head> so you can start loading it early
[12:10:12]<zcorpan>yoav: did you see the wpt PR?
[12:12:53]<yoav>zcorpan: Looking now
[12:16:57]<yoav>zcorpan: it's just :%s_data,a_/images/1x1.gif_ right?
[12:17:22]<yoav>It's hard to review it line by line since it's in separate blocks
[12:18:29]<zcorpan>yes, plus a query string
[12:19:00]<yoav>yeah, LGTM
[12:19:53]<zcorpan>split view might help review
[12:35:31]<zcorpan>sizes="all 100vw, 1px" test fails in gecko
[12:36:09]<zcorpan>as does sizes="0.1%"
[12:36:59]* zcorpan files
[12:37:54]* joemcgill has joined #respimg
[12:38:48]* Wilto has joined #respimg
[12:39:27]<zcorpan>hmm, wonder what causes
[12:45:41]<zcorpan>i can reproduce it at least
[12:54:16]* joemcgill has joined #respimg
[12:57:00]* joe_mcgill has joined #respimg
[12:57:06]<zcorpan>the load events are fired in the right order at least. must be that currentSrc is sometimes updated after the load event
[13:04:39]<zcorpan>no, it's not updated too late, it's left at null. seems like no image is loaded sometimes
[13:39:34]* Wilto has joined #respimg
[13:40:55]* newtron has joined #respimg
[14:06:52]* nemzes has joined #respimg
[14:06:59]* nemzes has joined #respimg
[14:20:59]* Wilto has joined #respimg
[14:40:23]* Wilto_ has joined #respimg
[14:41:17]* joemcgill has joined #respimg
[14:48:17]* yoav has joined #respimg
[14:50:57]* marcosc has joined #respimg
[15:35:32]* MarcDrummond has joined #respimg
[15:37:16]* newtron has joined #respimg
[15:40:29]* Wilto has joined #respimg
[15:44:05]<PicBot>eh oh
[15:44:18]<PicBot>eh oh
[15:44:35]* ShaneHudson has joined #respimg
[15:44:57]* zcorpan commented in
[15:45:27]<Wilto>Looks like `srcset` is in much better shape as of last night.
[15:45:31]<Wilto>the system works
[15:51:00]* Wilto has joined #respimg
[15:51:50]* bruceontheloose has joined #respimg
[16:04:39]<Wilto>v good
[16:04:47]<Wilto>johns: Great work, man.
[16:39:07]* Wilto has joined #respimg
[16:46:16]* gregwhitworth has joined #respimg
[16:50:43]* eeeps has joined #respimg
[16:53:46]<gregwhitworth>Zakim, room for 6
[17:00:41]* zcorpan has joined #respimg
[17:16:48]* yoav has joined #respimg
[17:16:53]* Rossen has joined #respimg
[17:29:19]<TabAtkins>gregwhitworth: I'M IN THE LOBBY COME GET ME
[17:32:14]* zcorpan has joined #respimg
[17:33:55]* Wilto has joined #respimg
[17:34:38]<johns>oh great he's here
[17:34:42]<johns>there goes the neighborhood
[17:34:54]<gregwhitworth>Wilto: did you get the conf number?
[17:34:57]<Wilto>yoav: Ping. How do I join up?
[17:36:23]<Wilto>Ah, got it
[17:36:32]<yoav>Wilto: cool
[17:36:43]<Wilto>Downloading plugins; one sec
[17:38:36]* Wilto_ has joined #respimg
[17:39:41]<Wilto_>I’m in.
[17:40:34]* grigs has joined #respimg
[17:41:05]<gregwhitworth>everyone introduces themselves
[17:41:53]* TabAtkins greg, get everyone's names down, just to help memory?
[17:45:32]* adrianba has joined #respimg
[17:45:42]<gregwhitworth>Attendees in the AM: Jacob Rossi, Tab Atkins, Tobin Titus, Yoav Weiss, Ilya Grigorik, Jason Grigsby, Mat Marquis, Aaron Gustafson, Todd Reifsteck, Adrian Bateman, Greg Whitworth
[17:46:00]<gregwhitworth>Topic: Responsive Images
[17:46:17]<gregwhitworth>Yoav: We have srcset, sizes and picture in Blink
[17:46:26]<gregwhitworth>Yoav: Working on the picture stuff in webkit
[17:46:41]<gregwhitworth>Yoav: Firefox has just turned on picture, srcset for 38
[17:46:57]<gregwhitworth>Yoav: The big question is IE, beyond srcset x
[17:48:05]<gregwhitworth>Greg: We plan to implemente extended srcset, similiar to webkit and blink
[17:48:57]* zcorpan has joined #respimg
[17:49:17]<gregwhitworth>Yoav: there is also the subject of extending image-set to allow what srcset can do
[17:50:11]<gregwhitworth>Yoav: Where does IE stand regarding this
[17:50:36]<gregwhitworth>gregwhitworth: now that we are beginning to get the plumbing in place, we are looking at this and plan to do this
[17:51:34]<gregwhitworth>yoav: we may want to split content dpr from just the client hints spec
[17:51:58]<gregwhitworth>ilya: it is actually broader than that, we should be able to do it more broadly via js
[17:52:18]<gregwhitworth>yoav: srcset would be able to use this header by default
[17:52:38]<gregwhitworth>yoav: it would mostly be interesting for semi legacy content
[17:52:47]<gregwhitworth>yoav: you have access to the html
[17:53:03]<gregwhitworth>ilya: it's not just legacy html, what if you fetch an image via xhr
[17:53:17]<gregwhitworth>ilya: I spoke with Simon about this at TPAC
[17:53:30]<gregwhitworth>ilya: So we need to volunteer someone to write the spec
[17:53:41]<gregwhitworth>Tab: it's an attr on image
[17:53:46]<gregwhitworth>Yoav: An attr or a property
[17:53:57]<gregwhitworth>Tab: A web idl attribute, so a property
[17:54:14]<gregwhitworth>Ilya: It can be defined in the cleint hints spec
[17:54:29]<gregwhitworth>Ilya: it doesn't really matter where it's defined, it's just registered there
[17:54:45]<gregwhitworth>Tab: The actual attr for image should be in the HTML spec
[17:55:25]* jrossi has joined #respimg
[17:55:43]<gregwhitworth>Mat: We can go home for the day
[17:56:19]<Wilto_>case closed; tab is gonna do everything
[17:56:50]<TabAtkins>RESOLVED: Add a property to <img> that reports the currently-chosen resolution, and is settable so authors can manipulate it.
[17:57:12]<TabAtkins>ACTION Tab to write up proposal for <img> density property and send to WHATWG.
[17:57:19]<gregwhitworth>Jason: image-set needs parity with srcset
[17:57:28]<gregwhitworth>Jason: Tab you had talked with this on the list?
[17:57:32]<gregwhitworth>Tab: yes, and I plan to
[17:57:40]<gregwhitworth>Tab: The image spec I haven't touched in a few years
[17:58:04]<gregwhitworth>Tab: lists things that need to change to image-set
[17:58:12]* mike has joined #respimg
[17:59:00]<gregwhitworth>Yoav: The problem with doing that with on content images is layout can happen before the image is fetched
[17:59:13]* igrigorik has joined #respimg
[17:59:20]<gregwhitworth>Yoav: I haven't figured out a non-racy way to solve that problem
[17:59:37]<gregwhitworth>Yoav: I'm not 100% certain it's not a bad thing
[17:59:41]<PicBot> => API for getting/setting image pixel density => 5 comments, 1 IRC mention => open
[18:00:06]<gregwhitworth>Yoav: Even if the worst case is today's status quo, it would make it harder to test and more confusing to autors
[18:00:11]<gregwhitworth>Greg: How so
[18:03:09]<gregwhitworth>Tab: We need a #iknowthiswillbeslowbuttheengineknowsbetter attribute for sizes
[18:03:16]<gregwhitworth>Tab: or value
[18:03:32]<gregwhitworth>Yoav: Currently the resource priority is officially dead
[18:04:49]<gregwhitworth>Jason: There were two issues you brought up
[18:04:56]<gregwhitworth>Jason: If people can defer things
[18:05:10]* AaronGustafson has joined #respimg
[18:05:14]<gregwhitworth>Jason: If the browser knows better, should it override sizes
[18:06:15]<gregwhitworth>AaronGustafson: The resource spec does not have a note saying it is dead
[18:06:24]<gregwhitworth>ilya: can you give me an example of this racing
[18:06:55]<gregwhitworth>yoav: if you have an image down the page, when the preloader get's to it, it will be in the queue by the time that layout actually happens
[18:07:14]<AaronGustafson>There is also a case for lazy images only to load above a particular size (e.g. when content images are an enhancement for larger screens). Exploring that idea using srcset & sizes:
[18:07:32]<gregwhitworth>yoav: the only reason I'm even playing around the idea, the worst case in the race is today's status quo
[18:08:03]<gregwhitworth>yoav: on the other hand, going back to client hints we could send out
[18:08:11]<gregwhitworth>ilya: isn't that the same issue
[18:08:21]<gregwhitworth>jrossi: you could actually send out the state
[18:08:35]<gregwhitworth>jrossi: do you have confidence about the layout or not
[18:09:23]<gregwhitworth>yoav: currently the way it works in Blink, the images that are in the queue get their priorities upgraded when layout happens and they are visible in the viewport
[18:09:51]<gregwhitworth>yoav: the same mechanisms could be used to tell sizes, if it's not this it's that
[18:10:06]<gregwhitworth>ilya: the whole concept of a queue is being destroyed by that
[18:10:24]<gregwhitworth>yoav: but on http2 you have the queue on the opposite side
[18:10:27]<AaronGustafson>Resporce Priorities Abandoned:
[18:11:05]<gregwhitworth>Tobin: one mistake can outdue 10 of your optimizations
[18:11:11]<gregwhitworth>ilya: that was from velocity conf
[18:11:25]<gregwhitworth>ilya: you don't know, there is latency
[18:11:34]<gregwhitworth>yoav: you could tell the server, change this unless
[18:11:48]<gregwhitworth>ilya: if latency was not an issue that would work
[18:11:57]<gregwhitworth>yoav: if you change the protocol
[18:12:14]<gregwhitworth>ilya: this is a tricky problem
[18:12:33]<gregwhitworth>yoav: we would want an opt in if we go down that path
[18:14:09]<gregwhitworth>yoav: regarding w3c tests are you using them?
[18:14:15]<gregwhitworth>gregwhitworth: yes we do
[18:14:30]* tm has joined #respimg
[18:15:08]<gregwhitworth>gregwhitworth: how do we know what is ED versus WD
[18:17:24]<gregwhitworth>wilto: I would prefer not to depend on emails
[18:17:37]<gregwhitworth>wilto: maybe a call for comments when we make changes to the spec
[18:17:48]<gregwhitworth>wilto: I would like to automate somehow
[18:18:33]<Wilto_>^ when a “breaking” change or addition is made to specifications, and browser reps need immediate notification of intent to make that change
[18:18:36]<gregwhitworth>aarongustafson: I've had a couple projects regarding lazy loading, instead of just deferring the image
[18:18:58]<gregwhitworth>aarongustafson: we've been relying on JS for that
[18:20:01]<gregwhitworth>aarongustafson: discusses how his codepen regarding a sizes for lazyloading
[18:20:07]<gregwhitworth>yoav: we have discussed it
[18:20:22]<gregwhitworth>yoav: the hacky solution for that, is to add src=""
[18:20:36]<gregwhitworth>grigs: why would you want that?
[18:20:54]<gregwhitworth>aarongustafson: on a news site
[18:21:13]<gregwhitworth>aarongustafson: you may not want those small content images on a smaller screen
[18:21:28]<gregwhitworth>aarongustafson: it's additional overhead and may create a poor reading experience
[18:21:46]<gregwhitworth>aarongustafson: it's an improvement for smaller viewports but is nice to have on larger devices
[18:22:19]<gregwhitworth>aarongustafson: we would traditionally approach that with an empty paragraph or div and lazy loading those in after JS determines it matches what we're going for
[18:22:30]<gregwhitworth>wilto: there has been a lot of demand for this
[18:22:41]<gregwhitworth>wilto: to be honest, I'm against this idea
[18:23:04]<gregwhitworth>aarongustafson: if you're talking about "Obama signing a bill" does the picture count as decorative or content
[18:23:10]<gregwhitworth>aarongustafson: it's not black and white
[18:23:41]<gregwhitworth>wilto: it is not black and white, but if it's content it should be shown, but there is a lot of demand for this so we may want to start accounting for this
[18:24:02]<gregwhitworth>yoav: this is possible in <picture> with an empty data uri
[18:24:14]<gregwhitworth>wilto: it might be something we want to consider
[18:24:28]<gregwhitworth>aarongustafson: would the src need to be a 1x1 gif?
[18:24:35]<gregwhitworth>aarongustafson: that seems very hacky
[18:24:47]<gregwhitworth>yoav: it is art direction, that is the picture realm not srcset
[18:25:09]<gregwhitworth>yoav: we have proposed an empty attribute and that would leave out the 1x1 gif
[18:25:33]<gregwhitworth>yoav: we have determined against it, but it's not impossible to reverse that
[18:25:49]<gregwhitworth>wilto: it seems hacky to write markup to get an empty area
[18:26:08]<gregwhitworth>aarongustafson: it is possible across all images except for older versions of IE to use this
[18:26:26]<gregwhitworth>aarongustafson: Firefox does a gc piece anyways, so we turn that off if the image shouldn't be shown
[18:27:53]<gregwhitworth>yoav: a broken image still has dimensions that can affect layout
[18:28:28]<gregwhitworth>yoav: I've heard from e-commerce as well
[18:28:28]* TabAtkins Tiniest transparent gif: data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=
[18:29:13]<gregwhitworth>grigs: This is a good use case, but it isn't in the RESPIMG use case list
[18:29:27]* ben_a_adams has joined #respimg
[18:29:33]<gregwhitworth>grigs: This should be there and ask people if it's worth us spending time on solving this issue
[18:29:48]<gregwhitworth>yoav: The use cases doc is a W3C note, can we add stuff to it
[18:29:52]<gregwhitworth>Tab: heck ya!!
[18:30:07]<gregwhitworth>aarongustafson: I can try to add it since I'm 3 hours ahead of you
[18:30:19]<gregwhitworth>wilto: We can link to that and point to specfic lines for feedback
[18:30:34]<gregwhitworth>aarongustafson: I have a fork of picture in github so I can work on that
[18:30:39]<TabAtkins>s/heck ya!!/Hell yeah!/
[18:30:58]<gregwhitworth>ilya: this should be quick
[18:31:10]<gregwhitworth>ilya: yoav you brought the idea of modifying srcset
[18:31:28]<gregwhitworth>ilya: the current spec allows the UA to modify the srcset selection based on numerous things
[18:31:36]<gregwhitworth>ilya: within Chrome this is a very interesting topic
[18:31:42]<Wilto_>(We wanna “RESOLVED” AaronGustafson’s plan?)
[18:31:51]<gregwhitworth>ilya: I think this is something that we want to explore
[18:32:12]<gregwhitworth>yoav: The spec allows as much liberty as we would like, the only problem is author expectations
[18:32:20]<gregwhitworth>yoav: it is better to break that sooner rather than later
[18:32:33]<gregwhitworth>grigs: at least form my perspective, the venues I get to speak about this
[18:32:52]<gregwhitworth>grigs: I mention that UAs get precedence to choose the best image as the UA has the most information
[18:33:02]<gregwhitworth>grigs: I'm trying to set those developer expectations ahead of time
[18:33:08]<gregwhitworth>wilto: I've been doing the same thing
[18:33:27]<gregwhitworth>wilto: if you are using anything other than picture, you are giving up control over what is shown
[18:33:38]<gregwhitworth>grigs: if you want more control, use picture
[18:34:09]<gregwhitworth>yoav: using srcset to do a low quality download followed by a high quality download
[18:34:25]<gregwhitworth>yoav: 0.2x resource, trigger onload, do it's thing and then improve on it later on
[18:34:38]<gregwhitworth>yoav: if we plan to do that, we need to figure out how to opt-in to that
[18:34:50]<gregwhitworth>wilto: that is something we want author's to control that
[18:34:55]<gregwhitworth>wilto: we will get bugs on that
[18:35:12]<gregwhitworth>yoav: we were talking with someone from Amazon, they were using placeholders and replacing them with JS
[18:35:31]<gregwhitworth>yoav: they can be happy with that approach, but something that we can experiment with as an opt-in feature
[18:35:53]<gregwhitworth>wilto: yes there is a demand on that, and we put up a use case on the doc
[18:36:12]<gregwhitworth>ilya: the family here is progressive rendering
[18:36:21]<Wilto_>(should put up a PR on the use cases doc, for discussion^)
[18:36:22]<gregwhitworth>ilya: I'm not a fan of multiple requests
[18:36:49]<gregwhitworth>wilto: I agree, I don't like the idea of multiple requests
[18:37:16]<gregwhitworth>wilto: why specifically does Amazon do this
[18:37:37]<gregwhitworth>yoav: it allows them to lazy load their images with a fast image to render quickly and then update
[18:37:53]<gregwhitworth>*5 minute break*
[18:50:44]* grigs has joined #respimg
[18:51:19]* yoav has joined #respimg
[18:51:46]* zcorpan has joined #respimg
[18:51:50]<yoav>The use cases repo is on
[18:53:05]<gregwhitworth>Topic: Element Queries
[18:53:18]<gregwhitworth>wilto: I have the elevator pitch down to a science
[18:53:50]<gregwhitworth>wilto: MQs in CSS are very helpful for top level break points but are not helpful for modular control
[18:54:12]<gregwhitworth>wilto: you have to have a bunch of redundant markup to achieve what you're going for
[18:55:12]<gregwhitworth>wilto: EQs depending on the size of the parent of that element, will allow you to trigger styles based on its parent
[18:55:18]<gregwhitworth>wilto: we have one global use case
[18:55:27]<gregwhitworth>wilto: it doesn't get into the details
[18:55:48]<gregwhitworth>wilto: I would like to put together an element query use case and it contains a polyfill
[18:55:57]<gregwhitworth>wilto: and use that to put together a few examples
[18:56:13]* newtron has joined #respimg
[18:56:23]<gregwhitworth>wilto: put that out to the community and allow them to put together real world examples and get PRs back into our repo
[18:57:17]<gregwhitworth>wilto: that doesn't keep us from working on the use case document
[18:57:21]<gregwhitworth>ilya: naive question
[18:57:32]<gregwhitworth>ilya: wouldn't web components sort of address this
[18:57:35]<gregwhitworth>Tab: no
[18:58:17]<gregwhitworth>wilto: in WC you're still writing against the viewport
[18:58:49]<gregwhitworth>grigs: if company A releases a component it needs to be able to change its layout given it's own layout, not the viewport
[18:59:02]<gregwhitworth>grigs: to get the mass adoption we need this
[18:59:33]<gregwhitworth>Tab: I have a proposal and it may be ready to work on it as a spec
[18:59:53]<gregwhitworth>Tab: you have some way to trigger it as a layout boundary where it no longer cares about its parent
[19:00:07]<gregwhitworth><section style="layout-container: yes;">
[19:00:15]<gregwhitworth>Tab: obviously this is not final syntax
[19:00:19]<AaronGustafson>can anyone shoot the whiteboard for me?
[19:00:28]<gregwhitworth>tab: once you do this, it doesn't care about it's children
[19:00:34]<gregwhitworth>aarongustafson: I'm writing it
[19:01:14]<AaronGustafson>ah, gotcha thx gregwhitworth
[19:01:15]<gregwhitworth>tab: <widget><style scoped> width:parent-eq(width<600px) ...
[19:01:33]<gregwhitworth>tab: this would allow you to talk to the closest layout boundary
[19:01:50]<gregwhitworth>Rossen: does this effect scrollbars
[19:01:56]<gregwhitworth>Tab: yes, scrolling is easy
[19:02:11]<gregwhitworth>yoav: one concern that I heard from layout engineers
[19:02:31]<gregwhitworth>yoav: it would require layout to happen multiple phases
[19:02:38]<gregwhitworth>tab: the fun thing about this...
[19:02:52]<gregwhitworth>rossen: this widget basically turns it into position absolute, you take it out of the flow
[19:03:04]<gregwhitworth>rossen: that's why I was asking about scroll bounds
[19:03:23]<gregwhitworth>rossen: let's assume this section is in shrink-to-fit it's either going to be 0, or the size of the scroll bar
[19:03:39]<gregwhitworth>tab: true, we may have to do something like we do with vw
[19:04:10]<gregwhitworth>tab: this is a little bit too strict where you don't care about your children
[19:04:30]<gregwhitworth>tab: you may want to be able to state that you only care about the width of your children or height, etc
[19:04:52]<gregwhitworth>tab: if you set this, then you can only use height or width in the element query
[19:05:11]<gregwhitworth>tab: what I really mean is a block size, inline size, calculated without reference to children
[19:05:47]<gregwhitworth>grigs: when you say that you would have to declare the width, can that width still be dynamic
[19:06:13]<gregwhitworth>tab: yes, you can still set it as width auto
[19:06:38]<gregwhitworth>grigs: this brings up the recurrsive problems
[19:07:03]<gregwhitworth>tab: yes, because the children just walk up to it's parent until it gets to a layout boundary
[19:07:32]<gregwhitworth>yoav: on that part then, calling this element queries would be confusing since you're actually referncing its parent
[19:07:39]<gregwhitworth>yoav: this is really container queries
[19:07:46]<gregwhitworth>ilya: assuming you have something like this
[19:07:55]<gregwhitworth>ilya: where would I put the section boundary
[19:08:30]<gregwhitworth>tab: you can double wrap your widget, and it's outer self is a layout container, but you want to make sure the author doesn't float this
[19:09:11]<gregwhitworth>ilya: The twitter timeline, maybe I want to fetch something completely different
[19:09:23]<gregwhitworth>tab: yes you can query it regularly via JS
[19:09:40]<gregwhitworth>tab: I talked this over with my engineers, and they seems good with it
[19:10:07]<gregwhitworth>tab: not even relating to EQs we are interested in being about to declare layout boundaries for performance reasons
[19:10:26]<gregwhitworth>tab: you currently set a couple props, width, height, transform, relpos to make it a layout boundary
[19:10:46]<gregwhitworth>tab: if you forget, you go down a slow path instead of a fast path
[19:11:00]<gregwhitworth>tab: is everyone please with this?
[19:11:04]<Wilto_> 100%
[19:11:11]<gregwhitworth>grigs: makes a lot of sense to me
[19:11:27]<gregwhitworth>tab: as far as I know, this addresses everything I can think of it
[19:11:32]<gregwhitworth>wilto: this a good foundation
[19:11:39]<gregwhitworth>aarongustafson: this sounds good to me as well
[19:12:43]<AaronGustafson>invite zakim
[19:12:45]<gregwhitworth>Resolve: Tab to create a spec and submit it to the RICG mailing list
[19:12:57]<gregwhitworth>Action Tab: For the above resolution
[19:13:36]* Zakim has joined #respimg
[19:13:48]<AaronGustafson>I was almost there :-)
[19:13:52]<jrossi>zakim, where have you been all my life
[19:13:52]<Zakim>I don't understand 'where have you been all my life', jrossi
[19:14:17]<gregwhitworth>Action Tab to do the resolution above regarding creating a strawman spec
[19:14:39]<AaronGustafson>Do we want a log?
[19:14:39]<jrossi>action: Tab to do the resolution above regarding creating a strawman spec
[19:14:57]<Rossen>zakim are you there
[19:15:01]* trackbot has joined #respimg
[19:15:04]<Rossen>zakim, are you there?
[19:15:04]<Zakim>I don't understand your question, Rossen.
[19:15:05]* RRSAgent has joined #respimg
[19:15:05]<RRSAgent>logging to
[19:15:21]<TabAtkins>ACTION Tab to write up his proposal for EQ and send to RICG.
[19:15:21]<trackbot>Sorry, but no Tracker is associated with this channel.
[19:15:27]<Rossen>Action: Tab to do the resolution above regarding creating a strawman spec
[19:15:28]<trackbot>Sorry, but no Tracker is associated with this channel.
[19:15:28]* RRSAgent records action 1
[19:15:29]<Wilto_>Computers, man.
[19:15:33]<gregwhitworth>yoav: regarding element queries and the html inside has images
[19:15:33]<TabAtkins>trackbot, go away.
[19:15:33]<trackbot>Sorry, TabAtkins, I don't understand 'trackbot, go away.'. Please refer to <> for help.
[19:15:50]<gregwhitworth>yoav: I thought we resolved to wait until after layout
[19:16:00]<gregwhitworth>tab: yeah, that's why we need lazy load
[19:16:19]<Rossen>Action: Zakim, kill trackbot
[19:16:19]* RRSAgent records action 2
[19:16:19]<trackbot>Sorry, but no Tracker is associated with this channel.
[19:16:20]* jonathansampson has joined #respimg
[19:16:45]<gregwhitworth>grigs: is it an opt out
[19:16:53]<gregwhitworth>yoav: opt in, opt out
[19:16:56]<gregwhitworth>tab: opt around
[19:17:06]<gregwhitworth>yoav: you would need a sizes attribute on the section
[19:17:17]<gregwhitworth>grigs: is there a scenario where
[19:17:27]<gregwhitworth>grigs: if the author has declared layout-container: width
[19:17:42]<gregwhitworth>grigs: does sizes make sense at all
[19:17:49]<AaronGustafson>rrsagent, what are the action items?
[19:17:49]<RRSAgent>I see 2 open action items saved in :
[19:17:51]<RRSAgent>ACTION: Tab to do the resolution above regarding creating a strawman spec [1]
[19:17:52]<RRSAgent> recorded in
[19:17:53]<gregwhitworth>yoav: if we have this layout container control
[19:17:54]<RRSAgent>ACTION: Zakim, kill trackbot [2]
[19:17:55]<RRSAgent> recorded in
[19:18:18]<AaronGustafson>rrsagent, please drop action 2
[19:18:18]<RRSAgent>removing action 2, Zakim, kill trackbot
[19:18:19]<gregwhitworth>yoav: we probably don't want to download its images at all, we would want to opt out at the secion, not at the image layer
[19:18:29]<gregwhitworth>tab: that's not possible if we do this via CSS
[19:18:40]<gregwhitworth>yoav: yeah, we need some markup sygnal
[19:18:47]* zcorpan sees the bots are unusually helpful today
[19:18:55]* jlembeck has joined #respimg
[19:19:01]<gregwhitworth>tab: boris preferred it being in html
[19:19:06]<gregwhitworth>wilto: I would prefer it in CSS
[19:19:08]<gregwhitworth>tab: me too
[19:19:38]<gregwhitworth>yoav: the problem is, if you have both markup and css signal, if authors forget or purposefully omit the image will get loaded with the wrong dimensions
[19:19:56]<gregwhitworth>tab: we only care about this with images that have the width descriptor
[19:20:13]<gregwhitworth>yoav: and whether we want an opt out at the section level
[19:20:27]<gregwhitworth>yoav: for images to work here properly, we'll need some markup signal
[19:20:51]<gregwhitworth>aarongustafson: from an author standpoint, the width/height on an image and the css trumps it
[19:21:04]<gregwhitworth>aarongustafson: so you could have both and follow consistency
[19:21:19]<gregwhitworth>aarongustafson: it's a specificity thing really
[19:21:48]<gregwhitworth>wilto: nah, I think we have enough here to get us kicked off
[19:22:27]<gregwhitworth>gregwhitworth: do we want a forcing function
[19:22:32]<gregwhitworth>tab: yes this is polyfillable
[19:22:39]<gregwhitworth>yoav: yeah, but something that resembles this?
[19:22:42]* zcorpan has joined #respimg
[19:22:49]<gregwhitworth>tab: except that you can't do custom css today
[19:23:23]<gregwhitworth>yoav: maybe an action for wilto to polyfil this
[19:23:56]<gregwhitworth>wilto: I actually have somebody that has a very sound polyfil, and it's written in a super modular way
[19:24:03]<gregwhitworth>wilto: I can reach out to him
[19:24:28]<gregwhitworth>ilya: this is a little bit outside of EQs
[19:24:40]<gregwhitworth>ilya: but now that we have layout boundaries
[19:25:03]<gregwhitworth>ilya: being able to define priorities of certain sections, that may be possible now
[19:25:20]<gregwhitworth>tab: I think that is orthogonal, but it may be able to use this
[19:25:52]<gregwhitworth>ilya: assume that I have third party widget (facebook widget) and I want to prevent it from slowing my page load down
[19:26:08]<gregwhitworth>tab: yes, when we try to address that issue this could be used
[19:26:17]<gregwhitworth>ilya: this seems like the right primitive to use to address this
[19:26:38]* zcorpan has joined #respimg
[19:28:47]<gregwhitworth>grigs: How do we address the performance budget into account
[19:29:01]<gregwhitworth>ilya: the perf budget is more complicated than that
[19:29:22]<gregwhitworth>ilya: do you take cache into account, bandwidth, etc
[19:29:38]<gregwhitworth>ilya: in theory you could, but in practice, you don't want to do that due to transcoding
[19:29:52]<gregwhitworth>ilya: this leads into a discussion we will have this afternoon regarding client hints
[19:30:21]<gregwhitworth>ilya: this is a very hard area and we need to expirement with this
[19:30:35]<gregwhitworth>yoav: this is not something that you can hand code into HTML
[19:31:14]<gregwhitworth>ilya: this is why I keep asking for client hints because a relationship between client and server to handle the best image based on breakpoints and client hints
[19:31:39]<gregwhitworth>yoav: CSS in general, as a community how do we actually use these for regualr authors
[19:31:55]<gregwhitworth>grigs: those are acceptable answers, but it's on my mind a lot
[19:32:28]<gregwhitworth>grigs: I feel like the discussion has moved far enough long that we can discuss this with authors and introduce that puzzle
[19:34:18]<gregwhitworth>*break lunch*
[19:35:13]* Wilto has joined #respimg
[19:35:27]* iill has joined #respimg
[19:40:00]* zcorpan has joined #respimg
[19:41:43]* jrossi has joined #respimg
[19:46:49]* Wilto_ has joined #respimg
[19:47:19]* jonathansampson_ has joined #respimg
[20:40:53]* ShaneHudson has joined #respimg
[20:50:46]* zcorpan has joined #respimg
[20:53:02]* Wilto has joined #respimg
[20:54:10]* yoav has joined #respimg
[20:54:24]* Wilto has joined #respimg
[20:59:04]* yoav has joined #respimg
[20:59:07]<AaronGustafson>Are we back from lunch?
[20:59:20]<yoav>more or less
[20:59:26]<yoav>a few more minutes, I think
[20:59:29]<AaronGustafson>I guess it may be another :15 give or take
[20:59:33]<AaronGustafson>okey dokey
[21:00:49]* grigs has joined #respimg
[21:02:15]* jonathansampson_ has joined #respimg
[21:03:54]<Wilto>Ready whenever you guys are.
[21:04:04]* jrossi has joined #respimg
[21:12:20]<TabAtkins>ScribeNick: TabAtkins
[21:13:05]<TabAtkins>Topic: Client Hints
[21:13:33]<TabAtkins>yoav: Like we discussed earlier, Client Hints can significantly help to automate --- take the multiple resources of srcset out of markup and send the same data to the server.
[21:13:50]<Wilto>(thanks TabAtkins)
[21:14:03]<TabAtkins>yoav: It can be significantly better for the CDN usecase, and for the legacy content use-case, where I have tons of pages that I don't wanna go back and mess around with; I can just isntall server logic that'll do the srcset work for me.
[21:14:21]<TabAtkins>yoav: In terms of impl, I'm currently implementing in Blink behind a flag.
[21:14:32]<TabAtkins>yoav: The first two switches are the DPR and the RW (resource width) hint.
[21:14:46]<TabAtkins>yoav: RW falls back to viewport width when there's no other information o nthe size of the resource.
[21:14:53]<TabAtkins>yoav: Impl is still in very early stages.
[21:15:17]<TabAtkins>yoav: We also have from the Moz side, Marcos Caceres is interested in moving this along on the Moz side.
[21:15:23]<TabAtkins>yoav: Don't think they have any timeframes in mind.
[21:15:38]<TabAtkins>yoav: I dunno about webkit, we haven't really asked them.
[21:15:47]<TabAtkins>igrigorik: Before we get into the impl weeds, let me give some background.
[21:15:53]<TabAtkins>igrigorik: The spec itself has evolved over time.
[21:16:01]* zcorpan has joined #respimg
[21:16:07]<TabAtkins>igrigorik: There's a general problem of UA detection. Many companies are built around providing databases for UA strings.
[21:16:14]<TabAtkins>igrigorik: Some CDNs provide the service, etc.
[21:16:21]<TabAtkins>igrigorik: It's a pain in the ass and it's terrible.
[21:16:35]<TabAtkins>igrigorik: Devs are using this, though. They want to know about the brwoser so they can do special things.
[21:17:04]<TabAtkins>igrigorik: The first proposal for CH was a single header (CH) and we'd define a bunch of parameters in it, like DPR.
[21:17:14]<TabAtkins>igrigorik: After talking, we realized we're packing too many things into the one header.
[21:17:21]<TabAtkins>igrigorik: So we've unbundled it; each hint is its own header.
[21:17:36]<TabAtkins>igrigorik: So "Client Hints" is just a general name for the group of things you can send to the header now.
[21:17:47]<TabAtkins>igrigorik: So the DPR header is just something under the CH umbrella.
[21:18:08]<TabAtkins>igrigorik: I bring that up because, take the webp experience with Spartan - as we find new things that devs want, we want to be able to communicate that to the server.
[21:18:24]<TabAtkins>igrigorik: Some of those can be sent directly by the app dev - if you'r emaking an XHR, you can send whatever you want.
[21:18:36]<TabAtkins>igrigorik: Service Worker makes this even easier to do, you can send whatever information you want.
[21:18:46]<TabAtkins>igrigorik: Except for things that require native information, like the Resource Width.
[21:19:03]<TabAtkins>igrigorik: You could potentially RTT back to the renderer, but that's expensive, and doesn't work with preloader, etc.
[21:19:14]<TabAtkins>igrigorik: So that's one that needs to be implemented natively. Most others could be done by the app itself.
[21:19:18]* aarongustafson_ has joined #respimg
[21:19:26]<TabAtkins>igrigorik: Today yoav is implementing DPR and RW.
[21:19:34]<TabAtkins>igrigorik: The DPR doesn't really change, it's not resource-specific.
[21:19:52]<TabAtkins>igrigorik: But for the full image-optim use-case, it's useful to bundle it with RW so you can figure out what resolution to send down.
[21:20:00]<TabAtkins>yoav: So that's the reason to start with these two headers.
[21:20:18]<TabAtkins>yoav: The third one in the spec is "max download bandwidth", similar to the NetInfo API for downlinkMax.
[21:20:38]<TabAtkins>yoav: That could be handled as well by the browser, but it's also easy to do in ServiceWorker, so we're punting right now.
[21:21:00]<TabAtkins>igrigorik: In the future I see different apps wanting different types of hints. CH provides a way to opt in or out to certain types of hints to be sent.
[21:21:28]<TabAtkins>yoav: The downside of the opt-in, though, means you don't have hints for the initial HTML request (unless they're pinned or manifest or something).
[21:21:39]<TabAtkins>yoav: That's a big downside, some argue, for replacing the UA-sniffing use-case.
[21:21:54]<TabAtkins>yoav: But some people have objections to throwing in too much HTTP headers, because they stay around forever.
[21:22:15]<TabAtkins>jrossi: Also, sending everything means you don't have to modify any pages at all.
[21:23:14]<TabAtkins>yoav: If you're tackling the legacy content case, you can send an Accept-CH header in the HTML response, rather than putting it in a <meta> directly.
[21:23:32]<TabAtkins>yoav: So the controversy right now is whether to send CH headers in the first navigation to a server; what should we throw in?
[21:24:11]<TabAtkins>igrigorik: So that's ongoing. We can add other mechanisms to negotiate that sort of thing; storing prefs for future navigations, etc.
[21:24:29]<TabAtkins>igrigorik: So if I send a list of CHes to send, the UA remembers this for next time.
[21:25:19]<TabAtkins>david: Headers sent automatically affect packet sizes.
[21:25:47]<TabAtkins>igrigorik: Concretely, for RW and DPR, the nice thing is that you can turn a vanilla <img> tag into a DPR-sensitive tag without any syntax modifications.
[21:26:00]<TabAtkins>igrigorik: This is the legacy site use-case; you just point your images at a smarter server.
[21:26:37]<TabAtkins>yoav: This also impacts the 'w' usage, the Content-DPR header comes into play. The server tells the browser the resource's native density.
[21:26:43]<gregwhitworth>Attendees in the PM: Jacob Rossi, Tab Atkins, Tobin Titus, Yoav Weiss, Ilya Grigorik, Jason Grigsby, Mat Marquis, Aaron Gustafson, Todd Reifsteck, Adrian Bateman, Greg Whitworth, David Walp, Jonathan Sampson, David Storey
[21:26:51]<TabAtkins>yoav: In variable width case, you can still copmensate for that on the server side.
[21:27:04]<TabAtkins>david: So you're prototyping that?
[21:27:25]<TabAtkins>yoav: There's an experimental impl in Blink. It's not yet complete; RW is always viewport width, and http-equiv isn't yet implemented.
[21:27:46]<TabAtkins>david: Your thoughts on going forward? You taking this to W3C?
[21:27:50]<TabAtkins>yoav: It's an IETF RFC.
[21:27:52]<grigs>wait, David Storey is here?
[21:28:09]<TabAtkins>yoav: We're hoping that Moz will pick this up.
[21:28:17]<grigs>so many tweets and never met in person
[21:28:32]<TabAtkins>igrigorik: The HTTP WG has been heads-down on HTTP2. CH is on their list of specs. But the spec is trivial.
[21:28:54]<TabAtkins>igrigorik: We're not defining any new magical browser behaviors, besides Content-DPR, which is some plumbing.
[21:29:16]<TabAtkins>igrigorik: So if you have <picture> *and* these hints, how does the syntax change? You can push some of the markup functionality to the server.
[21:29:29]<TabAtkins>igrigorik: The README on github talks about this.
[21:29:48]<TabAtkins>mat: This is more srcset than <picture>?
[21:29:49]* Zakim excuses himself; his presence no longer seems to be needed
[21:29:49]* Zakim has left #respimg (Zakim)
[21:29:50]<TabAtkins>igrigorik: Yeah.
[21:30:15]<TabAtkins>mat: Is this removing some of the UA choice?
[21:30:27]<TabAtkins>TabAtkins: Entirely, yes. It's letting the server decide *instead of* the UA.
[21:31:08]<TabAtkins>mat: [paraphrasing] Would resources re-load when environment changes?
[21:31:16]<TabAtkins>yoav: Not defined; it's not defined for today's srcset either.
[21:31:31]<TabAtkins>aarongustafson_: That's an interesting case, a lot of people have two screens.
[21:31:37]<TabAtkins>jrossi: Or any casting scenario.
[21:32:06]<TabAtkins>igrigorik: I don't think whether we're using CH impacts this. Even with plain srcset, does it initiate a new fetch? If so, what do you advertise in CH?
[21:32:20]<TabAtkins>david: Have you thought about security? This is more info.
[21:32:36]<TabAtkins>yoav: There's no new fingerprinting risk. All of this info is already available in the page.
[21:32:42]<TabAtkins>TabAtkins: And trivially exfiltratable.
[21:32:57]<TabAtkins>grigs: So the scenario where you ahve an image in the page, the brwoser doesn't yet know the size of th eelement in the page.
[21:33:09]<TabAtkins>grigs: In the markup solution, we have srcset and sizes to help.
[21:33:19]<TabAtkins>grigs: Would we remove or modify these? How would this work?
[21:33:37]<TabAtkins>igrigorik: If you go to the README, it covers all these cases. Better to read that; I'll mess things up.
[21:34:04]<TabAtkins>igrigorik: But basically you'd omit srcset, and leave sizes. sizes affects the resource width, the server knows the set of sources.
[21:35:05]<TabAtkins>gregwhitworth: Thinking of how many images you have to generate, what sort of perf impact you have when you need to gen a new image.
[21:35:18]<TabAtkins>yoav: You can just pre-prepare them like you do today.
[21:35:45]<TabAtkins>yoav: And if you need to gen a new one, just serve one you already have at first, while genning it for the next person to need it.
[21:36:00]<TabAtkins>grigs: In these examples you have only one url listed, so there's a caching issue.
[21:36:07]<TabAtkins>igrigorik: We need Vary, but better than that.
[21:36:26]<TabAtkins>igrigorik: We need to implement smarter keygen and selection on the cache servers.
[21:36:40]<TabAtkins>igrigorik: So like "for images between 100px and 200px wide, this is the cached image".
[21:36:47]<TabAtkins>yoav: There is a standard called Key, which...
[21:36:54]<TabAtkins>igrigorik: In our tests with Vary, it's not really an issue.
[21:37:15]<TabAtkins>igrigorik: There are cases where Vary is totally broken, but I haven't seen them, and with HTTP2 it isn't necessary, becuase you have a direct connection to your cache server.
[21:37:24]<TabAtkins>yoav: Vary is broken on some proxies, but mostly works.
[21:37:37]<TabAtkins>yoav: Problem ist hat the Vary value may vary often. Without Key, you can't have caching buckets.
[21:37:51]<TabAtkins>igrigorik: When we say "Vary is broken", what we mean is that some proxies, when they see Vary, just don't cache at all.
[21:38:12]<TabAtkins>igrigorik: Key is an unrelated but useful spec by mnot.
[21:38:23]<TabAtkins>igrigorik: Still in motion, I think he's planning to rewrite it. It's Vary v2.
[21:38:34]<TabAtkins>igrigorik: Lets you specify a brief algo for how to construct the cache key from the data.
[21:38:55]<TabAtkins>igrigorik: So rather than "Vary on this header", can say "Vary on this substring of the header" or "Vary if the value is less than X", etc.
[21:39:04]<zcorpan>(i think people also forget to send a Vary header when they should)
[21:39:05]<TabAtkins>igrigorik: That becomes incredibly valuable for advertising dpr, etc.
[21:39:26]<TabAtkins>tobin: We're already seeing caches doing this on their own sometimes.
[21:39:57]<TabAtkins>grigs: What's the process by which new client hints are proposed and adopted?
[21:40:03]<TabAtkins>igrigorik: I'm treating the CH spec as a registry.
[21:40:09]<TabAtkins>igrigorik: You can come in with a PR and merge it.
[21:40:16]<TabAtkins>igrigorik: With ServiceWorker, you can advertise anything you want.
[21:40:31]<TabAtkins>igrigorik: For example, if you can query the current Window object in the client, you can send whatever information you want.
[21:40:47]<TabAtkins>igrigorik: So, can we develop common names for these headers? So we can have interop on servers.
[21:41:21]<TabAtkins>grigs: One of the things James Pierce said to me is when he was working with Device Atlas, one of the things that happens with the device detection dbs is that they're constnatly tracking the info people cared about two years ago.
[21:41:33]<TabAtkins>grigs: By the time things were codified, they weren't really an issue.
[21:41:46]<TabAtkins>grigs: So the ability to move things quicker...
[21:42:04]<TabAtkins>igrigorik: Difference is that you're not guessing, the client can figure out exactly what it wants to send.
[21:42:10]<TabAtkins>[jokes about ringtones]
[21:42:35]<TabAtkins>grigs: So as a web page author, you declare you want certain hints to be sent to the server.
[21:42:47]<TabAtkins>igrigorik: Some things need to be native to be performant, like RW.
[21:43:00]<TabAtkins>igrigorik: Then you'd opt-in to "yes, please send these hints to my server".
[21:43:43]<TabAtkins>igrigorik: But custom client hints, you just talk to your service worker for that.
[21:44:06]<TabAtkins>igrigorik: Right now, the first request is naked. The response says "I want these hints" in an Accept-CH
[21:44:24]<TabAtkins>igrigorik: And all following requests send those CHes.
[21:44:39]<TabAtkins>igrigorik: There's some people wanting them on the first request, but our networking team pushes back.
[21:44:52]<TabAtkins>igrigorik: So maybe there's a middle ground to deal with this, maybe remember for next time.
[21:45:01]<TabAtkins>gregwhitworth: In the non-native headers, why not X-Headers?
[21:45:28]<TabAtkins>igrigorik: Any custom headers you want to send, you can name them whatever.
[21:45:43]<TabAtkins>igrigorik: CH is just an umbrella term now for all the "hints" you "send" to the "client".
[21:46:04]<TabAtkins>yoav: You can put X- on your headers if you wnat. Or not. Up to you.
[21:46:44]<TabAtkins>todd: Specifically images are the requests we're most concerned about, for native CHes.
[21:47:16]<TabAtkins>todd: So if says they want some headers, and they have images from, they'll get the headers?
[21:47:17]<TabAtkins>yoav: Yes.
[21:47:25]<TabAtkins>todd: And if you have stylesheets, etc?
[21:47:27]<TabAtkins>yoav: Yes.
[21:47:32]* tobint has joined #respimg
[21:47:51]<TabAtkins>yoav: For a <link>, resource width would be viewport width, etc.
[21:48:06]<TabAtkins>igrigorik: It does make sense to send this info; you might want to modify the stylesheet based on DPR.
[21:49:10]<TabAtkins>igrigorik: Coming back to Key, that would let the server define what range of values the response is good for, so when the environement changes the brwoser can intelligently reuse or re-request.
[21:50:03]<TabAtkins>yoav: So what do y'all think?
[21:50:11]<TabAtkins>gregwhitworth: Sounds like the right appraoch to me.
[21:50:28]<TabAtkins>gregwhitworth: The caching stuff is outside my domain, but for the respimg part, I definitely like it.
[21:50:35]<TabAtkins>TabAtkins: Sounds good to me too.
[21:50:50]<TabAtkins>yoav: Thoughts on first request?
[21:52:51]* PicBot has joined #respimg
[21:52:57]<TabAtkins>david: If we narrow it down to just DPR and RW, maybe we can get some data on usage.
[21:53:46]<TabAtkins>igrigorik: I think there's a middle ground; maybe you don't get it on the very first visit, but we remember and send the requested headers on future navigations.
[21:53:56]<TabAtkins>TabAtkins: Similar to SW - you don't get it on the very first visit until it installs.
[21:53:59]<TabAtkins>david: Or HSTS.
[21:54:15]<TabAtkins>igrigorik: And for HSTS, we're discussing a pinning mechanism, so they dont' have to send HSTS on every request.
[21:54:59]* zcorpan has joined #respimg
[21:55:47]<TabAtkins>yoav: Example, the Upgrade-HTTPS header. Servers had to test brwosers to see if they can send https to the browser, or not. This header upgrades all http subresources to https.
[21:56:15]<TabAtkins>yoav: There's similarly a Prefer header sent every time. (to http navigations, not https)
[21:56:41]<TabAtkins>todd: So I think most of the room agrees that conceptually the idea is good, but until we get data it'll be harder to reason about the initial request.
[21:57:26]<TabAtkins>igrigorik: So for images we're not constrained.
[21:57:40]<TabAtkins>yoav: Even in the opt-in only scenario, we'll send it for all subresources, XHR included.
[21:58:12]<TabAtkins>todd: We're happy about that?
[21:58:25]<TabAtkins>david: I was talking about the initial request; later subresource requests are different.
[21:58:45]<TabAtkins>igrigorik: We're not forcing this on the whole internet, it's just websites that want it. And in practice they already do it, just with a cookie.
[21:59:22]<TabAtkins>igrigorik: But cookies are annoying; they don't sent to 3rd-party origins.
[21:59:23]<adrianba>maybe we need a preference that says to stop sending huge UA strings on subsequent requests in exchange for promising not to do broken sniffing
[22:00:02]<TabAtkins>Not a bad idea.
[22:04:10]<TabAtkins>RESOLVED: The DPR and RW client hints are good, write up a spec for them.
[22:05:03]<TabAtkins>igrigorik: So how do we take this further? We already have a spec.
[22:05:17]<TabAtkins>TabAtkins: Blink shipping guidelines just need other browser cooperation; get that and we can ship.
[22:06:28]<TabAtkins>todd: [looks at http client hints example about their effect on bytes downloaded]
[22:07:01]<TabAtkins>igrigorik: In HTTPArchive, in the next run we'll add data for image resizing; if we could deliver pixel-perfec timages, what would be the savings?
[22:07:17]<TabAtkins>tobin: We did that, and it was expensive to do.
[22:07:32]<TabAtkins>igrigorik: I'm hoping we'll get that in the March 15 run.
[22:07:53]<TabAtkins>igrigorik: We already run this data, we just throw it away and only record the score. We can start recording this information.
[22:08:04]<TabAtkins>tobin: We also looked at decoded image size.
[22:08:43]<TabAtkins>mat: Greg, you were running into, not resistrance, but reluctance about srcset/sizes syntax. Does the potential for CH alleviate that?
[22:08:55]<TabAtkins>gregwhitworth: We had that discussion this morning a bit; I think we're past that contentiousness.
[22:09:07]<TabAtkins>gregwhitworth: Our contention wasn't on us, just with authors.
[22:09:15]<TabAtkins>gregwhitworth: This sounds like the holy grail.
[22:09:50]<TabAtkins>gregwhitworth: There's still the question of whether they'll do good for mobile, etc. b
[22:10:05]<TabAtkins>yoav: If we implement only RW and DPR, we don't give the server side enough data...
[22:10:07]<TabAtkins>igrigorik: We can lie.
[22:10:22]<TabAtkins>yoav: Or we can send the max-download pref.
[22:10:41]<TabAtkins>gregwhitworth: I'd prefer not lying, because we'll have people reverse-engineering based on browser version.
[22:11:42]<TabAtkins>igrigorik: We've tried to break that assumption of perfection with srcset. And like with the Chrome data compression proxy, we'd probably want to always pull the 1x version regardless.
[22:11:57]<TabAtkins>TabAtkins: And if you *really* want control, you can just use <source media> to get precise control.
[22:12:39]<TabAtkins>tobin: And quality is actually worse if you send a big image that's scaled down on the client, because bilinear looks bad. Better to send a properly-prepared version.
[22:12:51]<TabAtkins>igrigorik: So I'm hearing positive signals to take back to the Blink team.
[22:13:05]<TabAtkins>igrigorik: We'll try to get more data as well, on savings.
[22:13:13]<TabAtkins>yoav: I'll try to get some signals from the WebKit folks.
[22:13:28]<TabAtkins>yoav: There's a webkit contributors meetup next week.
[22:13:36]<TabAtkins>todd: Let's imagine that clients implemented this.
[22:13:51]<TabAtkins>todd: I dunno what percentage of CDNs take what % of images...
[22:14:00]<TabAtkins>todd: How long would it take to have them switch over?
[22:14:08]<TabAtkins>yoav: I have one CDN I know about...
[22:14:22]<TabAtkins>igrigorik: I know a guy from Akamai said they can support it with the current syntax.
[22:14:35]<TabAtkins>yoav: Can't comment on record, but it's defintely... interesting for Akamai.
[22:14:55]<TabAtkins>todd: Does httparchive know what cdns are being used?
[22:15:01]<TabAtkins>igrigorik: Not tracked currently, but the data is there.
[22:15:22]<TabAtkins>igrigorik: The Moz bug on CH has a good discussion with various providers saying that if it's implemented, they'll support.
[22:15:37]<TabAtkins>igrigorik: CDNConnect, Akamai, Imagex, some others.
[22:17:17]<TabAtkins>Topic: Pre-*
[22:17:29]<TabAtkins>igrigorik: All browsers have implemented pre-rendering, etc in an unofficla way.
[22:17:45]<TabAtkins>igrigorik: Lots of heuristics, etc. But it's been very valuable in optimizating nav performance.
[22:17:55]<TabAtkins>igrigorik: We don't have consistency between browsers on how to handle this.
[22:18:01]<TabAtkins>igrigorik: When to do fetches, how many, etc.
[22:18:21]<TabAtkins>igrigorik: Preconnect, for example. Every browser supports DNS prefetch, but there's no explicit signal to preconnect to a host.
[22:18:35]<TabAtkins>igrigorik: Very valuable, though - you know you're getting *something* from an origin, but don't know what it is yet.
[22:18:55]<TabAtkins>igrigorik: That's an issue; https is slow, etc. Woudl be nice to provide that as a hint.
[22:19:20]<TabAtkins>igrigorik: So Resource Hints is my attempt to get browsers to do this sort of thing consistently.
[22:19:29]<TabAtkins>igrigorik: Currently broken in Chrome is subresource hinting.
[22:19:39]<TabAtkins>igrigorik: I tell people not to use it, too easy to shoot yourself in hint.
[22:19:44]<TabAtkins>igrigorik: So Resource Hints adds some hints.
[22:19:57]<TabAtkins>igrigorik: First is preconnect - you specify the origin you want to preconnect to.
[22:20:07]<TabAtkins>igrigorik: Very close to being finished. Our goal is to get it on Chrome 43.
[22:20:20]<TabAtkins>igrigorik: Next is preload.
[22:20:31]<TabAtkins>igrigorik: Spec started as just Resource Hints, but now Preload split out.
[22:20:39]<TabAtkins>igrigorik: Because Preload has mandatory semantics; others are speculative.
[22:20:51]<TabAtkins>igrigorik: Currently platform couples download and execution of assets.
[22:21:07]<TabAtkins>igrigorik: You can download a stylesheet, but can't say "dont' parse/apply/evaluate it".
[22:21:19]<TabAtkins>igrigorik: Preload lets you do that, download it now, but not apply it yet.
[22:21:34]<TabAtkins>igrigorik: This lets you write smarter resource loaders, lets you ipmlement <script async>, etc.
[22:22:07]<TabAtkins>igrigorik: So download now, put it into http cache, and sometime later I"ll actually fetch it.
[22:22:22]<TabAtkins>igrigorik: So when the browser hits <link rel=preload>, brwoser is required to fetch it.
[22:22:29]<TabAtkins>igrigorik: While other resource hitns, the browser can ignore if they want.
[22:22:37]<TabAtkins>igrigorik: Anyway, Yoav is working on preload in Blink.
[22:22:44]<TabAtkins>yoav: Very very early stages, nothing committed yet.
[22:23:17]<TabAtkins>igrigorik: [sets up projector]
[22:25:10]<TabAtkins>igrigorik: The new interesting thing that makes subresource hint break, is the lack of specifying the type of resource; we didn't know the priority to fetch with.
[22:25:32]<TabAtkins>igrigorik: Without that, we didn't know when to fetch it. If it was a critical resource, we'd just load it at medium priority, which could slow you down.
[22:26:02]<TabAtkins>igrigorik: Then you can apply a MQ.
[22:27:46]<TabAtkins>igrigorik: And it's possible to lie about as='', loading an image with stylesheet priority. There's actual use-cases for this.
[22:28:19]<TabAtkins>igrigorik: More relevant to resource hints; the UA when it fetches can do something smart.
[22:28:33]<TabAtkins>igrigorik: If you fetch an image asset, when you're idle you might decode it ahead of use.
[22:28:43]<TabAtkins>igrigorik: By default the user agent is allowed to do that, but doesn't force.
[22:29:01]<TabAtkins>igrigorik: If loadpolicy="inert", though, the UA definitely does nothing besides fetch.
[22:29:11]<TabAtkins>igrigorik: This lets us distinguish a prerender from a prefetch for HTML.
[22:30:42]<TabAtkins>gregwhitworth: What's the lifetime of preloaded things?
[22:31:14]<TabAtkins>igrigorik: Initially it's just an Http fetch, goes into the http cache. To use it, you make a script tag. If, in between, your cache got dumped, it would just make a new request.
[22:31:30]<TabAtkins>igrigorik: So there's a question about what to do with nocache. ^_^
[22:32:07]<TabAtkins>igrigorik: In Blink, at least, we remember nocache resources for the rest of the session.
[22:32:43]<TabAtkins>grigs: The as='' image, those aren't mimetypes or anything...
[22:32:54]<TabAtkins>igrigorik: They're the "request context" from the Fetch spec.
[22:33:12]<TabAtkins>todd: is the priority of the request contexts actually specified?
[22:33:12]<aarongustafson_>Gotta jump. Thanks for making today happen. You all rock!
[22:33:33]<gregwhitworth>thanks for attending aarongustafson_
[22:33:38]* aarongustafson_ has left #respimg (aarongustafson_)
[22:33:41]<TabAtkins>igrigorik: No, not at all. Browser can do anything. They should just preload with the same priority as they would do a normal load.
[22:34:09]<TabAtkins>todd: A little weird, since browsers have different orderings. People would test on one browser and optimize badly for others.
[22:35:06]<TabAtkins>gregwhitworth: How *do* we respond to that?
[22:35:27]<TabAtkins>igrigorik: This is already the case. If you, say, decided that font loads are more important than html loads, there's not much pages can do.
[22:36:01]<TabAtkins>gregwhitworth: This came up in Houdini too. As we get closer to the metal, we have to start considering standardizing things that we'd never standardized before, like load order.
[22:36:45]<TabAtkins>igrigorik: For Http2, we now have a lot more flexibility to change things around.
[22:36:58]<TabAtkins>igrigorik: Like we now have a prioritization based on dependency trees.
[22:37:23]<TabAtkins>grigs: Is the only use of as='' is for priority?
[22:37:25]<TabAtkins>igrigorik: Yes.
[22:39:30]<TabAtkins>grigs: If prioritizaton is in flux (which I think it is), it seems like this is the wrong time to be encouraging web authors to try to solve the AirBnB situation by declaring an image to be as='html'.
[22:39:47]<TabAtkins>igrigorik: The prioirization relative to resoruces has always been in flux. We change it regularly.
[22:40:11]<TabAtkins>igrigorik: Regardless of what you do, you don't want all things of a certain type to be lower priority as a class. Right now, all images are lower than all stylesheets.
[22:41:04]<TabAtkins>todd: We could in the future have more keywords like "low" and "high".
[22:41:13]<TabAtkins>david: We'd want to interoperate with the http2 behavior.
[22:41:40]<TabAtkins>igrigorik: Right, but really the lying use-case isn't primary; it's possible, but we're mainly optimizing for truth, which is still important to get things right.
[22:42:08]<TabAtkins>[something weird about details of http2 priorization]
[22:42:16]<TabAtkins>[not minuting because lol]
[22:43:26]<TabAtkins>mat: I've never told a lie. It's the right thing to do.
[22:44:07]<TabAtkins>grigs: I just think that when somebody sees as='', there's an impulse in people's mind to hijack this.
[22:44:50]<TabAtkins>grigs: If I saw type='', it sounds like I need to tell the browser what it is. When I see as='', it's more "oh, I can tell the browser to load this *as* anything I want".
[22:44:56]<TabAtkins>igrigorik: That's literally the whole point.
[22:46:23]<TabAtkins>grigs: This keeps sticking in my mind as something dangerous because the early attempts as respimg were all based on a current understanding of how brwosers were going to prioritize downloading images, then all of that changed.
[22:46:42]<TabAtkins>grigs: I'm reticent to encourage authors to declare an image as html...
[22:46:46]* yoav has joined #respimg
[22:47:13]<TabAtkins>igrigorik: We're not. You have to specify as='' if you want your resource to be loaded with the correct priority. That's it. Without as='' you have the footgun scenario of subresource.
[22:47:21]<eeeps>The RICG: Optimizing for Truth™
[22:48:35]<TabAtkins>grigs: I'm just having a problem with the name itself. A better name that encourages truthfulness would be better.
[22:49:33]* grigs has joined #respimg
[22:50:27]<TabAtkins>[more discussion about whether as='' encourages people to lie]
[22:51:36]<TabAtkins>Topic: Dynamic scheduling
[22:51:44]<TabAtkins>igrigorik: I think only Chrome does this with current hints
[22:51:53]<TabAtkins>igrigorik: If you create an element and insert it into the dom, do you execute the hint?
[22:52:02]<TabAtkins>igrigorik: Never been specced. We use it for Chrome.
[22:52:11]<TabAtkins>igrigorik: Search does it, we call it "reactive prefetch".
[22:53:05]<TabAtkins>igrigorik: We crawl the sites, so in parallel with you clicking the link to the page, we inject some prefetches to start downloading the css/etc already. So by the time you get to the page, the resources are already there, or close to it.
[22:53:20]<TabAtkins>igrigorik: This only happens when you click, so it's "reactive".
[22:53:36]<TabAtkins>igrigorik: It's not a prerender, because we *know* you want this; you clicked it. Prerenders are still kinda optional.
[22:54:02]<TabAtkins>igrigorik: You can think of more; in an image gallery, you want to prefetch the next page of images before they click to them.
[22:54:15]<TabAtkins>igrigorik: Link header interop.
[22:54:22]<TabAtkins>igrigorik: I think FF is the only one that supports Link header.
[22:54:28]<TabAtkins>igrigorik: (Yoav is working on it.)
[22:54:56]<TabAtkins>igrigorik: Important use-case is to send hints without having to rewrite the <head>.
[22:55:15]<TabAtkins>yoav: With our initial impl, we see a signif difference with links in headers versus html.
[22:55:54]* zcorpan has joined #respimg
[22:56:09]<TabAtkins>yoav: I'm implementing this on a rel-by-rel basis; I have no use-case for stylesheets as a Link header.
[22:56:16]<TabAtkins>yoav: So I'm not intending to implement stylesheets yet.
[22:57:01]<TabAtkins>igrigorik: So Resource Hints uses preload as a base, and extends it with some speculative primitives.
[22:57:07]<TabAtkins>igrigorik: Preconnect, which we already talked about.
[22:57:15]<TabAtkins>igrigorik: It's the UA decision whether to preconnect or not.
[22:57:23]<TabAtkins>igrigorik: Next is preload-with-additional-policies.
[22:57:29]<TabAtkins>igrigorik: Previous spec had "inert".
[22:57:48]<TabAtkins>igrigorik: This has "next", which means you'll need it for the next navigation. Equivalent of today's prefetch.
[22:57:59]<TabAtkins>igrigorik: The UA may or may not fetch it, maybe do it with a lower priority.
[22:58:34]<Wilto>Alright, I’m being gestured at; I gotta run. Thanks so much for this, guys—relay that to anyone not in the channel for me, yeah?
[22:59:02]* TabAtkins Will do, Wilto.
[22:59:10]* bruceontheloose has joined #respimg
[22:59:26]<gregwhitworth>have a good one wilto!!
[22:59:36]<TabAtkins>igrigorik: Difference between "next" and "next inert": "next" lets you do a prerender of an html page. "next inert" will just be a prefetch, no processing happens.
[22:59:59]* yoav has joined #respimg
[23:00:26]<TabAtkins>jonathansampson: Isn't this just rel=prerender?
[23:00:40]<TabAtkins>igrigorik: It might be defined as an alias for this. We tried to spec down to low-level primitives.
[23:01:04]<TabAtkins>yoav: What's likely different is that you opt out of prerender instead of opting into it.
[23:01:28]<TabAtkins>igrigorik: One controversial part is "hint probability" - let you communicate how likely it'll happen.
[23:02:16]<TabAtkins>tobin: I can see people changing this as the mouse moves closer to a link target.
[23:03:13]<TabAtkins>adrianba: We use similar things on Accept-Language
[23:03:44]<TabAtkins>igrigorik: In some cases you have plenty of spare capacity where you're willing to do more work. You're on your desktop, can prerender 25 tabs. On mobile, not the case.
[23:03:51]<TabAtkins>igrigorik: So this lets you distinguish that.
[23:04:51]<TabAtkins>igrigorik: I could see it just being used by the UA by ordering them by pr and just loading N of them.
[23:05:00]<TabAtkins>todd: And the pr is within its as='' bucket.
[23:06:36]<TabAtkins>todd: Does pr only apply to "next"?
[23:06:38]<TabAtkins>igrigorik: No, all.
[23:07:41]<TabAtkins>todd: So if I have 15 as='image', and some have pr on them, how are they ordered relative to the ones without pr?
[23:07:45]<TabAtkins>igrigorik: Not specified right now.
[23:07:51]<TabAtkins>yoav: Probably default to 1.0
[23:08:22]* jrossi has joined #respimg
[23:08:44]<TabAtkins>tobint: I could see people wanting to partially control execution - more than inert, less than full.
[23:08:54]<TabAtkins>igrigorik: We haven't thought about that yet.
[23:09:18]<TabAtkins>igrigorik: Probably crazy talk; makes things way more complicated. But not crazy in theory.
[23:10:26]<TabAtkins>igrigorik: So prerender is very expensive on mobile, for lots of reasons. rel=prerender is mostly disabled on mobile devices.
[23:10:42]<TabAtkins>igrigorik: We'd like to be smarter; preload and do a preload scanner, but not load the rest of the page.
[23:13:34]<TabAtkins>TabAtkins: I like how, even if pr is used just as a priority by the browser, casting it as a probability gives authors an idea of what value to put in. If its datatype was a long, there's no guidance on what values to use; a probability lets them legitimately say "one in five people go to this page later, so use .2 as the value".
[23:15:06]<TabAtkins>todd: Some feedback is that when authors give these hitns, it's for cold-start. Afterwards, the browser has enough info to do better ideas anyway.
[23:15:23]<TabAtkins>igrigorik: We found this useful for apps, dynamically injecting preloads and such as you switch between screens.
[23:16:03]<TabAtkins>yoav: In terms of a Link header impl, do you have any thoughts?
[23:16:24]<TabAtkins>david: Just something that hasn't happened yet, I think. No objections.
[23:16:42]<TabAtkins>tobint: Originally you had some ideas of "falling back" to lesser forms of preloading. Is that still there?
[23:17:01]<TabAtkins>tobint: If you said "prerender" and browser can't afford to, it would drop down to a preload.
[23:17:43]<TabAtkins>igrigorik: Hinted in the spec; if you can't prefetch, you can just preload, or just preconnect, etc.
[23:17:49]<TabAtkins>tobint: Was there feedback causing that change?
[23:17:56]<TabAtkins>igrigorik: No, we're planning to do fallback in Chrome.
[23:18:18]<TabAtkins>igrigorik: Prerendering is too expensive on mobile, so we're going to fall back to cheaper things.
[23:18:26]<TabAtkins>yoav: Is preconnect defined across navigations?
[23:18:30]<TabAtkins>igrigorik: Yes, it's defined as such.
[23:19:30]<TabAtkins>todd: So if you implement preload, and you haven't implemented "next" yet, they'll get a wrong mandatory behavior.
[23:19:51]<TabAtkins>TabAtkins: So just implement them at the same time.
[23:19:58]<TabAtkins>gregwhitworth: Yeah, that's not a joke. Spec might need to call that out.
[23:22:02]<TabAtkins>TabAtkins: If you can figure out how to coalesce types of preload requests, you can adopt the same kind of behavior CSS does - allow them to specify the same thing multiple times, where more primitive versions come first, and best version is last; last one the browser understands is used.
[23:22:23]<TabAtkins>TabAtkins: Sometimes hard to figure out how to coalesce. CSS is easy, it coalesces by property name in a single rule.
[23:23:01]<TabAtkins>igrigorik: The only missing pieces to me are fetch settings for http2 (priorities, dependencies), and then CSS.
[23:24:45]<TabAtkins>igrigorik: Letting CSS-initiated fetches describe these things.
[23:24:57]<TabAtkins>TabAtkins: [describes how you can basically put JSON inside of the url() function]
[23:25:48]<TabAtkins>igrigorik: And finally, a way to define that some resources should be fetched immediately, rather than waiting for content to match and require it.
[23:26:15]<TabAtkins>todd: And I suppose that the set of client hints can get bigger as the internet invents new popular ones via Service Worker.
[23:26:17]<TabAtkins>igrigorik: Yes.
[23:26:50]<TabAtkins>gregwhitworth: I'm interesting int he bandwidth one.
[23:26:56]<TabAtkins>igrigorik: Well we have the NetInfo API.
[23:27:01]<TabAtkins>igrigorik: This is the third version of it now.
[23:27:08]<TabAtkins>igrigorik: We have type and downlink max.
[23:27:17]<TabAtkins>igrigorik: Type is high-level bucket, like cellular or ethernet.
[23:27:34]<TabAtkins>igrigorik: downlinkMax sets either theoretical max, or if UA has better estimate, it can report that instead.
[23:27:54]<TabAtkins>igrigorik: So you cna query that attribute and get a value back to say how fast the user is.
[23:28:02]<TabAtkins>igrigorik: [example with service worker]
[23:28:23]<TabAtkins>igrigorik: Adding an MD header with Service Worker to tell all outgoing requests what the max download is.
[23:30:03]<TabAtkins>igrigorik: Already this is proven useful for Chrome, as we previously had to do all sorts of hacky guessing for what kind of connection you have.
[23:30:58]<TabAtkins>gregwhitworth: I think there's more than enough demand from authors.
[23:31:11]<TabAtkins>adrianba: Don't doubt there's demand, just doubt people will do something useful with it.
[23:32:38]<TabAtkins>[discussion about bandwidth info misuse]
[23:33:05]<TabAtkins>gregwhitworth: Like with Houdini, people are already doing these things terribly on their own.
[23:33:23]<TabAtkins>adrianba: This is better than previous. The other thing I was pushing for is to get a metered network signal.
[23:33:32]<TabAtkins>yoav: It was there, but was removed. Don't remember why.
[23:34:46]<TabAtkins>adrianba: We have an existence proof for its usefulness - apps that won't update until you connect to wifi.
[23:35:57]<TabAtkins>yoav: One issue is what "metered" means.
[23:36:11]* marcosc has joined #respimg
[23:36:25]<TabAtkins>TabAtkins: Some OSes let you dictate whether a wifi is metered or not.
[23:36:35]<TabAtkins>todd: Windows can tell if you're wifi-ing through a phone, and call it metered.
[23:36:52]<TabAtkins>gregwhitworth: I don't think it's reasonable for users to do all of that themselves.
[23:37:03]<TabAtkins>adrianba: There's smarts to make some of the obvious distinctions.
[23:37:23]<TabAtkins>adrianba: But when connecting to wifi, it assumes it's wifi. So I still have to set it as metered when I connect to my MyFi.
[23:37:43]<TabAtkins>adrianba: Then I can control in apps what to do in metered data.
[23:39:04]<TabAtkins>igrigorik: I'm reading my own notes -
[23:39:09]<TabAtkins>igrigorik: They say "metered is mostly a lie".
[23:39:22]<TabAtkins>igrigorik: Looking at our previous impl, they just mapped all cell to metered. That's it.
[23:39:37]<TabAtkins>igrigorik: So that's why it was taken out - an attempt to simplify.
[23:40:04]<TabAtkins>TabAtkins: But it seems we've increased the amount of correc tinformation now.
[23:40:13]<TabAtkins>igrigorik: Right, so it might make sense to come back with it.
[23:40:36]<TabAtkins>adrianba: Gonna be extra important when we add background-sync to Service Worker.
[23:41:42]<TabAtkins>igrigorik: One earlier proposal we didin't pursue was, instead of a metered boolean, have an enum with some values making it more precise.
[23:42:09]<TabAtkins>jrossi: We have this in the winRT system.
[23:43:12]<TabAtkins>igrigorik: Any usage data?
[23:43:18]<TabAtkins>jrossi: I'm sure we can go find it.
[23:44:55]<TabAtkins>jrossi: We have more reliable info from your carrier, or on Windows Phone there's a dataSense app that lets you specify your sim info and the OS tracks that.
[23:45:15]<TabAtkins>adrianba: We don't have many apps using that. Facebook, for example, just uses the "dont' do background syncing" kind of thing.
[23:45:29]<TabAtkins>adrianba: Just blocks photo uploads and similar things. One simple toggle.
[23:46:05]<TabAtkins>igrigorik: We've been talking with providers to see if we can query the phone and ask it for its data plan.
[23:46:18]* gregwhitworth has joined #respimg
[23:46:23]<TabAtkins>adrianba: We have the reverse - carriers can provide an XML file with the provisioning. Not sure how it's updated.
[23:47:04]<TabAtkins>jrossi: One more bit on the WinRT API is roaming status - indicating that these bytes are *expensive*.
[23:47:28]<TabAtkins>igrigorik: So info from carriers is how many bytes are left on the plan, how many users, and status (active/roaming/etc).
[23:47:56]<TabAtkins>yoav: There's some privacy implications there.
[23:48:08]<TabAtkins>igrigorik: This is just for the OS/browser to consume, not JS.
[23:48:27]<gregwhitworth>yoav: That is awesome!
[23:50:26]<TabAtkins>TabAtkins: I think we could usefully provide three buckets - cheap (wifi), metered (sim), expensive (roaming). Don't think you can justify more than three.
[23:50:46]<TabAtkins>[some rehashing of the current NetInfo api]
[23:52:20]<TabAtkins>jrossi: I just don't know the use-case for whether it's bluetooth or wifi or the like.
[23:52:42]<TabAtkins>yoav: An interesting extension is if theoretically we could get future/allocated bandwidth from the network cards.
[23:52:57]<TabAtkins>yoav: Similarly to talking to the operators for the billing info to expose a cost.
[23:53:11]<TabAtkins>yoav: So we could maybe get the downlink max numbers from the operators.
[23:53:24]<TabAtkins>igrigorik: There's no way to know what is.
[23:53:26]* jrossi has joined #respimg
[23:53:48]<TabAtkins>igrigorik: It's so transient, 4g networks assign on the order of milliseconds.
[23:54:05]<TabAtkins>igrigorik: Being able to map yourself to a generation does give you the range of possible latency.
[23:54:21]<TabAtkins>igrigorik: 4g generally has pretty good latency; can be high or low, but on 3.5g it'll be higer.
[23:55:54]<TabAtkins>Meeting adjourned.