| 00:21 | <jgraham> | MikeSmith: An alternative explaination is that the whole of twitter is actually parody accounts run by hober |
| 00:22 | <MikeSmith> | jgraham: lol |
| 00:22 | <MikeSmith> | that's actually starting to seem plausible |
| 00:41 | <jsbell> | Just noticed the whatwg logo for XHR. Nice. |
| 00:59 | <MikeSmith> | jsbell: from the mind of annevk and maybe he's the only one for whom that connection would have come to mind |
| 00:59 | MikeSmith | tries to imagine what the XHR logo would be if a different editor had chosen one |
| 01:00 | <MikeSmith> | too bad XHR is gonna be deprecated |
| 01:00 | <MikeSmith> | the Fetch logo is seriously lacking right now |
| 01:01 | <MikeSmith> | annevk: I think some variation on https://openclipart.org/detail/210732/Dog%20Bone would be a good logo for Fetch |
| 01:02 | <MikeSmith> | not a variation on that particular image but on the idea |
| 01:03 | <MikeSmith> | annevk: http://www.alettertomydog.com/wp-content/uploads/dog-bone.jpg |
| 01:03 | <MikeSmith> | http://www.newrepublic.com/sites/default/files/migrated/dog%20bone%209.3.JPG |
| 01:04 | <jsbell> | MikeSmith: Maybe a sideways u-turn? |
| 01:04 | <jsbell> | ... which appears to be one of the few arrows not in Unicode... |
| 01:41 | <sicking> | Domenic: i'm bummed that Promise.then can be called multiple times. It would have been so easy to add the most important forms of cancellability otherwise. |
| 02:14 | <MikeSmith> | botie: inform jsbell ↩ |
| 02:14 | <botie> | will do |
| 02:21 | <tantek> | MikeSmith - looks like "reply" |
| 02:26 | <MikeSmith> | tantek: yeah |
| 02:28 | <MikeSmith> | I don't really know why Josh suggested "sideways u-turn" |
| 02:29 | <MikeSmith> | but I do know I like my bone |
| 02:45 | <MikeSmith> | hey annevk when you're back please ping me so I can tell you something I been meaning to tell you |
| 03:18 | <tantek> | MikeSmith: 🐶 |
| 03:29 | <MikeSmith> | tantek: yeah that'd work |
| 07:16 | <annevk> | MikeSmith: about new logos for Fetch? :-) |
| 07:55 | <MikeSmith> | no |
| 07:55 | <MikeSmith> | well that too |
| 07:56 | <MikeSmith> | annevk: a simple bone image would be kinda fun |
| 08:18 | <annevk> | So https://html5.org/r/8886 is another data point for why custom elements would want some kind of end tag notification |
| 09:43 | <annevk> | rniwa: Firefox Nightly works fine here |
| 09:43 | <annevk> | rniwa: are you running another Firefox at the same time? That might be the problem |
| 09:43 | <rniwa> | annevk: I quit it but it doesn't launch :( |
| 09:44 | <annevk> | weird |
| 09:44 | <rniwa> | annevk: it keeps bouncing on the dock... |
| 09:44 | <annevk> | I've been using Nightly mostly reliably for over two years now |
| 09:45 | <annevk> | Yesterday I booted my other copy of Firefox to test something and it was Firefox 22 (beta channel)... |
| 09:50 | <rniwa> | annevk: LOL. that's some old Firefox |
| 09:50 | <rniwa> | annevk: on a completely unrelated note, I have a pretty decent implementation of classes in WebKit locally. |
| 09:51 | <Ms2ger> | Classes? |
| 09:51 | <rniwa> | I do need to split it into pieces and land them but it's getting there. |
| 09:51 | <rniwa> | Ms2ger: ES6 |
| 09:51 | <Ms2ger> | Ah |
| 09:52 | <annevk> | rniwa: cool |
| 09:52 | <karlcow> | HTML Stress test circa 1992 - http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/errors.html |
| 09:52 | <annevk> | rniwa: it seems Firefox' implementation is not entirely complete yet |
| 09:52 | <annevk> | rniwa: e.g. no default constructor |
| 09:52 | <rniwa> | default constructor is not that trivial due to its dependence on spread |
| 09:53 | <rniwa> | thankfully, oliver has implemented that one in JSC |
| 09:53 | <Ms2ger> | It's only constructor() and statics that are supported in SM, IIRC |
| 09:53 | <rniwa> | so I just need to miranda-function it |
| 09:53 | <Ms2ger> | And we have spread, I think |
| 09:53 | <rniwa> | Ms2ger: oh nice |
| 09:54 | <rniwa> | Ms2ger: and you guys support let/const so TDZ must be supported as well |
| 09:54 | <rniwa> | the biggest missing piece for us is TDZ at the moment. |
| 09:54 | <Ms2ger> | ...maybe :) |
| 09:54 | <rniwa> | and it took us a while to figure out the best way to implement it |
| 09:54 | <annevk> | Is let finally fixed? |
| 09:54 | <annevk> | I thought we had an old version of it |
| 09:54 | <rniwa> | annevk: oh.. |
| 09:54 | <Ms2ger> | We've had let/const long before the TDZ existed |
| 09:55 | <rniwa> | annevk, Ms2ger: so you guys might still need to implement TDZ |
| 09:55 | <Ms2ger> | It might be fixed by now, but I wouldn't put money on it yet :) |
| 09:55 | <rniwa> | I don't like TDZ though... |
| 09:55 | <rniwa> | it's like an extra runtime cost for nothing :( |
| 09:56 | <Ms2ger> | No comment :) |
| 09:59 | <rniwa> | anyway, now I can finally get back to custom elements. |
| 09:59 | <rniwa> | there are still some interesting questions. |
| 10:01 | <Ms2ger> | Like "Should we really implement this?"? |
| 10:02 | <rniwa> | Ms2ger: that's always an important question... |
| 10:02 | <rniwa> | Ms2ger: for implementing any feature. |
| 10:02 | <MikeSmith> | annevk: I prefer my HTML documents formatted as TeX |
| 10:03 | <rniwa> | Ms2ger: I was explaining how shadow DOM works to someone today and convinced myself that it's too damn complicated as is. |
| 10:03 | <rniwa> | Ms2ger: like... I couldn't even draw all possible scenarios on whiteboard after 15 minutes. |
| 10:03 | <rniwa> | even though the whiteboard looked like a complete gibberish at that point. |
| 10:04 | <MikeSmith> | rniwa: you should just build your Nightly from sources |
| 10:04 | <MikeSmith> | I reckon you got a good machine to build on |
| 10:04 | <Ms2ger> | Eh, not like Google is going to ship it anytime soon, amirite |
| 10:06 | <rniwa> | Ms2ger: yeah, and it's gonna be prefixed for a long time even if it did ship. |
| 10:06 | <rniwa> | it's not like we've come to consensus in the relevant working groups. |
| 10:07 | <annevk> | rniwa: can you make it April 24? |
| 10:07 | <rniwa> | annevk: yes! |
| 10:07 | <annevk> | great |
| 10:08 | <rniwa> | annevk: unless the U.S. government decides to not let me in after going back to Japan LOL |
| 10:08 | <annevk> | Travis' comment contrasting components with <iframe> was somewhat interesting |
| 10:08 | <annevk> | heh |
| 10:08 | <annevk> | although not really new |
| 10:08 | <annevk> | I'm still mulling over https://speakerdeck.com/vjeux/react-css-in-js a bit |
| 10:08 | <rniwa> | annevk: where did he post that? |
| 10:09 | <annevk> | rniwa: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27401#c5 |
| 10:09 | <jgraham> | MikeSmith: Not sure why you would build nightly from source, really, unless you want a debug build. Or like having a source tree to run tests |
| 10:10 | <annevk> | rniwa: it gives the idea that Apple + Mozilla + Microsoft agree that isolation is important |
| 10:10 | <annevk> | rniwa: coupled with that being a big complaint about CSS, there might be something there |
| 10:11 | <annevk> | though nobody has really turned this into anything concrete yet unfortunately |
| 10:12 | <jgraham> | annevk: Did you manage to get any detailed feedback out of the gaia people |
| 10:12 | <jgraham> | ? |
| 10:12 | <rniwa> | annevk: thanks |
| 10:13 | <annevk> | jgraham: some from Wilson (if you see him, wish him a happy b-day) |
| 10:13 | <rniwa> | annevk: yeah, someone at Microsoft mentioned to me that they're worried about versioning of web components |
| 10:13 | <rniwa> | annevk: and I fully agree with that concern |
| 10:13 | <annevk> | jgraham: also in the direction of wanting to build isolated components similar to e.g. <input> |
| 10:13 | <rniwa> | annevk: as things stand, it's a dependency nightmare for component authors |
| 10:14 | <jgraham> | annevk: OK, great. It was Wilson I was talking to, and it sounded like they were planning to move back to a more <iframe>-like model for some things |
| 10:14 | <annevk> | rniwa: versioning? That releasing updated components potentially requires global changes? |
| 10:15 | <rniwa> | annevk: like... when you release a new version of component, you need to worry about someone depending on your shadow DOM structures |
| 10:16 | <annevk> | rniwa: yeah okay, that's how I understood it, makes sense |
| 10:16 | <annevk> | rniwa: yeah, you can't really pull a mobile like Safari (and Opera before, hah) did with <input> |
| 10:17 | <rniwa> | annevk: yeah, not at all. |
| 10:17 | <rniwa> | annevk: for something like that to work |
| 10:17 | <rniwa> | annevk: we can't have any JS-visible API changes made by "components" |
| 10:17 | <rniwa> | annevk: we need to use something more like CSS-based decorators |
| 10:17 | <rniwa> | that UAs can just hoist at its will. |
| 10:20 | <annevk> | Decorators make event-based stuff harder though I reckon |
| 10:20 | <annevk> | But it does kind of make sense that public API you'd do through a custom element and styling through something decorator-like. But there's some intersection with focus/input... |
| 10:21 | <rniwa> | yeah, it's tricky :/ |
| 10:23 | <MikeSmith> | jgraham: if you run a version with your own patches for changing things but you also want to get the latest upstream changes |
| 10:28 | <jgraham> | Well yes, of course, but that's a pretty odd use case :) |
| 10:33 | <MikeSmith> | jgraham: it's even odder when some of your code does stuff that strings emitted by the chrome with hardcoded strings like "baddasss" |
| 10:33 | <MikeSmith> | I mean hypothetically speaking that would be pretty odd |
| 11:05 | <Flump5281> | Hi guys, is there anyone around who can create wiki accounts for wiki.whatwg.org? |
| 11:20 | <zcorpan> | would it make sense for Servo to try to identify as webkit instead of as gecko? (i guess there are bigger problems at this point, but long-term) |
| 11:23 | <Ms2ger> | We identify as mosaic |
| 11:30 | <annevk> | Flump5281: send me a pm with username / email |
| 11:30 | <annevk> | Flump5281: might take a while because I'm about to take a break |
| 11:31 | <Flump5281> | annevk: PM sent :) |
| 14:14 | hemanth | : nmotw -> http://nmotw.in/dompurify/ Super-fast, uber-tolerant XSS sanitizer for #HTML, MathML and SVG! |
| 15:58 | <zcorpan> | i wonder if browsers are named to conflict with other browser vendors' terminology just to annoy the other browser vendors. (chrome, spartan) |
| 17:39 | <jamesr___> | having that as a goal would make naming things easier |
| 17:40 | <annevk> | Domenic: I think SharedArrayBuffer is by design not on the main thread, would be bad to lock it |
| 17:40 | <annevk> | Domenic: and not sure what primitive I was thinking of, something that does what you want :-) |
| 17:40 | <annevk> | jamesr___++ |
| 17:41 | <caitp> | which browser terminology does spartan conflict with? |
| 17:42 | <gsnedders> | Most of the jokes I've seen have been the fact that Opera's old testing infra was called SPARTAN |
| 17:42 | <gsnedders> | an acronym for… something, nobody really knows. |
| 17:43 | <annevk> | Hixie should know, he made it up |
| 17:44 | <gsnedders> | I thought that was only ART |
| 17:45 | <caitp> | writing quality maintainable code is absolutely forbidden |
| 17:49 | <jgraham> | I think SPARTAN was an acronym for at least two things, although iirc the reasonable-sounding one was coined later |
| 17:49 | <jgraham> | I think the original one started Solar Powered… |
| 17:51 | <jgraham> | (although I'm not sure that wasn't the more reasonable one) |
| 17:52 | <Domenic> | annevk: I think there's nothing in the SAB design that is inherently worker-specific. If it doesn't work on the main thread people will just have to create async shim APIs to let the main thread manipulate it. |
| 18:42 | <botie> | jsbell, at 2015-03-05 02:14 UTC, MikeSmith said: ↩ |
| 18:43 | <jsbell> | Yeah, but not "go get something, then come back" enough |
| 19:42 | <sicking> | Domenic: the worker-specific thing is that the API allows for blocking IO, no? |
| 19:59 | <Domenic> | sicking: I didn't see any blocking, but maybe I didn't understand the futex stuff entirely. |
| 19:59 | <sicking> | Domenic: the futex stuff is entirely about blocking if I understand it correctly. That's the only thing it does |
| 20:00 | <sicking> | Domenic: There's two parts to it: 1. Blocking until you receive a signal, 2. Sending a signal to unblock someone |
| 20:01 | <sicking> | you could imagine exposing 2 to the main thread |
| 20:01 | <sicking> | but i'm not sure what complexities that would pull in |
| 20:01 | <Domenic> | OK. I guess I am less interested in the futexes and more in the actual SharedArrayBuffer data structure. |
| 20:01 | <sicking> | how would you used shared memory if you don't use futexes? |
| 20:02 | <Domenic> | Manually send signals when the background thread is done modifying a section? |
| 20:02 | <sicking> | transferring memory seems fine for that |
| 20:02 | <Domenic> | Yeah if you could transfer regions back and forth, that would suffice |
| 20:02 | <Domenic> | But nobody seems interested in that |
| 20:03 | <Domenic> | Probably because it isn't enough for pthread emulation? |
| 20:03 | <sicking> | the delta improvement over what is already there (thransferring entire buffers) doesn't seem big enough for the complexity maybe |
| 20:03 | <sicking> | right, and that |
| 20:04 | <Domenic> | transferring entire buffers is only there in Firefox :P |
| 20:04 | <sicking> | huh? |
| 20:04 | <Domenic> | ArrayBuffer.transfer is Firefox-proprietary |
| 20:04 | <sicking> | postMessage allows transferring arraybuffers in chrome too, no? |
| 20:04 | <Domenic> | Asynchronously |
| 20:05 | <sicking> | sure, but you were sending a asynchronous signal anyway, no? |
| 20:05 | <Domenic> | Yeah I guess so |
| 20:06 | <sicking> | so what's there allows you to do mainly what you were asking for. The only thing you can't do is to do a single allocation of a big buffer and then transfer parts |
| 20:06 | <sicking> | you'll have to allocate multiple buffers |
| 20:06 | <Domenic> | Right, which is wasteful if you don't know ahead of time how many bytes recv(2) is going to read from the socket |
| 20:07 | <Domenic> | Maybe not wasteful |
| 20:07 | <Domenic> | Just fragmenting |
| 20:07 | <sicking> | is the difference really that big between allocating 20 4kB buffers, and allocating one 80kB buffer? |
| 20:07 | <Domenic> | Which I don't have enough experience to know if that's a real problem |
| 20:07 | <Domenic> | Well |
| 20:07 | <sicking> | i don't think fragmentation is that big of a problem here |
| 20:08 | <Domenic> | If you allocate a 4 kB buffer and get only 1.5 kB, what do you do with the other 2.5 kB? |
| 20:08 | <sicking> | not when dealing with chunks that are of the same size, and are all "fairly large" |
| 20:08 | <Domenic> | You can either release it or you can try to reuse it, doing a recv(2) at offset 1.5 kB with length 2.5 kB |
| 20:08 | <Domenic> | Probably not a big deal though, yes. |
| 20:09 | <sicking> | yeah, i wouldn't think this is a problem |
| 20:09 | <sicking> | definitely not obviously enough a problem that we should assume it is without data |
| 20:16 | <sicking> | Domenic: fwiw, I believe that there might be people at mozilla who are interested in supporting transferring parts of an arraybuffer between threads. But someone needs to come up with a good API (which is tricky) as well as show interest across browsers (which is probably even trickier) |
| 21:03 | <roc> | Domenic: transferring independent buffers isn't just wasteful of memory, it breaks asm.js-like programs, which rely on all memory being accessible in a single array |
