| 06:08 | <annevk> | For a moment I thought inclusive siblings would let me get rid of contiguous Text nodes, but alas... |
| 07:16 | <annevk> | In the category everything old is new again: https://github.com/whatwg/fetch/issues/83 |
| 08:21 | <annevk> | mkwst: https://fetch.spec.whatwg.org/#client-request is the set of terms of we have today |
| 08:21 | <annevk> | mkwst: we could rename resource request to subresource request, but that still wouldn't include workers |
| 08:22 | <annevk> | mkwst: we could make it include workers, and then name the other type "non-worker subresource request"? |
| 09:19 | <hgl> | annevk, why fetch couldn't return document directly like xhr does? is there something prevents res.document() to work? |
| 09:20 | <annevk> | hgl: we mostly decided we didn't want the Fetch layer to depend upon the HTML parser |
| 09:20 | <annevk> | (and all of DOM) |
| 09:21 | <annevk> | once streams are out I'm sure something will come along that plugs all these pieces together |
| 09:21 | <hgl> | annevk, just saw issue #16 too on github too. thanks for the explanation. makes sense. |
| 09:34 | <smaug____> | annevk: what is your opinion on custom ctors ? |
| 09:35 | <annevk> | smaug____: I would love it if we could make them work as I think that's ultimately what developers want, a mapping between markup and JS objects |
| 09:35 | <annevk> | smaug____: and anything that doesn't expose the constructor will have a hard time competing with libraries that do manage to expose the constructor down the line |
| 09:36 | <smaug____> | right |
| 09:36 | <annevk> | (even harder if the JavaScript language evolves and adds features that depend on the constructor) |
| 09:36 | <smaug____> | and can you imagine what the spec would look like for this, for all sorts of edge cases? |
| 09:36 | <smaug____> | my worry is really in the spec level |
| 09:37 | <smaug____> | perhaps I worry too much |
| 09:37 | <annevk> | For the HTML parser it seems doable, since there's already a script-synchronization point. Although obviously it requires work and careful checks... |
| 09:38 | <annevk> | For cloneNode() and such I have not tried to figure out the implications yet. I know mutation events were hard, but I am convinced we could define how they work today if we needed to. That kind of complexity becomes more trivial with the algorithms we have written down today. |
| 09:39 | <annevk> | However, getting all the browser code in line... |
| 09:40 | <annevk> | Domenic has some kind of intermediate proposal that does not expose constructors for now (the browser still allocates the objects), but would allow them to be added in the future. Basically an element registry that only exposes a "get", not a "set"... |
| 09:40 | <annevk> | (And on top of that you'd keep lifecycle callbacks, perhaps generalized to all elements rather than just custom elements.) |
| 09:41 | <annevk> | I think that might be a nice way to ship custom elements without solving the hard problem, while keeping the door open for solving it later... |
| 09:44 | <smaug____> | so DOM spec, including Range, and anything using Range might need some tweaks. |
| 09:45 | <smaug____> | since suddenly after using certain range methods, the world around you might look totally different |
| 09:46 | <annevk> | Yeah, if we do custom constructors in v1 and not Domenic's way out we'd have to do that |
| 09:47 | <annevk> | Define cloning in a way that makes it clear it operates on a live tree and then define everything that needs to do cloning in terms of that somehow... |
| 11:48 | <annevk> | wanderview: hey, are you awake? |
| 11:49 | <annevk> | wanderview: I was wondering, for https://github.com/whatwg/fetch/issues/55 we wanted to introduce the "obsolete flag" |
| 11:49 | <annevk> | wanderview: however, couldn't we simply check if the used flag is set even if the body is null? |
| 11:49 | <annevk> | JakeA: ^^ |
| 11:59 | <JakeA> | annevk: so this problem is created by the transfer of body? If so, I agree with you, move the bodyUsed check before the if-body-not-null |
| 11:59 | <annevk> | yeah, it seems we only ever set the used flag if input's body was non-null to begin with |
| 12:00 | <annevk> | alright, I'll fix that |
| 12:00 | <annevk> | then next Wednesday we can worry about the rest :-) |
| 12:02 | <JakeA> | annevk: unfortunately i'm not going to make the Wednesday as I have a flight to Austin for TXJS, but the other people in the room know more than me about streams anyway |
| 12:02 | <annevk> | JakeA: I see, will you be there Monday? |
| 12:03 | <JakeA> | annevk: yep, and Tuesday |
| 12:03 | <annevk> | JakeA: I was kind of hoping we could cover cancelable stuff too |
| 12:03 | <annevk> | JakeA: for custom elements? |
| 12:03 | <annevk> | JakeA: especially if sleevi is there the security concerns around cancelation and streams in general |
| 12:03 | <JakeA> | annevk: I don't know much about custom elements, so dunno if it's worth me going to that meeting, but I'll be in the vicinity |
| 12:04 | <annevk> | JakeA: guess we'll mostly hang out Monday then; I'm in town Sunday too |
| 12:06 | <JakeA> | annevk: I arrive 14:35 on Sunday, so definately time for food & drinks Sunday evening if you're around |
| 12:06 | <annevk> | sounds good |
| 12:22 | <annevk> | So I was going to allow not teeing a request if you disable redirects and disable dialogs and such (through setting request's window to "no-window") but it mentions something about the Headers maybe changing... |
| 12:22 | <annevk> | I'm kind of glad I leave notes for myself, but they could be a little clearer |
| 12:23 | <annevk> | Ah okay, I think I figured it out... |
| 13:40 | <wanderview> | annevk: it was a rare morning and i indeed was asleep |
| 13:42 | <annevk> | nice |
| 14:48 | <wanderview> | annevk: is anyone working on wpt tests for the fetch spec yet? |
| 14:48 | <annevk> | wanderview: not that I know of |
| 14:48 | <annevk> | wanderview: I created some tests for nosniff... |
| 15:26 | <annevk> | Any volunteers for converting Fetch to bikeshed? |
| 15:27 | <philipj> | annevk: Not me, but whoever does it make sure to insert plenty of typos in the manual id=some-section that Bikeshed will ask you to write. TabAtkins ;) |
| 15:29 | <TabAtkins> | Fetch is only half as long as DOM, easy-peasy. |
| 15:29 | <TabAtkins> | Judging by my past performance, should only take a month. ^_^ |
| 15:43 | <Domenic> | Do Web IDL :P |
| 15:44 | <annevk> | IDL in bikeshed would be great |
| 15:44 | <annevk> | idl.spec.whatwg.org would be even better... |
| 15:46 | <philipj> | annevk: I see https://compat.spec.whatwg.org/ is now live, do you know who'll be editing it, for the most part? |
| 15:47 | <annevk> | miketaylr I think |
| 15:47 | <philipj> | cool |
| 15:47 | <philipj> | Is this the first step towards Gecko following Edge in pretending to be Chrome? |
| 15:47 | <miketaylr> | yeah, just trying to finish up some other junk this week before having more time |
| 15:47 | <miketaylr> | philipj: but contributions welcome ^_^ |
| 15:48 | <philipj> | miketaylr: I'll just file the bugs and tell you the commas are in the wrong places ;) |
| 15:48 | <miketaylr> | philipj: not so much pretending to be chrome, just trying to make the mobile web work |
| 15:48 | <miketaylr> | heh fair |
| 15:48 | <miketaylr> | the Asian web especially |
| 15:48 | <miketaylr> | Gecko does pretty well in the West, but in Japan and China things are... rough. |
| 15:49 | <philipj> | miketaylr: yeah, but so far both browsers who began adding some webkit things ended up either being Chromium (Opera) or pretending to be as well as possible (Edge) |
| 15:49 | <miketaylr> | yeah. |
| 15:49 | <miketaylr> | i remember when we tried the same thing at opera |
| 15:49 | <miketaylr> | starting with webkit prefixes... |
| 15:50 | <miketaylr> | iirc, for the same reasons: japan compat |
| 15:50 | <philipj> | I happen to think that would be great, chuck away all the prefixes except those webkit ones that are required, and forget about the IE and Gecko code paths in existing content |
| 15:50 | <philipj> | A lot of work though, and likely a rough transition :/ |
| 15:50 | <miketaylr> | to the extent possible i'd like to define supporting these things in terms of mappings to existing standard stuff |
| 15:51 | <philipj> | Plus nothing but hate from developers who will promise to block you forever |
| 15:51 | <miketaylr> | sort of like polyfills i guess |
| 15:51 | <miketaylr> | heh, i'm familiar with developer hate |
| 15:51 | <philipj> | miketaylr: some things can probably simply be defined in terms of JavaScript entirely, definitely webkitMatchesSelector could |
| 15:52 | <miketaylr> | yeah |
| 15:52 | <philipj> | but then an alias is trivial in prose too |
| 15:52 | <philipj> | In any event, best of luck, you won't get any hate from me, unless you put the commas in the wrong places :) |
| 15:52 | <miketaylr> | hehe, thanks |
| 16:27 | <Domenic> | So basically T[] is used in HTML and CSSOM |
| 16:27 | <Domenic> | Better than I expected |
| 17:05 | <annevk> | Hmm, I wonder where we documented why mutation events are problematic |
| 17:22 | <annevk> | https://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html is it btw |
| 17:30 | <Domenic> | execCommand() woof |
| 17:31 | <Domenic> | I guess that's subsumed under editing though which i already knew about |
| 17:31 | <annevk> | wanderview: so technically 2.2 'request's mode is not "no-cors" and response's type is "opaque".' is a bit of a hack |
| 17:32 | <annevk> | wanderview: if APIs truly worked on the response (and knew not to poke at the internal response), they would basically fail for those too |
| 17:33 | <annevk> | wanderview: actually, I guess it's a nice convenience since it gives the API less response types to distinguish, meh |
| 17:33 | <annevk> | Is that still at https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html these days? |
| 17:34 | <annevk> | No love for that... |
| 17:35 | <Domenic> | It's got to be somewhere else... |
| 17:36 | <annevk> | https://w3c.github.io/editing/ has pointers |
| 17:37 | <Domenic> | Ah this is the evolution thereof https://w3c.github.io/editing/execCommand.html |
| 17:37 | <annevk> | looks pretty bad this arbitrary splitting on features |
| 17:37 | <Domenic> | Meh |
| 17:38 | <annevk> | I keep trying to tell people to focus on the model, but... |
| 17:41 | <annevk> | E.g. the beforeinput/input thing is completely unclear about how these events get triggered and how that relates to the event loop and other things going on |
| 17:54 | <annevk> | "Made with love by the libuv team. — libuv is for C projects that miss the joy of javascript callback hell." |
| 18:00 | <Domenic> | haha never seen that before |
| 18:02 | <TabAtkins> | Ugh, doing WebIDL is on my list, yeah. |
| 18:02 | <TabAtkins> | Kinda considering taking a week or two off of work and just spending a few hours a day doing Bikeshed things. |
| 18:02 | <TabAtkins> | And the rest video games. |
| 18:08 | <TabAtkins> | Also: considering auto-adding the commit id to a <meta> when you generate, if you do so from a git repo. Makes it easier to look up historical revisions without having to do sleuthing to try and match up the commit. Good/bad idea? |
| 18:10 | <Domenic> | +1 |
| 18:10 | <Domenic> | Already doing similar things for streams |
| 18:10 | <TabAtkins> | via a custom macro or something? |
| 18:10 | <Domenic> | Yeah, https://github.com/whatwg/streams/blob/master/deploy.sh#L52-L53 |
| 18:30 | <annevk> | There's still some references issues with bikeshed |
| 18:30 | <annevk> | But overall I like it better than Anolis |
| 18:31 | <Ms2ger> | It helps that it's maintained :) |
| 18:36 | <TabAtkins> | annevk: Yeah, I'm still not 100% happy with my handling of IDL, but I'm gradually iterating it towards goodness. |
| 18:36 | <annevk> | TabAtkins: also WHATWG vs W3C normative references is a bit of a pain |
| 18:36 | <TabAtkins> | Ugh, I know. |
| 18:36 | <annevk> | TabAtkins: but maybe that's mostly specref |
| 18:37 | <TabAtkins> | Yeah, it's specref. Tobie's trying to be even-handed. |
| 18:37 | <TabAtkins> | Which is frustrating when it's wrong. ^_^ |
| 18:37 | <TabAtkins> | But then I have mikewest on the other side preferring W3C refs for something or other, which I've so far mostly ignored. |
| 18:38 | <annevk> | mkwst: really? :/ |
| 18:38 | <annevk> | I am disappoint |
| 18:38 | <philipj> | heretic! |
| 18:39 | <jsbell> | TabAtkins: to get a "webapps" bikeshed group/template... send you a PR or ...? |
| 18:40 | <TabAtkins> | jsbell: Yup. Probably just fork off of the csswg ones or something. |
| 18:40 | <jsbell> | kk. Don't hold your breath tho. |
| 18:41 | <TabAtkins> | No skin off my nose. |
| 18:43 | <TabAtkins> | heycam|away: "behahvior" |
| 21:36 | <Domenic> | hober: othermaciej: any chance we can get you guys to comment on https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0159.html ? |
| 21:47 | <hober> | Domenic: ok |
| 21:51 | <hober> | Domenic: I don't think our position has changed much since https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0225.html (see II.B. & II.C. in that email) |
| 21:52 | <Domenic> | hober: OK, got it. Note that upgrading and synchronous constructors are somewhat orthogonal. But if you guys think sync constructors are OK, could you maybe help me with https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0180.html ? |
| 21:55 | <hober> | Domenic: i'll take a look |
| 22:05 | <othermaciej> | Domenic: we'll look at it more closely and we'll send an update about our issue stances in general (maybe not til Monday in the worst case but def before the meeting) |
| 22:05 | <Domenic> | othermaciej: awesome, thank you. |
| 23:22 | <danbeam> | what would one expect from docFrag.querySelector(':root')? |
| 23:25 | <danbeam> | css selectors 4 says "an element that is the root of the document" |
| 23:25 | <danbeam> | does a DocumentFragment count? :) |
| 23:44 | <TabAtkins> | danbeam: DocumentFragment isn't an element. |
| 23:44 | <TabAtkins> | So the answer is null, or whatever querySelector returns when it doesn't find anything. |