| 01:06 | <cvrebert> | MikeSmith: Any update on the CSS Validator repo migration? |
| 01:30 | <tripu> | ato? |
| 01:38 | <ato> | tripu: Hi. |
| 01:47 | <MikeSmith> | cvrebert: probably will get to it today |
| 01:47 | <cvrebert> | MikeSmith: \o/ |
| 05:10 | <annevk> | "You’ve been removed from the Web Platform Testing and Tools Pushers team on the World Wide Web Consortium organization." I wonder what I did |
| 05:17 | <MikeSmith> | annevk: nothingーyou still have push perms |
| 05:17 | <MikeSmith> | that team was redundant |
| 05:23 | <Domenic> | annevk: is there a way to invoke the basic URL parser without a base URL in browsers, except indirectly? I tried setting <base href="url-to-parse"> and then investing <a href="#">.href, but it parsed url-to-parse relative to the page's "real" URL. |
| 05:23 | <Domenic> | I know you can do it with new URL("url-to-parse") but I was wondering if there were another context I could try, especially one that isn't allowed to fail. |
| 05:24 | <annevk> | Domenic: set <base> to about:blank |
| 05:24 | <annevk> | Domenic: roughly equivalent |
| 05:24 | <annevk> | Domenic: not sure it works reliably in IE/Edge though |
| 05:24 | <Domenic> | doesn't seem to work in Chrome... |
| 05:24 | <annevk> | oh |
| 05:25 | <annevk> | Domenic: test:test seems to work in Chrome... |
| 05:25 | <Domenic> | oh nice! |
| 05:26 | <Domenic> | https://jsbin.com/someje/edit?html,console,output is fun |
| 05:27 | <Domenic> | "" in Chrome, "/\\example.jpg" in Firefox, "https://null.jsbin.com///example.jpg"; in IE11 |
| 05:28 | <Domenic> | It's as if all this code was written without a well-specified standard |
| 05:29 | <Domenic> | Or worse, off of RFCs |
| 05:29 | <annevk> | Firefox' output is correct, if you hit a fatal parse error you just return the input |
| 05:29 | <annevk> | (it's fatal since there's no base URL) |
| 05:31 | <annevk> | Domenic: how does it match Chrome? |
| 05:33 | <Domenic> | Chrome matches when parsed with base URL |
| 05:33 | <Domenic> | Firefox matches without one |
| 05:33 | <annevk> | Oh right, Firefox doesn't handle backslashes correctly yet |
| 05:34 | <annevk> | There's an open bug on that |
| 05:36 | <annevk> | Domenic: for https://github.com/whatwg/loader/issues/62 I think ideally we end up with something similar to custom elements |
| 05:36 | <annevk> | Domenic: although I guess it's not quite lifecycle methods, but it's somewhat close |
| 05:37 | <Domenic> | Ah yeah interesting parallel |
| 05:37 | <Domenic> | That argues for symbols at least |
| 06:46 | <annevk> | MikeSmith: https://blogs.oracle.com/maryanndavidson/entry/no_you_really_can_t seems like something you'd enjoy reading |
| 06:46 | MikeSmith | looks |
| 06:54 | <MikeSmith> | annevk: needs more photos |
| 06:54 | <MikeSmith> | but "Bug bounties are the new boy band" is good |
| 06:57 | <MikeSmith> | there should be a reverse bug-bounty thing, where if you try to get attention by claiming some product/spec has a security vulnerability and it turns out to not really be true, you have to give money to a community fund that then gets paid out to people who find real security vulnerabilities |
| 06:58 | <annevk> | <<Otherwise everyone would hire a consultant to say (legal terms follow) “Nanny, nanny boo boo, big bad consultant can do X even if the customer can’t!”>> |
| 06:59 | <annevk> | The entire premise though of security by obscurity seems so wrong... I'm somewhat baffled this person is the CTO. |
| 07:04 | <MikeSmith> | annevk: actually, Chief Security Officer, right? |
| 07:06 | <MikeSmith> | and speaking of security by obscurity I notice that Oracle's state-of-the-art blogging tool identifies her as "User701213-Oracle" in the byline |
| 07:06 | <MikeSmith> | that inspires a lot of confidence |
| 07:07 | <MikeSmith> | especially since the gist of the piece is basically "Trust us, we know what we're doing." |
| 08:16 | <annevk> | abc.wtf is kinda funny |
| 08:33 | <Ms2ger> | So what's this Alphabet thing? |
| 08:40 | <annevk> | Ms2ger: most plausible explanation I saw was that it's a trick to pay less tax, but I don't understand US tax law so I don't really know if that's the real reason |
| 09:33 | <JakeA> | annevk: when a listener callback is executed (https://dom.spec.whatwg.org/#dispatching-events), is that calling a callback as per https://html.spec.whatwg.org/#clean-up-after-running-a-callback ? |
| 09:33 | <annevk> | JakeA: this is the dust thing I mentioned |
| 09:34 | <JakeA> | ahh ok |
| 09:34 | <annevk> | JakeA: see the bugs blocking https://www.w3.org/Bugs/Public/show_bug.cgi?id=17713 |
| 09:34 | <JakeA> | Chrome's implementation performs a microtask checkpoint per listener, Firefox doesn't |
| 09:34 | <annevk> | JakeA: the idea though, is yes |
| 09:35 | <annevk> | JakeA: Firefox does too, just not for promises |
| 09:36 | <JakeA> | Ahh I see. I'll test this with mutation observers |
| 09:37 | <annevk> | JakeA: are you using FirefoxNightly btw? |
| 09:37 | <JakeA> | annevk: no, will test that now |
| 09:40 | <JakeA> | annevk: yeah, still wrong in Nightly |
| 09:40 | <annevk> | Hmm, I cannot find the bug in Nightly |
| 09:40 | <JakeA> | annevk: http://jsbin.com/zetoya/edit?console,output |
| 09:41 | <JakeA> | click the blue square |
| 09:42 | <annevk> | I see |
| 10:02 | <Ms2ger> | Was display: -webkit-flexbox a thing? |
| 10:09 | <annevk> | Ms2ger: some search results suggest display: -webkit-flex is |
| 11:20 | <Ms2ger> | MikeSmith, https://blog.mozilla.org/community/2015/08/10/firefox-40-new-contributors/ |
| 11:23 | <MikeSmith> | Ms2ger: w00t |
| 11:23 | <MikeSmith> | I wonder when do I start getting the royalty checks |
| 11:28 | <Ms2ger> | MikeSmith, can you add csswg-test to the testing teams on github? |
| 11:29 | <MikeSmith> | Ms2ger: which teams exactly? |
| 11:29 | <Ms2ger> | Web Platform Testing / Web Platform Testing and Tools Owners |
| 11:31 | <MikeSmith> | ok |
| 11:31 | <MikeSmith> | done I think |
| 11:32 | <Ms2ger> | Yep, thanks |
| 12:09 | <annevk> | JakeA: https://html5.org/temp/fetch-newcontext.html |
| 12:15 | <JakeA> | annevk: looks good. Why does imgset get an initiator? |
| 12:16 | <JakeA> | annevk: I can see why xslt-styles are their own thing, given the CSP rule, but why an initiator rather than type? |
| 12:17 | <annevk> | JakeA: you'd want type = "xslt"? |
| 12:17 | <annevk> | JakeA: I opted for initiator since I expected "xslt" to maybe be removed at some point and initiator is not exposed |
| 12:17 | <annevk> | JakeA: I guess it doesn't matter much either way... |
| 12:18 | <JakeA> | that's a good enough reason |
| 12:18 | <annevk> | JakeA: "imageset" is needed for Mixed Content |
| 12:18 | <annevk> | and again, since initiator is not exposed... |
| 12:18 | <JakeA> | ahh good point |
| 12:18 | <JakeA> | annevk: I take it audio/video/track have different enough requests to warrant their own type? |
| 12:18 | <JakeA> | rather than just media |
| 12:19 | <annevk> | JakeA: I would expect them to have their own Accept header |
| 12:19 | <annevk> | JakeA: which is one of the things we use context for today |
| 12:19 | <annevk> | JakeA: we also use context to enforce X-Content-Type-Options: nosniff for which we'd also need these distinguished |
| 12:21 | <JakeA> | annevk: would fetch's type become settable? |
| 12:22 | <annevk> | JakeA: I don't see how we could do that and use it as a security mechanism at the same time, unless we restrict how the response is used |
| 12:24 | <JakeA> | Yeah, that follows. I guess there could be Request.asType('image', url, opts), but it only affects headers, not underlying type (or sets some kind of "imitating type") |
| 12:26 | <JakeA> | annevk: this looks really good. Nice one. |
| 12:26 | <annevk> | JakeA: yeah, I think for igrigorik's use cases we'd include an additional axis of sorts |
| 12:27 | <annevk> | JakeA: "as type" or "pretend type" or some such, that's simply not used for security |
| 12:27 | <JakeA> | Makes sense |
| 12:28 | <JakeA> | For <link rel="prefetch"> etc, setting actual type should be fine, as only the correct type will get a cache match on that |
| 12:29 | <JakeA> | But fetch(request) should always be connect-src |
| 12:42 | <annevk> | JakeA: does Chrome always use a browsing context for <object>? |
| 12:42 | <annevk> | JakeA: afaict Chrome does something different from Firefox |
| 12:44 | <JakeA> | annevk: I don't know off the top of my head, I'll find someone to bug about that when SF wakes up. I'm not sure how I'd test that |
| 12:44 | <JakeA> | annevk: When I click something on the page, how is the dispatch of the event queued? Is it a task? |
| 12:45 | <JakeA> | actually, thought of a way to test the object thing |
| 12:45 | <annevk> | JakeA: I've been playing with http://software.hixie.ch/utilities/js/live-dom-viewer/ and <object data=document> vs <object data=image> |
| 12:45 | <annevk> | JakeA: for the latter contentDocument is null in Firefox, but in Chrome you still get a document |
| 12:46 | <annevk> | JakeA: In Firefox you only get a contentDocument if you do <a target=x href=image>...</a> against <object data=document name=x> |
| 12:47 | <JakeA> | annevk: http://jsbin.com/jeruku/edit?console,output - no contentDocument on this |
| 12:47 | <JakeA> | click events don't get trapped either |
| 12:49 | <annevk> | whoa how is that different |
| 12:50 | <annevk> | Does it depend on whether or not you document.write() the <object> in Chrome? |
| 12:51 | <JakeA> | annevk: updated the bin. Looks the same |
| 12:52 | <annevk> | If I start typing in that bin it really shouldn't try to sync your stuff from upstream |
| 12:52 | <annevk> | That's super annoying |
| 12:53 | <JakeA> | heh, I've stopped typing |
| 12:54 | <annevk> | JakeA: see http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3589 |
| 12:54 | <annevk> | JakeA: and the difference in Chrome and Firefox |
| 12:57 | <JakeA> | That is bizarre |
| 12:57 | <annevk> | I know, I was thinking we could require Chrome's behavior and always have a browsing context, but you've shown that Chrome doesn't always do that |
| 12:57 | <annevk> | And now I'm confused |
| 12:58 | <JakeA> | annevk: typemustmatch would do the trick though, right? |
| 12:59 | <annevk> | JakeA: provided we defined the behavior and removed those <object> elements from being able to be targeted with <a target>... |
| 13:00 | <JakeA> | annevk: can an object with typemustmatch and a non-document type still be navigated via <a target>? |
| 13:00 | <annevk> | JakeA: I'm not sure |
| 13:00 | <JakeA> | That might be ok, because we still know before the response if it'll be a document or not |
| 13:03 | <annevk> | Yeah, although I wonder if <object> will show its fallback content in case of a network error and whether it'll have a browsing context in that case... |
| 13:04 | <annevk> | But I guess that's fine, it's equivalent to a hidden <iframe>, only the ones no longer part of the tree are bad |
| 13:05 | <JakeA> | Hah, I don't think I understand the processing model of object fallbacks, they don't seem to appear in the DOM |
| 13:06 | <annevk> | That sounds like a bug |
| 13:11 | <JakeA> | It's certainly not what I expected |
| 13:12 | <gsnedders> | they definitely should be in the DOM! |
| 13:14 | <JakeA> | Ah, I think they are, but devtool's representation is broken |
| 13:14 | <JakeA> | http://output.jsbin.com/ganehi/quiet |
| 13:30 | <JakeA> | annevk: is it explained anywhere that jobs and microtasks share the same queue? |
| 13:32 | <annevk> | JakeA: not yet |
| 13:32 | <annevk> | JakeA: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981 |
| 13:33 | <annevk> | I wonder if we can work with bterlson on a better model |
| 13:34 | <annevk> | Since awbjs wasn't too helpful |
| 13:39 | <JakeA> | Thanks for the link, exactly what I was looking for. https://esdiscuss.org/topic/the-initialization-steps-for-web-browsers#content-18 appears to be the closest to confirmation |
| 13:40 | <JakeA> | And yeah, awbjs wasn't being too helpful in that thread |
| 14:40 | <annevk> | JakeA: I think https://bugzilla.mozilla.org/show_bug.cgi?id=874571 and https://bugzilla.mozilla.org/show_bug.cgi?id=1169307 are the Firefox issues btw |
| 14:41 | <JakeA> | annevk: cheers! I might get you to proofread this tomorrow if you have time |
| 14:42 | <wanderview> | annevk: so does our broken microtask implementation block something significant? looking for a way to prioritize it to get someone to work it |
| 14:43 | <JakeA> | wanderview: you can't promisify indexedDB https://github.com/w3c/IndexedDB/issues/27 |
| 14:44 | <JakeA> | wanderview: I wrote a promisified version of IDB, but it only works in Chrome due to the microtask thing https://github.com/jakearchibald/indexeddb-promised/blob/master/test/idb.js#L18 |
| 14:46 | <wanderview> | JakeA: you mean you can't write a polyfill that works? |
| 14:46 | <JakeA> | wanderview: yep, there's no way to get a value & write a value within the same transaction, as promise callbacks happen too late |
| 14:47 | <JakeA> | same goes for iterating over cursors |
| 14:48 | <wanderview> | hmm, I see... I'm not sure that's enough to raise the priority unfortunately... I guess we can ask bz when he returns from holiday |
| 14:51 | <wanderview> | annevk: maybe we should write a bug about this specific problem... since not sure anyone will see it buried in the comments on the other bug |
| 15:02 | <annevk> | JakeA: are you writing a patch for HTML? |
| 15:02 | <annevk> | wanderview: we could I guess |
| 15:02 | <JakeA> | annevk: for what? |
| 15:03 | <annevk> | JakeA: you were asking for proofreading |
| 15:04 | <JakeA> | annevk: ohh sorry, no, I'm writing an article on tasks microtasks & jobs. You mentioned the bugs right after I saw https://twitter.com/briankardell/status/631095683559387136 so thought you'd seen it |
| 15:05 | <annevk> | JakeA: ah, I only saw your original tweet |
| 16:21 | <Domenic> | JakeA: yay, thus proving my strategy of never actually writing anything in my blog post backlog, since other people will do so eventually anyway |
| 16:21 | <Domenic> | JakeA: can you emphasize how jobs are a stupid non-real-world abstraction that just make things complicated by pretending they're relevant. they make me angry. |
| 16:21 | <annevk> | wanderview: JakeA: I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1193394 specifically on the topic of promises and microtasks |
| 16:22 | <annevk> | Domenic: when can we fix awbjs mistakes? es-discuss does not make me hopeful |
| 16:22 | <Domenic> | give brian some time to settle in, and we'll see. |
| 16:24 | <JakeA> | Domenic: haha, so what should ECMAScript have done instead? Offered an API to the queue so microtasks could just use that? |
| 16:24 | <Domenic> | JakeA: just actually worked with the real-world concept of microtasks, IMO. |
| 16:25 | <wanderview> | JakeA: there seems to be an excellent opportunity for a "Domenic is angry" picture here |
| 16:25 | <Domenic> | Pretending there is this abstract separation of "abstract job which could in theory be anything" is silly when all engines intend to implement in the exact same way. |
| 16:25 | <wanderview> | from your last blog post we know you are a wiz with photoshop... |
| 16:25 | <Domenic> | oh dear |
| 16:25 | <JakeA> | haha |
| 16:25 | <Domenic> | I still never found out why I was on a slide at jqConf |
| 16:28 | <annevk> | JakeA: I think the best would have been for ECMAScript to just do HostEnqueue(potential metadata, the task) and have some requirements around ordering for hosts |
| 16:29 | <JakeA> | annevk: that would have covered the microtask listener behaviour automatically, since the stack would be empty between listener calls, so it'd do the right thing |
| 16:30 | <Domenic> | annevk: wait, that's basically what ES does. |
| 16:31 | <annevk> | Domenic: see the HTML ES6 integration bug for how much harder ES makes it |
| 16:31 | <annevk> | (referenced above somewhere) |
| 16:31 | <Domenic> | Ah right it tried to take over initialization somehow |
| 17:01 | <Domenic> | TabAtkins: ping https://github.com/tabatkins/bikeshed/issues/438#issuecomment-129662299 |
| 17:13 | <TabAtkins> | Domenic: It strikes me that I might not have the id generation correct for dfn-headings. I think the heading will generate an id first and then won't generate one as a dfn. |
| 17:13 | <Domenic> | TabAtkins: I've heard of a technique called unit tests that might help in this kind of situation ;) |
| 17:14 | <TabAtkins> | I've heard of those, but I dont' think they're real. |
| 19:06 | <Domenic> | bterlson: would you say Edge has "no public signals" for Array.prototype.includes, or "public support" |
| 20:07 | <bterlson> | Domenic: I think the latter as I don't recall talking about it |
| 20:08 | <Domenic> | bterlson: as in, no objections, so your default position for TC39-supported things is public support? |
| 20:08 | <bterlson> | err, I meant former not latter |
| 20:08 | <Domenic> | ah right ok |
| 20:08 | <bterlson> | there have been no public signals |
| 20:08 | <bterlson> | BUT |
| 20:08 | <bterlson> | can I make one now? ;) |
| 20:08 | <Domenic> | yep! |
| 20:08 | <bterlson> | do you need to link to something |
| 20:08 | <bterlson> | ? |
| 20:08 | <Domenic> | chat logs should be fine :) |
| 20:09 | <bterlson> | how is public support defined anyway? |
| 20:09 | <bterlson> | saying "yeah we'll implement that" is sufficient? |
| 20:09 | <Domenic> | yeah pretty much |
| 20:10 | <bterlson> | because assuming Array.prototype.includes works on the web we will def implement it :-P |
| 20:10 | <Domenic> | as distinct from "that's a bad idea" or "we have no comment at this time and will leave you in suspense" |
| 20:10 | <bterlson> | no evidence yet to suggest it's a bad idea |
| 20:10 | <bterlson> | :-P |
| 20:10 | <Domenic> | i'll take it! :) |
| 20:10 | <bterlson> | haha |
| 20:10 | <bterlson> | nice |
| 20:11 | <Domenic> | sigh the logs for this channel are over HTTP, so sad so sad. |
| 20:22 | <Ms2ger> | Domenic, I'm sure krijnhoetmer would be happy for you to pay for https ;) |
| 20:23 | <Domenic> | Ms2ger: I'm happy to walk him through how to create a free cloudflare account. |
![https://null.jsbin.com///example.jpg"](https://null.jsbin.com///example.jpg"){kind=link}