| 01:31 | <MikeSmith> | caitp: about what's hot, 100% agree with what smaug said about ServiceWorker and the Web Components renaissance |
| 01:31 | MikeSmith | looks back through his list of other stuff |
| 01:38 | <caitp-> | that comment was really more like "what will be getting deprecated in the next 5 years" |
| 01:39 | <caitp-> | because you know, some of this stuff is gonna fall apart |
| 01:39 | <caitp-> | and it will be sad |
| 02:45 | <MikeSmith> | caitp: oh, well that's an interesting question too |
| 02:47 | <MikeSmith> | caitp: so in that light, not sure the future looks so bright for IndexedDB |
| 02:49 | <MikeSmith> | caitp: maybe you know this already but annevk has been driving some effort on a more rational "unified architecture for storage on the web" https://wiki.whatwg.org/wiki/Storage |
| 02:50 | <MikeSmith> | other stuff... I wonder (hope) that a lot of use cases for Web Sockets might get obviated by WebRTC DataChannel |
| 02:50 | <roc> | MikeSmith: why do you say "not so bright for IndexedDB"? |
| 02:51 | <MikeSmith> | hey roc |
| 02:51 | <MikeSmith> | from talking with annevk and slightlyoff and others last week |
| 02:52 | <MikeSmith> | we already know webdevs aren't exactly warm to that API |
| 02:52 | <MikeSmith> | roc: lemme get you a URL for the notes from annevk session on storage last week |
| 02:53 | <MikeSmith> | roc: or did you see those notes already? |
| 02:53 | <MikeSmith> | roc: https://pad.w3ctag.org/p/EWS-20April2015-Breakout1.1.md |
| 02:54 | <MikeSmith> | hmm I see now those a pretty sketchy as far as capturing the comments about IndexedDB |
| 02:55 | <roc> | to be precise, it captured none of them :-) |
| 02:56 | <MikeSmith> | yeah I'm looking to see if some of slightlyoff comments elsewhere got recorded |
| 02:57 | <MikeSmith> | roc: in the mean time if you want a more informed view, you probably want to ask annevk to share some thoughts with you directly |
| 02:58 | <roc> | I hardly ever get to talk to Anne, he's on the wrong side of the planet :-) |
| 02:58 | <MikeSmith> | well |
| 02:58 | <MikeSmith> | you just need to travel more |
| 02:58 | <MikeSmith> | but yeah, sucks for us |
| 02:59 | <MikeSmith> | probably you're in the worst possible timezone for wide real-time collaboration |
| 02:59 | <MikeSmith> | Tokyo is just slightly better |
| 02:59 | <MikeSmith> | roc: https://pad.w3ctag.org/p/22-minutes |
| 02:59 | <MikeSmith> | see the first part on Storage |
| 03:00 | <MikeSmith> | e.g., slightlyoff comments about "likely we'll struggle with the storage mechanismsm we have right now, because they're not integrated. Re the locking propblem: IndexDB has a similar problem" |
| 03:01 | <MikeSmith> | and "How do we deal with storage locking? Now, IndexDB has a nasty way of daling with this: it closes transactions at the end of the task. You could extend the life of the transaction (artifically), — but it's there to keep developers from getting themselves into an inconsistent state.... This goes badly with other apps wanting access to the storage and trying to coordinate about the transaction lifet |
| 03:01 | <MikeSmith> | ime" |
| 03:02 | <MikeSmith> | "But now, It isn't possible to coordinate your rights to a cached storage area with a indexDB transaction. We're clearly missing a locking system" |
| 03:03 | <MikeSmith> | this reminds me, Travis is pretty great a scribing |
| 03:03 | <MikeSmith> | I was there in the room for that discussion and those notes do a very good job of capturing it in good detail |
| 05:43 | <annevk> | MikeSmith: so that's the underlying architecture of IDB and localStorage et al |
| 05:43 | <annevk> | MikeSmith: there's no plans for getting rid of IDB |
| 05:43 | <annevk> | MikeSmith: in fact, we're extending it |
| 05:43 | <MikeSmith> | ah so I was confused |
| 05:44 | <MikeSmith> | so you're documenting the underlying architecture but not changing it? |
| 05:44 | <MikeSmith> | I mean it can be changed fundamentally at this point can it? |
| 05:45 | <annevk> | MikeSmith: yeah, in a way |
| 05:45 | <annevk> | MikeSmith: what I want to define is what all these APIs are grounded in, what their underlying storage box is |
| 05:45 | <annevk> | MikeSmith: and then define ways to make that box persistent |
| 05:45 | <MikeSmith> | ok |
| 05:45 | <annevk> | MikeSmith: and then define ways to make additional boxes and allow IDB and Cache API etc to use those newly created boxes |
| 05:45 | <MikeSmith> | annevk: ok what about the IndexedDB locking issue that slightlyoff pointed out? |
| 05:45 | <MikeSmith> | I see |
| 05:47 | <MikeSmith> | so I guess there's no plan to expose a different higher-level API |
| 05:47 | <annevk> | MikeSmith: due to IDB having transactions it doesn't actually have a locking problem |
| 05:47 | MikeSmith | realizes now he'd been reading too much into this |
| 05:47 | <annevk> | MikeSmith: but the way it does transactions is also what makes it complicated |
| 05:48 | <MikeSmith> | annevk: I thought slightlyoff or somebody brought this up at the summit session too |
| 05:48 | <MikeSmith> | I mean the thing I pointed roc too |
| 05:48 | <MikeSmith> | in the TAG minutes |
| 05:48 | <annevk> | https://gist.github.com/inexorabletash/8c122c84a65de65c35b3 and https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191 have ideas around new higher-level APIs and new lower-level APIs around IDB |
| 05:48 | <MikeSmith> | ah ok |
| 05:49 | <annevk> | To model IDB with promises you basically need to create some kind of promise subclass to handle transactions |
| 05:49 | <MikeSmith> | so maybe I wasn't completely imagining it |
| 05:49 | <MikeSmith> | my memory is pretty sketchy even in the best of times, let alone when jetlagged and hung over |
| 05:49 | MikeSmith | looks at annevk links |
| 05:50 | <roc> | phew! |
| 05:50 | <MikeSmith> | heh |
| 05:50 | <MikeSmith> | I'm still sure I didn't imagine the think slightlyoff said about the locking-like problem |
| 05:52 | <MikeSmith> | annevk: from http://krijnhoetmer.nl/irc-logs/whatwg/20150430#l-139 |
| 05:53 | <MikeSmith> | "Re the locking propblem: IndexDB has a similar problem" and the other quoted stuff after that |
| 05:53 | <annevk> | MikeSmith: sure, I addressed that above |
| 05:53 | <MikeSmith> | oh |
| 05:53 | <MikeSmith> | I guess I should actually read stuff |
| 05:53 | <annevk> | MikeSmith: all storage has a locking issue since two tabs can address the same storage at the same time |
| 05:54 | <annevk> | MikeSmith: IDB deals with this by having transactions, but not everyone is a fan of the way it does those |
| 05:54 | <MikeSmith> | ah flags |
| 05:54 | <annevk> | MikeSmith: localStorage has a theoretical "storage mutex", but in practice it's racy |
| 05:54 | <MikeSmith> | right yeah that much I already understood |
| 05:55 | <MikeSmith> | and knew too that IndexedDB by design didn't need a mutex |
| 05:57 | <MikeSmith> | hmm I also recall now that I only caught half your session because I was in whatever session that was next door the other half of that hour |
| 05:58 | <MikeSmith> | anyway I'm glad there's a way forward and things will get rationalized further |
| 05:59 | <annevk> | We have some cross-browser agreement to add persistent storage |
| 06:00 | <annevk> | But there's quite a bit of demand from e.g. gaming to go beyond that as per the wiki page |
| 06:00 | <annevk> | Need to flush that out some more and I guess write down persistent storage and storage architecture... |
| 06:01 | <MikeSmith> | I guess that's what I had been thinking about, along with thinking it was planned to supersede/obsolete both IndexedDB and localStorage |
| 06:02 | <annevk> | Ah I see, underpinnings != primitives, at least not yet |
| 06:06 | <MikeSmith> | aha |
| 06:06 | <MikeSmith> | ok |
| 07:34 | <annevk> | Hmm |
| 07:35 | <annevk> | Were accounts moved to this new discuss.webplatform.org thing too? |
| 07:35 | <annevk> | Not sure I'm super happy contributing to webplatform.org branded stuff given the disaster they made out of docs |
| 07:48 | <MikeSmith> | annevk: please keep an open mind there |
| 07:49 | <MikeSmith> | at this point everybody recognizes that the docs thing didn't work out |
| 07:50 | <MikeSmith> | IMHO it was a failed plan from the get-go but I don't fault others for having thought differently and having actually tried in good faith to make it happen as planned |
| 07:52 | <MikeSmith> | but there is some momentum toward making a reborn webplatform.org that discuss.webplatform.org will be part of, and I think you'll see it transition into being much more of a genuinely community-driven project that you'll be much happier to participate in |
| 07:53 | <MikeSmith> | more like web-platform-tests |
| 07:53 | <annevk> | I don't know, I wasn't particularly thrilled either with the forking of URL to yet another location either |
| 07:53 | <annevk> | I've yet to see the benefit of that |
| 07:53 | <MikeSmith> | well that was not a top-down thing |
| 07:53 | <MikeSmith> | iirc |
| 07:53 | <MikeSmith> | that was a choice that Sam made |
| 07:54 | <MikeSmith> | and maybe it's not going to work out at that other place but if so we can write it off a lesson learned I guess |
| 07:55 | <annevk> | And that community supported that action apparently rather than pushing back |
| 07:57 | <MikeSmith> | I don't know that anybody "supported" it other than in the sense of facilitating Sam's choice to experiment with it there |
| 07:57 | <MikeSmith> | anyway to be clear I think when the dust settles for discuss.webplatform.org it will be minus any of the docs.webplatform.org stuff, which at this point pretty clearly to everybody is now completely obviated by MDN (or clearly now always has been) |
| 07:58 | <MikeSmith> | just please don't feed into killing new ideas for what to do with webplatform.org before anybody's had a chance to try more |
| 07:58 | <annevk> | Well, what good stuff has happened there so far? |
| 07:58 | <MikeSmith> | the basic goal here really is to try to faciliate more real colloboration |
| 07:59 | <MikeSmith> | annevk: the specifiction stuff |
| 07:59 | <annevk> | It seems to me that happened elsewhere and just got folded in, as they tried to do with MDN and failed pretty drastically at |
| 08:00 | <MikeSmith> | which is just changing from being run at Robin's own domain into being something that tries to fit in with a bigger picture around collaboration |
| 08:00 | <MikeSmith> | no the analogy would be more like MDN having been moved to a new domain |
| 08:00 | <MikeSmith> | so it's not a fair comparison |
| 08:16 | <annevk> | philipj: yo |
| 08:16 | <annevk> | philipj: I guess you can rename that repo now |
| 08:17 | <annevk> | philipj: let me know when you're all set up and then I can add the commit hook and such |
| 08:20 | <Domenic> | annevk: looks like fixing file URLs on windows will be easier than you thought: https://github.com/jsdom/whatwg-url/commit/c13670dffdef1f31cb53d9c342076a27a5742760 |
| 08:21 | <annevk> | Domenic: the lack of tests is disturbing |
| 08:21 | <Domenic> | annevk: heh yeah that commit was 14 commits ago before he put the web-platform-tests in place. It was just a prototype. |
| 08:21 | <annevk> | Ah okay |
| 08:22 | <Domenic> | annevk: I am pretty sure Sebmaster is waiting to get 100% pass rate on web-platform-tests before starting to make spec modifications |
| 08:22 | <Domenic> | I am hopeful that we can convince Sebmaster to start submitting PRs to url.spec.whatwg.org :). We can probably tackle lots of the cases at https://url.spec.whatwg.org/interop/test-results/?select=current too |
| 08:22 | <annevk> | Do you think he's willing to help edit the spec? Sam hasn't really been making progress and I don't think the diagramification of parsing is the way to go anymore... |
| 08:23 | <annevk> | Sounds good |
| 08:23 | <Domenic> | Yeah I mean even if he's not then I might be up for doing literal translation from JS to spec-ese since the implementation follows the spec so closely it should be quite easy |
| 08:24 | <Domenic> | Agreed that diagramification was not so great... I mean I think state machines are pretty reasonable for implementers. Maybe not for authors, but that's a separate issue IMO. |
| 08:25 | Ms2ger | is very surprised |
| 08:26 | <Sebmaster> | o/ |
| 08:27 | <annevk> | I slightly prefer the functional variant SimonSapin came up with for Rust, I think that could work well in the specification and make it a little easier to comprehend |
| 08:27 | <Sebmaster> | Not sure if I'm good at writing specs |
| 08:27 | <annevk> | But I could live with keeping the current state-based version |
| 08:27 | <annevk> | Sebmaster: it's translating code to English and coming up with "good" terms |
| 08:28 | <Sebmaster> | my modification to the algorithm is buggy at the moment in any case, it doesn't work well with resolving //C:/abc on base file:///D:/ |
| 08:28 | <botie> | Hmm. No matches for that, Sebmaster. |
| 08:28 | <Sebmaster> | but that shouldnt be hard to fix |
| 08:30 | <Domenic> | wait, what triggered botie, that was weird |
| 08:37 | <MikeSmith> | Domenic: yeah I guess that triggered the thing in botie where looks for "x is y" stuff but not sure why botie seems to have thought Sebmaster was asking for a match for something |
| 08:44 | <philipj> | annevk: richt and I are setting it up right now, I'll ping you shortly |
| 08:45 | <annevk> | philipj: cool, I agree that the renaming is better |
| 08:45 | <annevk> | philipj: GitHub takes care of redirects and you keep everyone that already starred and forked engaged |
| 08:53 | <philipj> | annevk: I didn't know about renames before Marcos told me yesterday :) |
| 08:58 | <philipj> | annevk: https://github.com/whatwg/mediasession now has a mediasession.html, any time the master branch changes we'd like that to be published to https://mediasession.spec.whatwg.org |
| 09:05 | <annevk> | philipj: it's live |
| 09:05 | <annevk> | philipj: you need to update some links in the spec to reflect the new GitHub URL |
| 09:08 | <Domenic> | philipj: I also have it on my todo list to hook up automatic compilation so you don't have to commit output to repos |
| 09:32 | <annevk> | philipj: you also need a logo :p |
| 09:47 | <Sebmaster> | Oh yeah, annevk |
| 09:47 | <Sebmaster> | the url test suite expects some test cases to fail; does "fail" in that context mean parse error or return failure? |
| 10:03 | <annevk> | Sebmaster: not sure |
| 10:03 | <annevk> | Sebmaster: prolly return failure |
| 10:03 | <Sebmaster> | yeah, i think so too |
| 10:03 | <annevk> | Sebmaster: I don't think parse errors are tested |
| 10:03 | <Sebmaster> | since as far as i read, parse errors arent even exposed on the final url object? |
| 10:04 | <annevk> | Anyone experience with WiFi repeaters? Wondering whether to buy an Airport Express since there's some lag between floors... |
| 10:04 | <annevk> | Sebmaster: correct, they're an error console affair |
| 10:04 | <annevk> | Sebmaster: well, potential error console affair |
| 10:04 | <annevk> | Sebmaster: it's not entirely clear what we want to do with them yet |
| 10:04 | <SteveF_> | annevk: cheers for responses yestrerday |
| 10:06 | <Sebmaster> | 14 test cases still failing then, most of them due to unicode / host verification |
| 10:06 | <annevk> | Sounds like we need more tests |
| 10:50 | <Sebmaster> | i think i won't be able to continue with host validation without someone implementing this flavor of TR46 in JS :( |
| 10:52 | <Domenic> | Sebmaster: I think rubys might have done so. At least, he has a JS implementation that passes all the tests. |
| 10:52 | <Sebmaster> | where's that? |
| 10:53 | <Domenic> | https://github.com/rubys/url/tree/peg.js/reference-implementation I think... there's some Ruby-to-JS stuff going on... |
| 10:55 | <Sebmaster> | ah, that retrieves the mapping table thing |
| 10:55 | <Domenic> | then https://github.com/rubys/url/blob/peg.js/url.pegjs#L600-L616 |
| 12:05 | <philipj> | annevk: awesome, thanks you! |
| 12:06 | <philipj> | Domenic: that would be cleaner, but I quite like that I can go back in the history of specs to see what they looked like at each point, which is a lot harder if toolchains and build scripts change over the years |
| 12:08 | <annevk> | philipj: Domenic keeps static snapshots for that |
| 12:09 | <philipj> | annevk: in a separate repo? |
| 12:09 | <annevk> | philipj: no repo, similar to what browsers do for nightly builds |
| 12:09 | <Domenic> | auto-generated and uploaded to the server on every push. https://streams.spec.whatwg.org/commit-snapshots |
| 12:09 | <philipj> | oh, I guess that works if you're looking for a specific version |
| 12:13 | <Domenic> | https://streams.spec.whatwg.org/commit-snapshots/?C=M;O=D gives a nice chronological view too |
| 12:19 | <philipj> | annevk: is the webhook installed now? https://mediasession.spec.whatwg.org/ is no longer in sync with Git |
| 12:19 | <philipj> | or does it update once an hour or something? |
| 12:20 | <annevk> | philipj: oh maybe I forgot to set chmod |
| 12:22 | <annevk> | philipj: seems to work? |
| 12:23 | <philipj> | annevk: now it's up to date, did you have to poke something? |
| 12:23 | <annevk> | philipj: well I poked something that should be poked automatically |
| 12:23 | <philipj> | annevk: hmm, is the webhook on a specific port that needs to be opened? |
| 12:24 | <philipj> | (that's how I did mine) |
| 12:24 | <annevk> | philipj: no |
| 12:24 | <annevk> | philipj: it says it already worked a couple times successfully |
| 12:24 | <annevk> | philipj: perhaps you had a cache hit? |
| 12:25 | <philipj> | annevk: I reloaded a bunch, so I don't think so |
| 12:25 | <annevk> | philipj: hmm let me know if this persists |
| 12:25 | <philipj> | annevk: where are the logs on the server so I can check myself if it fails again? |
| 12:25 | <annevk> | philipj: in logs top-level dir |
| 12:27 | <philipj> | annevk: I guess it's not on the same machine as html5.org where I'm looking? |
| 12:27 | <annevk> | philipj: oh right |
| 12:29 | <annevk> | philipj: let me try to copy your key to this other server too |
| 12:30 | <philipj> | annevk: I guess I can then just ssh to mediasession.spec.whatwg.org? |
| 12:30 | <annevk> | philipj: yeah, if only I could figure out how to copy a line from nano |
| 12:32 | <philipj> | annevk: ctrl+k, but I don't know if that puts it in any clipboard |
| 12:32 | <annevk> | doesn't |
| 13:08 | <annevk> | Domenic: I feel like you hijacked that thread a bit... oh well, hopefully everyone can still follow |
| 13:09 | <Domenic> | annevk: I was trying to come up with a way to solve the "when do we call distributeCallback" and "how do we get consistency on offsetTop etc." problem. |
| 13:09 | <annevk> | we can't |
| 13:09 | <annevk> | that's why you throw offsetTop of the rails |
| 13:10 | <Domenic> | it wasn't clear to me at the time. last message helps a bit. |
| 13:11 | <annevk> | To understand this is a bit like baking apple pie |
| 13:12 | <annevk> | Actually, the first invent the universe analogy doesn't hold up too well |
| 13:12 | <annevk> | Domenic: so Layout is async. But offsetTop forces Layout to be sync. |
| 13:13 | <annevk> | Domenic: Distribution is async but needs to happen before Layout. So offsetTop forces it to be sync. |
| 13:13 | <Domenic> | sure. still seems OK to me for .offsetTop to invoke distributeCallback. |
| 13:13 | <Domenic> | why is distribution async |
| 13:13 | <annevk> | Domenic: well say it's sync |
| 13:13 | <annevk> | Domenic: then modifying the DOM invokes distribution sync |
| 13:14 | <annevk> | Domenic: and then we have mutation events back |
| 13:14 | <annevk> | we want sync mutation events less than we want offsetTop to work, imo |
| 13:15 | <Domenic> | maybe. I dunno, I can see authors adding `set offsetTop(v) { this.distribute(); super.offsetTop = v; }` etc. to get the behavior back. |
| 13:15 | <annevk> | seems fine |
| 13:15 | <annevk> | and they could likewise overload appendChild and such like that |
| 13:15 | <Domenic> | yeah, someone will make a mixin that just overrides everything necessary. |
| 13:16 | <Domenic> | almost some sort of ... shadow DOM polyfill .... |
| 13:16 | <annevk> | which is why I'd prefer not do anything with timing or doing anything automatically for v1 |
| 13:16 | <annevk> | although timing equivalent to mutation observers seems reasonable and not too hard to add |
| 15:53 | <annevk_> | TabAtkins: so if I want to link "environment settings object" in HTML, what's the easiest way to do that? |
| 16:09 | <dglazkov> | annevk: have to be careful here with offsetTop et al. |
| 16:09 | <dglazkov> | I agree they're terrible APIs, but they also are widely used |
| 16:10 | <dglazkov> | so we need to make darn sure we don't turn the distribution API into something that you can only use on in a small set of the web that doesn't use these terrible APIs |
| 16:10 | <annevk> | As long as we leave timing to users of the API there's no problem |
| 16:11 | <dglazkov> | can you explain this a bit more? |
| 16:11 | <annevk> | Distribution only happens when you invoke distribute() |
| 16:12 | <dglazkov> | btw, my concern is captured well here: https://gist.github.com/rniwa/2f14588926e1a11c65d3#extention-to-custom-elements-for-consistency |
| 16:13 | <dglazkov> | I think the question is: who needs to invoke the distribute()? In a situation where component is developed by dev A and is being used by dev B, specifically. |
| 16:13 | <smaug____> | annevk: well, we may need to define some way to trigger callbacks at the end of nanotasks, in order to have distribution happening early enough |
| 16:14 | <dglazkov> | what if we just run them in a separate environment, pure-function-style |
| 16:14 | <dglazkov> | ? |
| 16:15 | <smaug____> | don't understand that question |
| 16:15 | <smaug____> | separate environment? |
| 16:15 | <dglazkov> | run distribution callback in a separate script environment, with no access to the docs global |
| 16:15 | <smaug____> | like, adding isolation ;) |
| 16:15 | <dglazkov> | sort of, except in a very limited way |
| 16:16 | <dglazkov> | like a pure function, where there's really nothing else but the arguments of the function |
| 16:16 | <dglazkov> | that way, there will never be a problem with timing and we don't have to specify how the execution of the distribution callback correlates with the style resolution or anything like that |
| 16:17 | <smaug____> | well, if arguments are like nodelists, you can access the global object from there |
| 16:17 | <dglazkov> | they would be some dumb objects |
| 16:17 | <smaug____> | oh, some kind of weird proxy objects around the actual nodes |
| 16:17 | <dglazkov> | like a serialization of an element |
| 16:17 | <dglazkov> | or a proxy |
| 16:17 | <smaug____> | s/weird/dummy/ |
| 16:18 | dglazkov | waves hands |
| 16:21 | <annevk> | I'm not sure that's gonna work |
| 16:21 | <annevk> | that would defeat things like using Media Queries as input to distribute nodes |
| 16:21 | <annevk> | or require adding all those APIs in an "separate script environment" |
| 16:22 | <dglazkov> | true |
| 16:22 | <annevk> | dglazkov: A needs to invoke distribute(), though B could too I suppose if it's not closed |
| 16:22 | <annevk> | smaug____: do we need to do that for v1? |
| 16:22 | <smaug____> | add a flag to MutationObserver whether it should be called at the end of microtask or nanotask, and let shadow dom users then call distribute if needed ? |
| 16:23 | <dglazkov> | annevk: when does A invoke distribute(), then? |
| 16:23 | <annevk> | smaug____: nanotask observers seems useful, but I wonder whether we need it for v1 |
| 16:23 | <smaug____> | annevk: maybe not for v1, but need to think about v2 too a bit |
| 16:23 | <annevk> | dglazkov: whenever they think that is needed |
| 16:23 | <dglazkov> | annevk: I would like to flesh this out a bit more :) |
| 16:24 | <annevk> | dglazkov: I think I would put advice to devs to use mutation observers |
| 16:25 | <annevk> | dglazkov: but they have the freedom to call it at other times or provide hooks to the outside world, etc. |
| 16:25 | <smaug____> | yeah, I like the freedom distribute() gives |
| 16:26 | <smaug____> | we're just missing the nanotask-like thing from the platform atm, and that will be needed at some point |
| 16:26 | <smaug____> | (perhaps we need nanotasks only for DOM mutations, so it wouldn't be a generic thing, but MutationObserver only) |
| 16:27 | <annevk> | nanotasks are like IDL exit callbacks |
| 16:27 | <dglazkov> | let's try to make this a bit more concrete: https://gist.github.com/dglazkov/bdbe817b9cce48e4d072 |
| 16:27 | <dglazkov> | when does A have a chance to run distribute in that gist? |
| 16:27 | <annevk> | dglazkov: as I said elsewhere that fails |
| 16:27 | <annevk> | dglazkov: though not with a future nanotasks thingie |
| 16:28 | <annevk> | dglazkov: here is the tradeoff: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0450.html |
| 16:28 | <annevk> | dglazkov: if you can defeat the tradeoff you win, but otherwise we should just make a choice and move on |
| 16:28 | <smaug____> | annevk: we don't want distribute() to be called at the end of any nanotask, only after dom mutations, I think |
| 16:28 | <dglazkov> | annevk: I am confused. Are you saying that you would put the burden on B to make this work? |
| 16:28 | <annevk> | smaug____: I agree that we want to scope nanotasks |
| 16:29 | <annevk> | dglazkov: yeah |
| 16:29 | <dglazkov> | annevk: that means that shadow DOM components can't be used in pretty much any framework that exists today. |
| 16:29 | <dglazkov> | that seems... drastic? |
| 16:29 | <annevk> | dglazkov: again see tradeoff? |
| 16:31 | <dglazkov> | annevk: I saw the link, but I am not sure that the cost of web component not being adopted anywhere in any foreseable future is worth the benefit in this trade-off |
| 16:31 | <dglazkov> | right? |
| 16:31 | <dglazkov> | I mean.. the whole point of web components is to conform to DOM contract that exists currently |
| 16:32 | <annevk> | dglazkov: I don't think there's another tradeoff? |
| 16:32 | <dglazkov> | the separate environment is one |
| 16:33 | <dglazkov> | you're trading hypothetical media query use cases for being able to satisfy all other requirements |
| 16:33 | <annevk> | dglazkov: that seems very unlikely to happen to me |
| 16:34 | <dglazkov> | tell me more |
| 16:35 | <annevk> | As far as I know this has been a research area for TC39 for quite a while |
| 16:35 | <dglazkov> | oh, I see |
| 16:35 | <annevk> | At least subclassing was a somewhat concrete idea when we started Shadow DOM |
| 16:35 | <annevk> | I mean, Web Components |
| 16:35 | <dglazkov> | you're worried that if we pursue true pure functions, we'll be blocked on TC39 for a while |
| 16:36 | <annevk> | Another five years? |
| 16:36 | <dglazkov> | that seems _awesome_ |
| 16:36 | <dglazkov> | :D |
| 16:36 | annevk | would like to ship something... |
| 16:36 | <annevk> | dglazkov: so nanotasks? |
| 16:37 | <annevk> | dglazkov: mutation observer nanotasks, that is |
| 16:37 | <annevk> | dglazkov: that gives A a callback at the end of B's call to appendChild(), which can invoke distribute(), which means B's call to offset gets the right answer |
| 16:38 | <dglazkov> | you know what |
| 16:38 | <dglazkov> | maybe! |
| 16:38 | <dglazkov> | let me think about this |
| 17:02 | <annevk> | Hahaha |
| 17:02 | <annevk> | <a>origin</a> links to http://dev.w3.org/csswg/css-cascade-4/#origin |
| 17:06 | <annevk> | TabAtkins: so what I'd like is something like <a from=html>origin</a> |
| 17:29 | <Domenic> | Pure functions can be defined without TC39 I think |
| 17:30 | <Domenic> | You serialize the function to a string |
| 17:30 | <Domenic> | If it works in the other environment then it's pure |
| 17:30 | <Domenic> | That is what came up when I asked TC39 about this |
| 17:35 | <bradleymeck> | Domenic: you can also parse out if a function is pure, but it is pricey in JS |
| 17:35 | <bradleymeck> | parse/analyze |
| 18:02 | <wanderview> | jgraham: I think this one is ready for merge: https://critic.hoppipolla.co.uk/r/4838 |
| 18:10 | <jgraham> | wanderview: Done. How many of your PRs are left? |
| 18:11 | <jgraham> | Just one? |
| 18:11 | <wanderview> | jgraham: just one :-) https://critic.hoppipolla.co.uk/r/4825 |
| 18:11 | <jgraham> | OK, I'll kick off an update in gecko as soon as that one gets reviewed |
| 18:11 | <jgraham> | and merged |
| 18:17 | <dglazkov> | Domenic: how quickly can we confirm/reject the hypothesis that we don't need TC39 for pure functions? |
| 18:17 | <dglazkov> | I would like to keep all ideas on the table |
| 18:17 | <dglazkov> | do we even need pure functions? |
| 18:22 | SteveF_ | trys to follow shadow dom/web components discussion, totally out of my league |
| 18:33 | <MikeSmith> | botie, inform SteveF_ re: "SteveF_ trys to follow shadow dom/web components discussion, totally out of my league", you're in good company. I think the set of people who actually understand all of this well can be counted on two hands |
| 18:33 | <botie> | will do |
| 18:42 | <caitp-> | trevnorris, re: optimizing subclasses, i wouldn't expect hydrogen to deal with them, but turbofan might already |
| 18:43 | <trevnorris> | caitp-: not as of 4.4.44. was trying to get some info out for IRHydra and there was no output. |
| 18:44 | <caitp-> | does IRHydra deal with TF at all? |
| 18:44 | <trevnorris> | yup. |
| 18:44 | <caitp-> | anyways, it will end up optimized in TF at some point |
| 18:45 | <trevnorris> | no doubt. it just threw me when there wasn't any output. thought there was something wrong with the internal V8 tracing. |
| 19:10 | <Domenic> | dglazkov: we can do a slow polyfill (web workers + actual JS serialization) in a day or two. |
| 19:15 | <botie> | SteveF_, at 2015-04-30 18:33 UTC, MikeSmith said: re: "SteveF_ trys to follow shadow dom/web components discussion, totally out of my league", you're in good company. I think the set of people who actually understand all of this well can be counted on two hands |
| 19:16 | <SteveF_> | botie: gotcha player ;-) |
| 19:16 | <botie> | SteveF_: i'm not following you... |
| 19:18 | <jgraham> | Anyone know why this expects to throw an error? https://github.com/w3c/web-platform-tests/blob/master/workers/interfaces/WorkerGlobalScope/close/setTimeout.html |
| 20:13 | <wanderview> | Domenic: its unfortunate Response.body.getReader() does not have backpressure yet |
| 20:14 | <wanderview> | I guess I can build backpressure at the app level |
| 21:26 | <jgraham> | Hixie: Did the spec at some point change so that a worker that does close(); setTimeout(function(){},0) would no longer fire an error event? |
| 21:37 | <dglazkov> | MikeSmith: can you give rniwa w3c/webcomponents commit bit? |
| 21:49 | <terinjokes> | JakeA: w/r/t your tweet, it's something I certainly want to do |
| 22:22 | <TabAtkins> | annevk: You're looking for the spec='' attribute. The problem, though, is that HTML is really incredibly terrible for Bikeshed links. Nothing is "exported", in Bikeshed's terms, and it's all typed as "dfn" type definitions. That's why CSS's "origin" definition is winning; Bikeshed prefers exported definitions by default. |
| 22:23 | <TabAtkins> | After I finish up this File API spec, though, I'm gonna roll up something to do some manual link-adding, so we can put HTML terms in manually and let everyone use them. |
| 22:24 | <TabAtkins> | (Technically I can add custom definitions right now, but they all get interpreted as being "local" definitions, which auto-win over cross-spec defs, which isn't the behavior I want here. It won't be hard to fix.) |
| 22:25 | <TabAtkins> | annevk: For arbitrary terms that you want to link to in a one-off fashion, tho, just add them to the <pre class=anchors> block in your spec. There should already be a bunch of HTML anchors in there, so it'll be obvious how to do so. |
| 22:37 | <TabAtkins> | annevk: Oh man, just realized why a bunch of terms aren't linking to DOM; they're not exported either. Do you want a PR for exporting all the stuff, or is it okay for me to push directly to the spec? |
| 23:37 | <MikeSmith> | dglazkov: Yeah will try to do that right now (from my mobile) cc rniwa |
| 23:41 | <MikeSmith> | dglazkov: Ok, invite sent |
| 23:41 | <MikeSmith> | rniwa: you should have perms now |