| 09:06 | <Jake Archibald> | annevk: I addressed the nits on https://github.com/whatwg/dom/pull/1170 - is it good to go? |
| 10:34 | <annevk> | Jake Archibald: I can't land it due to CI errors (and there's a newline that's being eaten, but I can fix that); I can look into those later today I suspect as I guess they're not your fault |
| 10:50 | <Jake Archibald> | annevk: huh, I don't see the newline thing. Yeah, the CI error is LINK ERROR: Ambiguous for-less link for 'descendant' which is unrelated to my change. |
| 11:37 | <annevk> | Jake Archibald: the heading used to have two preceding newlines unless I'm missing something |
| 11:42 | <Jake Archibald> | ohhhhhhh |
| 11:42 | <Jake Archibald> | I see now |
| 11:42 | <Jake Archibald> | fixed |
| 12:18 | <annevk> | css2 claiming all the tree in the global scope terms while it should probably reuse the concepts of DOM is unfortunate |
| 12:18 | <annevk> | Fortunately adding for=tree isn't a lot of work, but still |
| 12:44 | <annevk> | Noam Rosenthal: I gave it a pass, it didn't seem like all existing feedback was addressed though |
| 12:46 | <Noam Rosenthal> | annevk: oh I thought it was but perhaps I missed something. There were auto-commits from github that weren't processed for some reason earlier so perhaps it's that. Thanks! |
| 12:47 | <annevk> | Inline comments? Maybe Fetch reached the point where it's too big for those? Those certainly always fail for HTML. |
| 12:47 | <Noam Rosenthal> | annevk: regarding "fetching" or "obtaining", none of them represent "the response body is completely downloaded" in laymen terms. Other suggestion? |
| 12:49 | <annevk> | has been fully obtained? |
| 12:49 | <Noam Rosenthal> | ok will give that a go |
| 12:49 | <annevk> | I'll fix the CI error, I guess that might be in part why you switched the element ref |
| 12:52 | <bkardell> | css2 claiming all the tree in the global scope terms while it should probably reuse the concepts of DOM is unfortunate |
| 12:54 | <annevk> | bkardell: whatwg/dom CI revealing to me those conflicts exist |
| 12:54 | <annevk> | Prolly due to Reffy doing things slightly differently |
| 13:01 | <annevk> | TabAtkins: https://github.com/speced/bikeshed/commit/be9d81bf44e171abf9895b555844677cb451f07d resulted in FATAL ERROR: Spurious / in <a>. for whatwg/fetch |
| 13:01 | <annevk> | No context |
| 13:01 | <annevk> | I guess I'll file an issue as I'm not going to try to find that |
| 13:03 | <annevk> | In case anyone else is hit by this: https://github.com/speced/bikeshed/issues/2498 |
| 13:40 | <annevk> | dlrobertson: do you think you can look at those two blob: URL range PRs this week? |
| 13:41 | <dlrobertson> | annevk: looking at the wpt PR now, sorry I didn't get to them yesterday |
| 13:46 | <annevk> | dlrobertson: that's fine, I just pushed some more changes so... |
| 15:22 | <TabAtkins> | annevk: The error messaging is fixed, but there is one new issue that'll affect this spec. I've switched Markdown's backtick-code-span syntax to being part of Bikeshed's core syntax for now (alongside the backtick-code-blocks, which are already core syntax), and fetch uses those backticks a good bit. (As does Infra and anyone using byte sequences using Infra syntax.) :/ Wonder if I should revert that and go back to it being gated behind the markdown shorthand flag. |
| 15:24 | <annevk> | TabAtkins: I think I'd prefer that; I'll take a look at the current output |
| 15:24 | <TabAtkins> | You've got some dfns that are wrapped in backticks, at least |
| 15:25 | <annevk> | TabAtkins: yeah, getting errors for those because MDN references can no longer be matched up |
| 15:25 | <TabAtkins> | yup |
| 15:26 | <TabAtkins> | okay, in a meeting right now but i'll back that out today. i'm doing something else similarly wrong but it's much less likely to catch anything by accident. |
| 15:27 | <annevk> | Thanks, I'll look at some non-Fetch stuff |
| 16:38 | <Ms2ger> | TabAtkins: is the above related to https://github.com/WebAssembly/spec/pull/1626/files ? |
| 16:55 | <TabAtkins> | the recent commit is indeed responsible for those, yes. |
| 18:18 | <Sam Sneddon [:gsnedders]> | css2 claiming all the tree in the global scope terms while it should probably reuse the concepts of DOM is unfortunate |
| 18:26 | <Sam Sneddon [:gsnedders]> | zcorpan: given it relates to your HTML PR, https://github.com/html5lib/html5lib-tests/issues/156 |
| 18:26 | <Sam Sneddon [:gsnedders]> | (I presume the answer is "the PR shouldn't have landed in html5lib-tests) |
| 18:44 | <annevk> | Sam Sneddon [:gsnedders]: well, the problem is really getting those tests synced with WPT, that was the main thing blocking Domenic's PR; not sure if we made progress on that? Also, if we did, I guess we might have to briefly look at the HTML <search> PR again to see everything is still correct |
| 21:19 | <TabAtkins> | We really do need to drop most of CSS2. I wasn't capable of intervening the last time we tried it a few years ago, but we should push on it again. I don't recall what the deal was that caused a lot of stuff to need to be reverted. |
| 21:19 | <TabAtkins> | I really do not want to do significant edits to CSS2 to make it play well in the ecosystem until we get all the replaced bits removed. |
| 23:38 | <Sam Sneddon [:gsnedders]> | IIRC, there were three main options: do we just add informative notes "you may want to see [later level]", do we just drop everything from CSS 2 and make them undefined, or do we drop everything from CSS 2 and replace them with references to later levels (maybe, e.g., restricting the value space of a property to what 2.1 defines, to maintain some notion of levels). There were questions about ramifications of the latter two options under the patent policy and the existing IPR commitments. And I just haven't had the time/energy to try and figure this out, we have so many contradictory resolutions now. |
| 23:38 | <Sam Sneddon [:gsnedders]> | Like really we need to decide "what are we doing about lower levels" in general, and hopefully what to do with CSS 2 becomes apparent from that. |