| 01:22 | <MikeSmith> | heycam: http://stackoverflow.com/questions/33215722/how-to-use-w3c-svg-test-suite (if you can provide any help) |
| 06:05 | JakeA | awakens |
| 06:07 | <JakeA> | smaug____: morning! |
| 06:10 | <JakeA> | wanderview: sorry, I missed your follow-up message, yeah, network timeout |
| 07:44 | <zcorpan> | wow i have never reflected that whitelist/blacklist had anything to do with skin color |
| 07:46 | <rniwa> | zcorpan: me neither |
| 07:47 | <rniwa> | zcorpan: what's a proper term we should all be using? |
| 07:47 | <zcorpan> | https://github.com/whatwg/html/issues/265 |
| 07:47 | <zcorpan> | safelist/blocklist |
| 07:48 | <rniwa> | zcorpan: how about blocklist/allowedlist? |
| 07:49 | <rniwa> | zcorpan: nice |
| 07:51 | <zcorpan> | it's not clear to me anyone is actually offended by these terms today, although it is slightly uncomfortable if they indeed originated from skin color |
| 07:52 | <rniwa> | zcorpan: now that I think about it, it's very offensive. |
| 07:52 | <Ms2ger> | Just wait until you next hear someone use master/slave |
| 07:53 | <annevk> | zcorpan: same here, can't believe it never occurred to me before |
| 07:53 | <annevk> | Ms2ger: that too, geez |
| 07:53 | <jochen__> | rniwa: hey |
| 07:53 | <rniwa> | jochen__: hello, what's up? |
| 07:53 | <JakeA> | holy shit, never thought of white/blacklist in that way |
| 07:53 | JakeA | rewires brain |
| 07:53 | <jochen__> | rniwa: who in webkit land would be a good person to talk to about domenic's promise rejection events proposal? |
| 07:54 | <rniwa> | Ms2ger: master/slave is okay because it doesn't discriminate against any race |
| 07:54 | <zcorpan> | yeah |
| 07:54 | <rniwa> | jochen__: probably weinig since he implemented promise in WebKit/JSC |
| 07:54 | <jochen__> | ta |
| 07:55 | <rniwa> | jochen__: probably the best way to get in touch with him will be to file a WebKit bug and cc him |
| 07:55 | <rniwa> | he's a really busy guy these days |
| 07:55 | <jochen__> | who isn't |
| 07:59 | <jochen__> | filed https://bugs.webkit.org/show_bug.cgi?id=150358 |
| 08:02 | <zcorpan> | some people in http://english.stackexchange.com/questions/51088/alternative-term-to-blacklist-and-whitelist claim that the origin isn't skin color |
| 08:04 | <annevk> | zcorpan: I don't think that matters much |
| 08:06 | <annevk> | zcorpan: it's more that the use in this context suggests that black=bad, white=good, which is somewhat pervasive in Western society and not great |
| 08:06 | <zcorpan> | yeah sure |
| 08:08 | <zcorpan> | next up: white hat, black hat |
| 08:12 | <zcorpan> | and white lies |
| 09:05 | <annevk> | Writing ECMAScript stuff is rather fun |
| 09:24 | <Ms2ger> | Anyone have Edge nearby? |
| 09:31 | <gsnedders> | I can. But I don't have a stable internet connection. :) |
| 09:38 | <Ms2ger> | Pah |
| 09:38 | <Ms2ger> | I'm interested in http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3697 |
| 09:41 | <gsnedders> | uh, for some reason can't copy/paste |
| 09:41 | <gsnedders> | log: function CSS() { [native code] }, log: undefined |
| 09:41 | <Ms2ger> | Hrm |
| 09:41 | <Ms2ger> | Thanks |
| 11:27 | <JeanCarloMachado> | /msg NickServ identify wisdom20 |
| 11:27 | <JeanCarloMachado> | d |
| 12:02 | <annevk> | Domenic: given https://github.com/annevk/html-cross-origin-objects/blob/master/Location.md I think it's very feasible to create some kind of generic %CrossOriginObject% thingie that Location and WindowProxy both use |
| 12:02 | <annevk> | Domenic: if we want to list all the [[InternalMethod]] stuff only once |
| 12:02 | <annevk> | Domenic: but maybe that is overkill |
| 12:18 | <Ms2ger> | If anyone feels like being sad, r? https://github.com/w3c/web-platform-tests/pull/2266 |
| 12:19 | <jgraham> | Ms2ger: I am on it |
| 12:19 | <jgraham> | In fact I was already |
| 12:19 | <jgraham> | So obviously I naturally gravitate toward sadness |
| 12:20 | <Ms2ger> | You do live in the UK |
| 12:26 | <jgraham> | Ms2ger: Any special reason you created a new file rather than just running the same tests like ["matches", "webkitMatchesSelector"].each(function() {}) ? |
| 12:27 | <Ms2ger> | jgraham, nothing particularly though out; just felt better this way |
| 12:27 | <Ms2ger> | It might be nice to share some more code, but I didn't really want to spend more time on it |
| 12:29 | <smaug____> | how should openWindow work in SW? |
| 12:29 | <smaug____> | how long should it actually wait before resolving the Promise on worker side |
| 12:30 | <smaug____> | If I read the spec correctly, the promise is resolved ASAP we have a new document |
| 12:30 | <smaug____> | but perhaps I'm missing something |
| 12:31 | <smaug____> | JakeA: annevk: ^ you might know |
| 12:31 | <annevk> | smaug____: yeah, I think once a document is created it'll be resolved |
| 12:32 | <annevk> | fulfilled, I suppose |
| 12:32 | <JakeA> | Agreed |
| 12:32 | <smaug____> | annevk: so the Document might not actually have any content |
| 12:32 | <smaug____> | like scripts loaded or anything |
| 12:32 | <smaug____> | and sw could already try to communicate with it? |
| 12:33 | <annevk> | smaug____: yeah... I think that was roughly the idea |
| 12:33 | <annevk> | smaug____: hasn't really been specified in detail |
| 12:33 | <smaug____> | hmm, rather racy setup |
| 12:33 | <JakeA> | hm, yeah. Although since it opened it, it could put init data in the fragment or search |
| 12:33 | <smaug____> | but perhaps that is fine. perhaps the idea is that the new Window sends something to sw when it thinks it is ready enough |
| 12:34 | <zcorpan> | browsers don't have built-in feed readers anymore, do they? |
| 12:34 | <JakeA> | If it becomes a pain, we could add a client.ready promise or something to that effect |
| 12:34 | <smaug____> | and visibility and focus states can be anything at the moment Promise is resolved |
| 12:37 | <smaug____> | zcorpan: FF has still |
| 12:37 | <smaug____> | if live bookmarks is a "feed reader" |
| 12:39 | <zcorpan> | sure. ok i see "subscribe to this page" in firefox. but clicking it takes me to https://annevankesteren.nl/feeds/weblog which is mostly empty in Nightly and clicking "subscribe now" appears to do nothing |
| 12:40 | <smaug____> | hmm, I do use livebookmarks all the time |
| 12:41 | <smaug____> | but those were created long ago |
| 12:42 | <smaug____> | zcorpan: ah, you're using nightly? |
| 12:42 | <smaug____> | with e10s? |
| 12:42 | <zcorpan> | yeah. i don't know what e10s is but there is a "new non-e10s window" menu item |
| 12:43 | <smaug____> | it is an e10s issue |
| 12:43 | <Ms2ger> | Multiprocess Firefox |
| 12:43 | <zcorpan> | ok |
| 12:46 | <smaug____> | filed https://bugzilla.mozilla.org/show_bug.cgi?id=1216513 |
| 12:55 | <smaug____> | annevk: JakeA: FWIW, I'm rather worried that openWindow setup is too fragile, and ends up causing issues where on slow network something doesn't work, but on fast network, which web devs probably use, things work just fine because data is transferred fast enough so that script etc are loaded before sw's message to client window is processed. |
| 12:56 | <smaug____> | (and better to fix the API sooner than later) |
| 12:57 | <smaug____> | explicit ready() call, or implicit ready at 'load' time might work quite well |
| 12:58 | <smaug____> | (explicit ready() before 'load' would override the implicit ready call) |
| 12:59 | smaug____ | files a bug |
| 13:00 | <smaug____> | ah, there is https://github.com/slightlyoff/ServiceWorker/issues/728 |
| 13:12 | <JakeA> | smaug____: cheers, I've added this to our TPAC agenda |
| 13:12 | <annevk> | smaug____: yeah, it seems better to wait for DOMContentLoaded or some such |
| 13:14 | <JakeA> | I guess having the SW open a bit longer isn't a performance issue here, as the SW will likely be used for the new window's fetch. At the very least the browser needs to be running |
| 13:16 | <annevk> | If anyone is interested in security of Window and Location: https://github.com/annevk/html-cross-origin-objects |
| 13:16 | <annevk> | (Window is not yet covered, waiting on some feedback for Location first.) |
| 13:26 | <smaug____> | Window and Location ... sounds complicated ;) |
| 13:26 | <annevk> | smaug____: quite |
| 16:35 | <Domenic> | annevk: why bound functions? |
| 16:35 | <annevk> | Domenic: that looked close to what I wanted... |
| 16:35 | <Domenic> | what did you want? |
| 16:36 | <annevk> | Domenic: "a wrapper function" is that clear enough? |
| 16:36 | <Domenic> | not sure... what is a wrapper function... |
| 16:36 | <annevk> | Domenic: function() { actualFunction(); } |
| 16:36 | <Domenic> | got it |
| 16:36 | <Domenic> | hmm |
| 16:37 | <annevk> | Oh yeah, WeakMap is wrong |
| 16:37 | <annevk> | Bummer |
| 16:38 | <Domenic> | Separate question: so originalDesc.[[Get]] is a function from another realm, and crossOriginGet is supposed to be instantiated in the current realm? |
| 16:38 | <annevk> | Is there a way to get the key removed if the value is GC'd? |
| 16:38 | <Domenic> | I think everything related to that is correct as-is, but it's quite implicit because of how ES is usually implicit about current realm |
| 16:38 | <annevk> | Or some pattern? |
| 16:38 | <Domenic> | Hmm |
| 16:39 | <annevk> | Domenic: yeah, I forgot about that, crossOriginGet needs to be from the current realm and have the correct Function.prototype thing |
| 16:39 | <Domenic> | I think it does that automatically |
| 16:39 | <annevk> | Domenic: that's why it's wrapping |
| 16:40 | <Domenic> | But adding a NOTE might be helpful since it's implicit |
| 16:40 | <annevk> | I will file an issue for now |
| 16:40 | <Domenic> | And probably replace bound function with something different |
| 16:40 | <Domenic> | bound functions are weird, they don't have a varying `this` |
| 16:41 | <Domenic> | so you want a tuple -> list map where if the list gets deleted the items in the tuple are not held by GC |
| 16:41 | <Domenic> | ? |
| 16:41 | <Domenic> | no, not the list gets deleted |
| 16:41 | <Domenic> | if all the items in the list get GCed |
| 16:46 | <annevk> | Domenic: it's a tuple -> Property Descriptor Record map |
| 16:46 | <annevk> | Domenic: and if everything in the Property Descriptor Record map is no longer used, the whole map entry can be GC'd |
| 16:46 | <Domenic> | The map is keys -> propdescs? makes sense |
| 16:47 | <annevk> | Domenic: yeah, since that is what GetOwnProperty returns that seemed easiest |
| 16:47 | <Domenic> | Wait, is it a map or is it just a single propdesc |
| 16:47 | <Domenic> | [[GetOwnProperty]] seems to imply just a single propdesc |
| 16:48 | <annevk> | The internal structure is a map of tuple -> propdesc |
| 16:48 | <Domenic> | i think i understand |
| 16:48 | <annevk> | [[GetOwnProperty]] returns one propdesc out of that map at most |
| 16:48 | <Domenic> | what is in the tuple? anything object-like we can use? |
| 16:48 | <annevk> | no |
| 16:49 | <Domenic> | then i don't think we should worry about GCing the keys |
| 16:49 | <Domenic> | if they are just primitives then there is no notion of them being allocated or not |
| 16:49 | <annevk> | origin + effective script origin or maybe just effective script origin |
| 16:50 | <Domenic> | cool |
| 16:50 | <Domenic> | but we ... still don't want to hold strong references to the propdescs? |
| 16:50 | <Domenic> | (and more specifically to the functions) |
| 16:50 | <annevk> | yeah |
| 16:50 | <Domenic> | hmm, but that seems like it would expose GC: |
| 16:51 | <Domenic> | I do const x = Object.getOwnPropertyDescriptor(location, "href").get; |
| 16:51 | <annevk> | e.g. if I do document.domain = "x.x.x.com" and then later do document.domain = "x.x.com" it makes little sense for the Location object to keep functions alive I can never possibly access again |
| 16:51 | <Domenic> | I see |
| 16:51 | <annevk> | sure, if you have a ref to them, they shouldn't be collected |
| 16:52 | <annevk> | this is mostly about them getting stored once you access them and then there not being a way for them to get removed again |
| 16:52 | <annevk> | other than GC, which I thought WeakMap would address but really doesn't |
| 16:52 | <Domenic> | I'm tempted to go with something a bit handwavy about GC behavior instead of saying that we have found the perfect data structure |
| 16:52 | <Domenic> | Something like: |
| 16:54 | <annevk> | I do see now why I was totally wrong about WeakMap |
| 16:54 | <Domenic> | "The UA should allow the property descriptors their accessor functions stored in [[crossOriginPropertyDescriptorMap]] to be garbage collected if no references to them exist and it is not possible for them to be accessed." Then give 2+ examples, one where the author did window.x = Object.getOwnPropertyDescriptor(location, "href").get so it must stay alive, |
| 16:54 | <Domenic> | and one where they did document.domain so now it can be collected. |
| 16:55 | <annevk> | Seems reasonable |
| 17:01 | <annevk> | Domenic: so for Window, my thinking is that once Location.md is better I try to duplicate the text I have there first and create a WindowProxy.md based off it |
| 17:01 | <annevk> | Domenic: then we review that |
| 17:02 | <annevk> | Domenic: then we can attempt a potential %AllenWirfsBrockObjectMagicHappens% merger? |
| 17:03 | <annevk> | Domenic: and even if we decide not to merge the objects (mostly to avoid duplicate [[PreventExtensions]] ( ) and friends), things like CrossOriginPropertyDescriptor will be reused of course |
| 17:05 | <annevk> | that's all I got for today, more tomorrow, I'm sure |
| 17:23 | <Domenic> | annevk: yeah that sounds like a good plan. |
| 17:50 | <Joseph__Silber> | TabAtkins, is it possible to use `justify-content: center` for a multi-line flexbox, and have the last line left aligned to the edge of the previous line?? |
| 17:51 | <TabAtkins> | Joseph__Silber: Nope. Handling the "last line problem" will happen in Flexbox 2. |
| 17:51 | <Joseph__Silber> | K. Thanks. |
| 17:51 | <Joseph__Silber> | Guess the only way to solve it now is with another wrapper. |