| 00:42 | <jwalden> | is there a convenient site out there for doing cross-origin (and document.domain-joined origin) demonstration of behaviors? or do I need to conjure up one of my own provision? |
| 00:42 | <TabAtkins> | Domenic: Sure, you've just expressed annoyance at the "inlining" Bikeshed does for some things, so I assumed you'd prefer the linking thing. |
| 00:43 | <jwalden> | something like http://software.hixie.ch/utilities/js/live-dom-viewer/ that lets me do testing on nested.software.hixie.ch as well, or so |
| 01:31 | <smaug____> | rbyers: are you perhaps writing wpt tests for eventlistener options stuff? |
| 01:31 | <smaug____> | or maybe there is even some patches waiting for review ? |
| 01:32 | <rbyers> | smaug: Yes, sorry I haven't done it yet - been on my list, just been swamped with other stuff :-( |
| 01:32 | <smaug____> | ok |
| 01:32 | <rbyers> | Are you working on the Gecko impl and need tests? |
| 01:32 | <smaug____> | baku is working on the impl |
| 01:32 | <smaug____> | right now |
| 01:33 | <smaug____> | well, has patch for the dictionary (no passive handling or anything, just the dictionary) |
| 01:33 | <smaug____> | and I was wondering if we already have good test coverage |
| 01:33 | <rbyers> | I've got management crap occupying my time until Thursday but could make it my top priority then. |
| 01:33 | <rbyers> | We've got blink tests of course, still working on our WPT pipeline/process to avoid the test duplication... |
| 01:34 | <rbyers> | (had a good f2f chat with jdm@ and other Moz folks in Toronto a week ago about this) |
| 01:34 | <smaug____> | I think I can ask him to write tests |
| 01:34 | <rbyers> | Our blink tests are here: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/fast/events/eventlisteneroptions/&q=file:LayoutTests%20file:passive&sq=package:chromium&type=cs |
| 01:35 | <rbyers> | Oh right these are already testharness.js tests |
| 01:35 | <rbyers> | Perhaps all we need to do is upstream these |
| 01:36 | <rbyers> | dtapuska is about to land the change for the key, so they'll change then obviously |
| 01:36 | <smaug____> | that is about passive only I guess |
| 01:38 | <rbyers> | right |
| 01:40 | <rbyers> | looks like our tests have a few blinkisms in them, but shouldn't be hard to clean them up for WPT. Maybe I can get to that sooner than Thursday - I'll do my best (I haven't landed anything in WPT yet myself - was actually looking forward to the forcing function to experience the review pain people are telling me about <grin>) |
| 02:05 | jwalden | rolls his own cross-domain testing scheme, in the absence of someone else setting up a nice live system |
| 02:16 | <Domenic> | TabAtkins: Oh, I see, I misunderstood. Now that I get it, either solution sounds reasonable to me. |
| 03:32 | <Domenic> | ' |
| 04:47 | <annevk> | smaug____: rbyers: thoughts on https://github.com/whatwg/dom/issues/215? |
| 04:47 | <annevk> | smaug____: rbyers: delegation proposal seems quite nice, though making it fast might require bring some CSS selector tricks over to DOM |
| 04:48 | <annevk> | rbyers: I guess I should ping the other folks you mentioned instead, will do that |
| 04:50 | <smaug____> | performance is rather critical with event dispatch |
| 04:50 | <smaug____> | but I'll try to look at that a bit later, like on Thursday. rather busy right now |
| 04:51 | <smaug____> | I couldn't understand the last comment in that bug though |
| 04:51 | <smaug____> | what (1) and (2) refer to |
| 04:53 | <annevk> | smaug____: to my comment earlier, https://github.com/whatwg/dom/issues/215#issuecomment-213980467 |
| 04:53 | <annevk> | smaug____: lists two strategies for implementing delegation, but one is rather suboptimal it turns out |
| 04:54 | <annevk> | smaug____: agreed that it's important, I guess the question is if it's better that the browser does it or have libraries emulate it all over in JavaScript, since that's what's happening now |
| 04:54 | <annevk> | smaug____: happy to wait until Thursday day, there's no rush |
| 04:56 | <smaug____> | I don't understand what delegate: "foo" means |
| 04:57 | <annevk> | smaug____: "foo" is a selector |
| 04:57 | <smaug____> | and it selects what |
| 04:58 | <smaug____> | descendants ? |
| 04:58 | <annevk> | smaug____: yeah |
| 04:58 | <annevk> | smaug____: it's as if you registered the listener on descendants |
| 04:59 | <annevk> | smaug____: so you don't have to worry about elements getting inserted and removed |
| 04:59 | <smaug____> | I see |
| 05:00 | <smaug____> | I wonder... whether that should be delegation or some kind of automatic registration. I guess it is the latter, if it means "as if you registered the listener on descendants" |
| 05:01 | <annevk> | smaug____: then you'd also have to automatically deregister |
| 05:02 | <annevk> | smaug____: perhaps engines could implement it either way, not sure |
| 05:03 | <smaug____> | a question is when to run the selector |
| 05:07 | <annevk> | smaug____: yeah, I was thinking during dispatch |
| 05:08 | <annevk> | smaug____: I guess at the start of dispatch would be most consistent, but that would require going through the parent chain twice |
| 05:09 | <annevk> | smaug____: but the alternative might require going through the parent chain many more times |
| 05:10 | <smaug____> | gecko goes through the chain...hmm, 3 times. First creating the chain, then dispatch in default group (normal DOM dispatch) and then system group (for certain default handling and so) |
| 05:10 | <smaug____> | that iteration isn't slow |
| 05:11 | <smaug____> | but doing any specific operation on entries in the chain might slow things down quite a bit |
| 05:11 | <smaug____> | would need to think about how to optimize this all |
| 05:11 | <smaug____> | but I'm too jetlagged now to think about optimizations :) |
| 05:12 | <annevk> | smaug____: as I said, there's no rush, but it's appreciated š |
| 08:20 | <zcorpan> | "Thanks for getting in touch. We've added your idea of supporting fixup option in the squash and merge feature to our internal Feature Request List so the team can see it. It might be something we support in the future, but we can't promise when it will happen." |
| 08:28 | <smaug____> | rbyers: ok, since you have the tests in wpt form (or some similar) already, we decided to wait for you to upload those |
| 09:32 | <annevk> | MikeSmith: ę„ę¬čŖ is Japanese in Japanese, right? |
| 09:54 | <annevk> | MikeSmith: I went with that for now, believing Wikipedia... |
| 11:44 | <MikeSmith> | annevk: yeah |
| 11:49 | <annevk> | I added a commit to the navigate-editorial branch but it's not showing up in the PR... |
| 12:12 | MikeSmith | looks at that branch |
| 12:12 | <MikeSmith> | annevk: āmore browsingContextā? |
| 12:13 | <annevk> | MikeSmith: yeah |
| 12:13 | <annevk> | Seems to be resolved now |
| 12:13 | <MikeSmith> | hai |
| 12:13 | <annevk> | Maybe I was hitting some cache issues |
| 12:19 | <MikeSmith> | annevk: given https://github.com/w3c/webappsec-subresource-integrity/issues/31#issuecomment-214691579 maybe I will try to make PR myself for upstreaming the integrity attribute |
| 12:20 | <annevk> | MikeSmith: cool, mkwst can probably help review |
| 12:20 | <MikeSmith> | yeah |
| 13:24 | <JonathanNeal> | Iāve been working on a flexibility polyfill, and I have most of the calculations complete, but Iām unsure when/how Iām supposed to calculate flex within flex. Here is an example of flex rendered via JS https://rawgit.com/10up/flexibility/release/2.0.0/test.row.html |
| 13:25 | <JonathanNeal> | Iām a little unsure of what order I am supposed to run align-content, align-items, and when I should begin calculating flex within flex. Should flex within flex trigger a re-calc of the parent, or should I optimize the order to avoid this? Anyone know? |
| 13:29 | <JonathanNeal> | And hereās the control / native flexbox example https://rawgit.com/10up/flexibility/release/2.0.0/test.row.control.html |
| 14:04 | <miketaylr> | hober++ (re https://webkit.org/blog/6131/updating-our-prefixing-policy/) |
| 14:04 | <miketaylr> | et al |
| 14:22 | <Ms2ger> | About fucking time |
| 14:27 | <MikeSmith> | hober: Ms2ger is suggesting you edit your blog post to change the title to his suggestion just above |
| 14:30 | <jgraham> | Maybe he's angling for a job as head of PR at W3C |
| 14:32 | <mounir> | jgraham: I'm pretty sure Ms2ger would be able to disrupt the PR business :) |
| 15:03 | <wanderview> | does it make sense to queue a microtask to update an attribute on a DOM object exposed in a worker thread? that seems strange to me |
| 15:12 | <annevk> | wanderview: it doesn't not make sense, but it's not really typical either |
| 15:12 | <wanderview> | I think we can just use queue a task here... I asked him to change it |
| 15:24 | <hober> | MikeSmith miketaylr Ms2ger: :) |
| 15:25 | <Ms2ger> | hober, if you're bored at Apple, I'd be happy to write some copy ;) |
| 15:30 | <miketaylr> | :)~ |
| 16:05 | <annevk> | Domenic: I'm going to refactor document.open() and window.open() |
| 16:05 | <annevk> | Domenic: I'm thinking of "document open steps" and "window open steps" |
| 16:05 | <annevk> | Domenic: let me know if you have any concerns |
| 16:08 | <Domenic> | annevk: sounds reasonable. One thing I'd kind of like to fix is how document.open()s window-ish overload is in "mutations" or something in the IDL block and section structure. |
| 16:09 | <annevk> | Domenic: yeah, I was hoping that early in document.open() we could dispatch to either "document open steps" or "window open steps" based on the arguments |
| 16:10 | <Domenic> | I guess that could work. I was thinking of just moving the overload's dfn to a new section. |
| 16:11 | <annevk> | Yeah, maybe hmm |
| 16:12 | <annevk> | My main issue is all these algorithms invoking open() directly |
| 16:12 | <TabAtkins> | JonathanNeal: This should all be clear from the flex layout algorithm in the spec. |
| 16:33 | <annevk> | Domenic: created a branch document-open-steps with some WIP |
| 17:34 | <JonathanNeal> | TabAtkins: thanks, Iām still looking. Is this the right spot to be looking? https://www.w3.org/TR/css-flexbox-1/ |
| 17:35 | <gsnedders> | JonathanNeal: you probably want the editor's draft, see link at the top |
| 17:35 | <JonathanNeal> | Will do https://drafts.csswg.org/css-flexbox/#box-model |
| 17:36 | <Domenic> | Remember, /TR/ stands for trash. |
| 17:39 | JonathanNeal | mumbles ātechnical reportā... |
| 17:39 | <TabAtkins> | JonathanNeal: https://drafts.csswg.org/css-flexbox/#layout-algorithm to be specific |
| 17:40 | <TabAtkins> | Reading the rest of the spec helps you understand how to *use* Flexbox, but only the layout algo will actually tell you how it works. |
| 17:41 | <JonathanNeal> | Wonderful. Iām very close. I just got stuck once I needed to implement flex within flex. |
| 17:43 | <TabAtkins> | Important bit is to find the parts where the flex container tells the children to layout into some space. Layout is very hierarchical - you find available space in the parent, then lay out children into that space, then the parent positions them and finds out its full dimensions, and reports back to *its* parent that its layout is done. |
| 17:43 | <TabAtkins> | A quick tree-descent into the leaves, then a reverse walk back up finishing everything. |
| 17:44 | <JonathanNeal> | Yeap, itās how much ālay out children into that spaceā I need to do before decending into the children for the same deal. |
| 17:45 | <TabAtkins> | And the layout algo should explain that in detail. ^_^ |
| 17:45 | <JonathanNeal> | I am looking. I would imagine itās something like 9 to 9.4. |
| 17:47 | <TabAtkins> | Hmmmmmm, the step numbering got broken and no longer continues thru the sections. >_< |
| 17:49 | <JonathanNeal> | If a flex item is also flex, then I need to know that itemās main and cross size before laying out its children. |
| 18:40 | <Domenic> | TabAtkins: ping on speccing https://github.com/w3c/webcomponents/issues/468 for me :) |
| 18:40 | <TabAtkins> | Yup, was thinking about that when I saw the bug activity today. ^_^ |
| 18:40 | <TabAtkins> | What form do you want that in, actually? |
| 18:41 | <TabAtkins> | oh never mind, you actuall provided that |
| 18:41 | <TabAtkins> | i'll slip it into scoping |
| 18:41 | <Domenic> | \o/ |
| 18:41 | <Domenic> | Open to suggestions if you think my "creates a custom user-agent stylesheet" idea could use some tweaking |
| 18:42 | <Domenic> | I want it to be window scoped since custom element registries are, but not sure if that fits with CSS infrastructure |
| 18:42 | <Domenic> | "element's node document's window" is I guess how you get from element -> window |
| 18:44 | <Domenic> | annevk: what is "the default origin"? |
| 18:44 | <annevk> | Domenic: dunno |
| 18:44 | <Domenic> | annevk: from your post in https://github.com/whatwg/html/pull/1122#issuecomment-214757427 |
| 18:48 | <annevk> | Domenic: ooh, the origin for fetching when none is specified is from the client |
| 18:48 | <Domenic> | hmm |
| 18:53 | <Mek> | but yeah, it definitely seems something is broken in the workers/fetch/csp3 integration. Where the child-src CSP policies of the document/worker creating a worker should possibly block creating the worker but the way it is currently specced in csp3 we would end up using the CSP policies from the worker itself (which don't even exist yet before the worker is fetched) |
| 21:49 | <miketaylr> | TabAtkins: yo, what's the magic way to make <<color>> autolinks point to css-color-4 in bikeshed? |
| 21:49 | <miketaylr> | link-defaults doesn't seem to like "spec:css-color-4; type:value; text:color" |