| 02:48 | <JosephSilber> | TabAtkins, can srcset handle switching of both size and resolution (2x, 3x) for a single image? |
| 03:36 | <TabAtkins> | JosephSilber: Yes, you can use multiple <source srcset> elements, one for each media query. |
| 03:37 | <JosephSilber> | TabAtkins, Is that for picture or img? |
| 03:37 | <JosephSilber> | I'm talking about image srcset. No art direction. |
| 03:38 | <TabAtkins> | If you dont' care about art direction, what did you mean by "switching of size"? |
| 03:42 | <JonathanNeal> | Does http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.from define how Array.from should handle primatives? |
| 03:43 | <JonathanNeal> | I am having trouble understanding http://people.mozilla.org/~jorendorff/es6-draft.html#sec-toobject - what happens a Boolean, for instance? |
| 03:44 | <TabAtkins> | JosephSilber: If you mean that you don't know how large the image will be (because its size is a percentage, or uses other units that might not be resolvable to pixels ahead of time), then you use the w unit rather than x; srcset will handle things for you. |
| 03:44 | <JosephSilber> | TabAtkins, Apple *still* doesn't support width based srcset :( |
| 03:44 | <JosephSilber> | Even in iOS8 |
| 03:44 | <TabAtkins> | JonathanNeal: It returns a Boolean object. That's different from a boolean value, note. |
| 03:44 | <TabAtkins> | JosephSilber: Yeah, they haven't finished things out yet. :/ |
| 03:45 | <JosephSilber> | Does anyone remember when the iPhone launched, and it had the most advanced mobile browser? |
| 03:45 | <JosephSilber> | What a joke that is now. |
| 03:45 | <JosephSilber> | They don't even do validation :/ |
| 03:45 | <JosephSilber> | How long has that been around for...? |
| 03:45 | <JonathanNeal> | I see, so it’s like `Object(true)`. No keys, but somehow still true. |
| 03:46 | <TabAtkins> | JonathanNeal: Boolean(false) is truthy. ^_^ |
| 03:46 | <TabAtkins> | (All objects are truthy.) |
| 03:46 | <JonathanNeal> | Fun! |
| 03:46 | <TabAtkins> | Yeah, it's great. |
| 03:49 | <JosephSilber> | Why doesn't srcset support infinite sizes, with a server-side script rendering whatever size the client needs? |
| 03:50 | <TabAtkins> | JosephSilber: Client Hints is an effort to work on that. |
| 03:50 | <TabAtkins> | Which will work nicely with srcset. |
| 03:51 | <JosephSilber> | TabAtkins, I'm saying that I want the client to decide, not the server. |
| 03:51 | <JosephSilber> | Let the client tell the server what size it wants. |
| 03:51 | <TabAtkins> | The server can do whatever it wants. All we can do is tell it what the resolution/etc is, which is what Client Hints does. |
| 03:52 | <JosephSilber> | The server shouldn't care about dpr, network speed or whatever else |
| 03:52 | <JosephSilber> | srcset is built so that the browser can take into account everything it know to and pick the correct image. |
| 03:52 | <JosephSilber> | Why not let it pick from an infinite pool? |
| 03:53 | <TabAtkins> | That's literally what I'm saying. |
| 03:53 | <JosephSilber> | Client Hints would have the server do a reimplementation of srcset's algorithms, of which many factors can't even be sent to the server. |
| 03:54 | <JosephSilber> | What I'm saying is: "Hello, I'm a server. I have an image that is 3000px x 4000px. Tell me which size you want." |
| 03:54 | <TabAtkins> | That's what you end up with, yes. |
| 03:55 | <JosephSilber> | "I don't care about your dpr. I don't care about your network speed. I don't care about your viewport size. I don't care about your element size. Just give me dimensions." |
| 03:55 | <JosephSilber> | Then I misread this: https://github.com/igrigorik/http-client-hints |
| 03:55 | <JosephSilber> | I don't see anything in there that would support this. |
| 03:58 | <TabAtkins> | client hints can certainly vary what it gives in the rw and dpr values to match exactly what it wants. |
| 04:03 | <JonathanNeal> | Am I to assume that Array.from is enumerable or not enumerable when it does not specify? |
| 04:06 | <TabAtkins> | The method? built-ins generally aren't enumerable. |
| 04:06 | <TabAtkins> | If it doesnt' actaully specify, it's a spec bug, but I'll bet it does, just in a confusing and indirect way. |
| 04:11 | <caitp-> | test262 seems to assert certain properties for functions of builtins that don't seem to be specified anywhere |
| 04:11 | <caitp-> | well, maybe it does say "function properties of builtin types don't have prototypes" somewhere, but I haven't found it :c |
| 04:17 | <JonathanNeal> | Last question. When Array.from converts length to a number, and the length is Infinity, should it throw an error? I don’t see something to throw that. Instead, it looks like it passes it along before it gets capped by min(length, 253-1). |
| 04:18 | <JonathanNeal> | e.g. If number is +0, −0, +∞, or −∞, return number … Return min(len, 253-1) |
| 04:18 | <JonathanNeal> | Sorry for the formatting change on 2(little 53). |
| 04:53 | <Domenic> | caitp-: JonathanNeal: the spec says things about built-in functions having no prototype, and built-in methods being nonenumerable |
| 04:54 | <Domenic> | JonathanNeal: doesn't Array.from use ToLength? I thought that capped Infinity. |
| 04:54 | <caitp-> | it does |
| 04:55 | <JonathanNeal> | When does ToLength cap Infinity? |
| 04:55 | <caitp-> | it caps at 2^53-1 iirc |
| 04:56 | <Domenic> | step 5, Return min(len, 253-1). |
| 04:56 | <Domenic> | min(Infinity, 2^53 - 1) is 2^53 - 1 |
| 04:56 | <JonathanNeal> | Yea, so it won’t throw. |
| 04:56 | <Domenic> | so yeah it shouldn't throw |
| 04:56 | <JonathanNeal> | It will cap, am I understanding that right? |
| 04:56 | <Domenic> | indeed |
| 04:56 | <caitp-> | it won't go higher |
| 04:57 | <JonathanNeal> | There’s really no way to pass an invalid length, then. |
| 04:57 | <caitp-> | yeah isn't it great? |
| 04:58 | <Domenic> | not true |
| 04:58 | <Domenic> | you could pass { valueOf() { throw new Error("boo!"); } } |
| 04:58 | <caitp-> | not sure that's a compelling useful thing to do though =) |
| 04:59 | <Domenic> | built-in defaults defined in https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-standard-built-in-objects |
| 04:59 | <Domenic> | (hmm that "ECMAScript" prefix seems redundant on the section heading) |
| 04:59 | <JonathanNeal> | Domenic: okay, in 99% of the cases other than explicitly telling the thing to throw, it will not. |
| 05:00 | <Domenic> | I mean, yes, it generally avoids throwing. |
| 05:00 | <Domenic> | Just like +x generally avoids throwing |
| 05:00 | <Domenic> | or parseInt |
| 05:04 | <JonathanNeal> | Thanks, Domenic. |
| 05:05 | <JonathanNeal> | “generally” made me laugh out loud. |
| 05:09 | <caitp-> | there are cases where @@toStringTag will cause things to throw, and i worry how that will affect dev tools :( but I guess there's nothing you can do about it |
| 05:32 | <JonathanNeal> | Ugh, index in array fails when array[index] = undefined in IE6-8. |
| 05:35 | <caitp-> | fails? |
| 05:39 | <JonathanNeal> | index in array returns false |
| 05:39 | <JonathanNeal> | when that index has a value of undefined |
| 05:43 | <JonathanNeal> | Likewise, for (index in array) will skip indexes/keys with a value of undefined. |
| 05:44 | <JonathanNeal> | In short, 0 in [undefined] is false |
| 05:48 | <JonathanNeal> | Reading all about the fun here https://github.com/es-shims/es5-shim/issues/190 |
| 05:50 | <caitp-> | that's interesting |
| 05:57 | <JonathanNeal> | Yea, that’s a pretty major flaw. |
| 06:04 | <caitp-> | well it won't be long before people stop caring about ie8 |
| 06:04 | <caitp-> | one imagines |
| 06:07 | <JonathanNeal> | Yes, huzzah, the end times are near, ie8, they always are. |
| 07:13 | <annevk_> | Domenic: arv: your call: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26178 |
| 10:24 | <smaug____> | oh, lowercase fetch |
| 10:24 | <smaug____> | annevk: what was the reason to go with fetch() and not with some less-likely-to-be-used-in-web-pages name? |
| 10:25 | <annevk> | smaug____: I don't recall |
| 10:31 | <smaug____> | it is super annoying that we need to think about existing pages when exposing new APIs |
| 10:37 | <annevk> | try to stay positive :-) |
| 11:49 | <annevk> | JakeA_: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#register-algorithm are "Get Registration" and "Get Newest Worker" supposed to run synchronously? |
| 11:50 | <annevk> | JakeA_: is it clear that if 7.2.2.2 returns 7.4/5 are no longer run? |
| 11:53 | <JakeA_> | annevk: hmm, step 7 onwards should be async |
| 11:54 | <annevk> | JakeA_: filed an issue |
| 11:54 | <annevk> | That Google managed to implement something speaks volumes of how closely the specification has been read... |
| 11:55 | <JakeA> | annevk: yeah, 7.2.2.3 should be "abort these steps" |
| 11:55 | <JakeA> | annevk: I'm pretty sure those steps used to be async, I think they've changed |
| 11:56 | <annevk> | JakeA: if you make t hem asynchronous, be sure to return the promise on time... |
| 11:56 | <annevk> | JakeA: and be sure to check the registration stuff in a non-racy way |
| 15:57 | <JakeA> | annevk: right, drag me kicking and screaming into understanding this url issue. I need the URL for assigning a serviceworker registration on navigation. I also need a snapshot of it when we provide request.client, or the BrowsingContent instances from clients.getAll(). I don't understand why the active document changing will break things, or why a url entry |
| 15:57 | <JakeA> | on the environment settings concept wouldn't have exactly the same issues |
| 15:59 | <annevk> | The relationship between Window objects and documents, ignoring corner cases, is 1:1 |
| 15:59 | <annevk> | The relationship between browsing contexts and documents, is 1:N |
| 16:00 | <annevk> | The current document in a browsing context is the active document |
| 16:00 | <annevk> | What a service worker has a relationship with is a Window object/document |
| 16:01 | <annevk> | So what we want to return is a document's url, and not a document's browsing context's active document's url |
| 16:02 | <annevk> | JakeA: ah, and an environment settings object is 1:1:1 with a Window object and document |
| 16:04 | <annevk> | JakeA: and you can't use an environment settings object's responsible document since it would not return a worker's url |
| 16:10 | <JakeA> | annevk: if an environment settings object is 1:1:1 with a Window & document, what's the problem with getting a url from a client's global's location? (considering a request client is an environment settings object) |
| 16:10 | <smaug____> | "ignoring corner cases" |
| 16:10 | <JakeA> | Ahh ok |
| 16:10 | <smaug____> | document.write isn't that faraway in a corner |
| 16:11 | <JakeA> | The url doesn't change in that case though, does it? |
| 16:11 | <smaug____> | document doesn't change with document.write, but Window changes |
| 16:12 | <annevk> | JakeA: a Location object observes document's browsing context's active document's url for various silly legacy reasons that I don't know |
| 16:12 | <smaug____> | (the other corner case is reusing Window object for another Document after the initial about:blank) |
| 16:15 | <JakeA> | smaug____: I thought for a minute you were suggesting the global got reused too. What's the practical impact of window reuse between about:blank and next url? |
| 16:16 | <annevk> | JakeA: that your reference to the object is still valid |
| 16:17 | <smaug____> | JakeA: you do window.open() and can set event listener to the window object even before the document has been loaded |
| 16:17 | <annevk> | JakeA: it means you can synchronously access an <iframe>'s Window from script while it's navigating to the page you actually requested |
| 16:17 | <JakeA> | I seeeeeee |
| 16:17 | <JakeA> | The web's complicated isn't it? |
| 16:17 | <annevk> | about:blank is really complicated |
| 16:18 | <annevk> | the web is okay in comparison :p |
| 16:30 | <JakeA> | annevk: So if the env settings obj concept gets a "document url", which document would that be defined as? |
| 16:31 | <annevk> | JakeA: the URL that caused it to be created, I would imagine |
| 16:32 | <JakeA> | annevk: that means request.client.url wouldn't reflect changes made by pushState… *ponders on if that's a good or bad thing* |
| 16:35 | <annevk> | JakeA: perhaps for document-based environments there should be currentURL as well? |
| 16:37 | <annevk> | JakeA: or perhaps for document-based environments it should return the document's url |
| 16:37 | <annevk> | JakeA: either way, definitely not the active document |
| 16:44 | <JakeA> | annevk: if I got a push message, I wouldn't show a notification if a relevant tab was focused & visible. For this case, pushState matters, I want the "location bar" url. For clients.takeControl(), if we go by post-pushState url, you get a weird edge-case where documents that were originally loaded out-of-scope could become controlled, so creationURL feels |
| 16:44 | <JakeA> | less hacky. Yeah, we need both, and should expose both. |
| 17:05 | <JakeA> | annevk: does this make sense https://www.w3.org/Bugs/Public/show_bug.cgi?id=27146 ? |
| 17:06 | <annevk> | JakeA: sounds good |
| 17:06 | <annevk> | JakeA: I think Mike West also wants these hooks |
| 17:07 | <JakeA> | annevk: cheers & thanks for persevering. If I continue to not get it, feel free to declare me not fit for spec writing :D |
| 17:08 | <Ms2ger> | JakeA, eh, we'll take anybody :) |
| 17:11 | <JakeA> | "Web Better Than Native Spec 1.0" Algorithms: 1. Be better than native. 2. Abort these steps. |
| 17:11 | <jgraham> | JakeA: You're right, that's a terrible spec |
| 17:11 | <jgraham> | Step 2 should be "Goto 1" |
| 17:12 | <JakeA> | Probably should be… ahh beat me to it |
| 17:12 | <JakeA> | Or 2. Be even more better |
| 17:13 | <jgraham> | Well, glad we solved that one |
| 17:13 | <jgraham> | Someone make a press release |
| 17:41 | <Domenic> | JakeA: not sure how you managed to pull this off https://github.com/slightlyoff/ServiceWorker/issues/468#issuecomment-60276779 but kudos |
| 17:41 | <JakeA> | Domenic: there's nothing I won't do to save https://jakearchibald.github.io/trained-to-thrill/ |
| 17:41 | <JakeA> | actually I'll need to change the script location |
| 17:42 | <Domenic> | hahahaha |
| 17:42 | <JakeA> | but that's easy vs getting Github to change headers |
| 17:42 | <Domenic> | yes exactly |
| 17:42 | <Domenic> | i was/am really worried about any solution that prevents creating SW sites on GitHub pages |
| 17:43 | <JakeA> | Yeah, GitHub pages were the sweetener to the https restriction |
| 17:47 | <JakeA> | annevk: so, what's the protocol now, shall I edit the serviceworker spec assuming those url things are on the env settings object? Are there annotation patterns for this stuff? |
| 18:04 | <annevk> | JakeA: seems reasonable |
| 18:05 | <annevk> | JakeA: annotate as monkey patch |
| 18:06 | <JakeA> | Ta |
| 18:35 | <annevk> | So glad Hixie pioneered this space several years ago |
| 18:48 | <JonathanNeal> | Domenic: thanks again for the help with Array.from. |
| 18:50 | <caitp> | array.from is pretty neat |
| 18:53 | <Domenic> | I am not a fan |
| 18:54 | <Domenic> | [...arrayLike] wins for me |
| 18:54 | <caitp> | well it would be more fun to implement |
| 18:55 | <caitp> | but there are things I like about not turning the language into some more ubiquitous version of python |
| 18:55 | <caitp> | python is hard to read |
| 19:05 | <JonathanNeal> | caitp: and we learned about more issues with IE8. Yay for no distinguishment between dense and sparse arrays. |
| 19:06 | <caitp> | you gotta figure sparse arrays are probably not very common for most use cases though |
| 19:08 | <caitp> | its one of the reasons why people often use for loops instead of forEach --- because forEach will care about sparse-ness and skip properties that aren't in the collection, which is significantly more expensive than just invoking the callback with an undefined value |
| 19:11 | <JonathanNeal> | What was the reason it was called .forEach instead of .each? |
| 19:13 | <Hixie> | annevk: which space was i pioneering? :-) |
| 19:13 | <annevk> | Hixie: minting new global objects and defining their infrastructure |
| 19:14 | <Hixie> | oh man |
| 19:14 | <Hixie> | i wouldn't say pioneering |
| 19:14 | <Hixie> | more like i fell into a sewer |
| 19:18 | <annevk> | Now I want to play Mario |
| 20:05 | <Domenic> | annevk: given https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60297625 I at least would take up slightlyoff on the idea of reopening the event listeners issue :). that's the worst part to me. |
| 20:06 | <Domenic> | i think i would prefer fetch not being a special snowflake---the argument there doesn't hold IMO, since having a fetch hook doesn't mean anything about your offline capabilities---but that battle doesn't seem worth fighting |
| 20:08 | <Hixie> | nooo, zcorpan broke the build |
| 20:08 | <Domenic> | there's a guarantee that setTimeout(f, x) and setTimeout(g, x) runs f then g in any order, right? Hixie? |
| 20:08 | <Domenic> | er |
| 20:08 | <Hixie> | zcorpan: <var>image request</span> |
| 20:08 | <Domenic> | in that order |
| 20:08 | <Hixie> | Domenic: i believe so, but i'd have to check the spec to be sure |
| 20:09 | <Domenic> | another benefit of html.spec.whatwg.org subdomain---googling "setTimeout site:html.spec.whatwg.org" |
| 20:09 | <Domenic> | ah yep "Wait until any invocations of this algorithm that had the same method context, that started before this one, and whose timeout is equal to or less than this one's, have completed." |
| 22:26 | <annevk> | Domenic: losing permissions for other things if you decide to enlarge the scope of your app seems pretty bad too |
| 22:34 | <annevk> | Hixie: tweets are still not working? |
| 22:35 | <annevk> | oh well, nn |
| 23:16 | <Domenic> | wow so apparently you used to be able to put default attributes in your DTD and when you did createElement("tagname") with that it would actually create an element with .attributes pre-populated??? |
| 23:21 | <Domenic> | and .specified used to be a thing?? |
| 23:21 | <Domenic> | wow the DOM was effed up |
| 23:21 | <Domenic> | (I'm looking through old dom level 1 tests which jsdom still has in its corpus... we're trying to kill the level1/level2/level3 structure and it's causing a bunch of level1 tests to fail.) |
| 23:42 | <Hixie> | Domenic: "be able to" is maybe the wrong way to put it |