| 08:34 | <jgraham> | gsnedders: username? |
| 09:08 | <annevk> | The concept of <a>term</a> having to be rewritten as <a for=/>term</a> has also caused a ton of issues in Fetch's conversion |
| 09:08 | <annevk> | As the person that did the conversion was probably not aware of how that worked |
| 09:09 | <annevk> | I didn't really discover it until later unfortunately |
| 09:23 | <annevk> | jgraham: moving wpt/cors/ into wpt/fetch/cors, can we do that and avoid breaking external links? |
| 09:29 | <annevk> | foolip: https://github.com/whatwg/encoding/issues/75#issuecomment-257148606 |
| 09:36 | <annevk> | jgraham: how often does Mozilla push? |
| 09:36 | <annevk> | jgraham: to wpt? https://github.com/w3c/web-platform-tests/pull/4090 could use a clarifying comment / merge / closure |
| 09:40 | <Ms2ger> | Which reminds me, I should do a servo sync |
| 09:42 | <annevk> | Ms2ger: if you know the answer please reply there btw |
| 09:42 | <Ms2ger> | "When jgraham has time" |
| 09:43 | <annevk> | Ms2ger: does it cause jgraham issues if I just merge that one too? |
| 09:44 | <Ms2ger> | Some, yes |
| 09:44 | <annevk> | Hmm okay, I guess I'll wait for jgraham to come online then |
| 09:44 | <Ms2ger> | Maybe wait to see if he answers today |
| 09:50 | <jgraham> | Answers what? |
| 09:51 | <annevk> | jgraham: see backlog? |
| 09:51 | <annevk> | jgraham: https://github.com/w3c/web-platform-tests/pull/4090 in particular |
| 09:51 | <annevk> | jgraham: (though I'm still curious about moving /cors into /fetch/cors at some point too) |
| 09:52 | <yoav> | annevk: Hey! I'm trying to see if the concept of "resource type matching" is defined in Fetch, and failing to find it. When I say "resource type matching" I'm talking about the concept of avoid to reuse the same resource when e.g. a request for same URL is initiated by e.g. <img> and <script> (but allowing reuse for <img> and CSS background image). Is that concept defined in Fetch (or elsewhere)? |
| 09:52 | <jgraham> | Moving tests has the downside that our sync infrastructure isn't clever enough to automatically move expectation data |
| 09:53 | <annevk> | yoav: is that even a thing? |
| 09:53 | <jgraham> | So it's OK if all the tests are enabled because it will just be recreated, but if some are disabled it can cause problems |
| 09:53 | <yoav> | annevk: It's a thing in Blink's loading code |
| 09:53 | <yoav> | I'm hoping it's a thing in other browsers as well |
| 09:53 | <annevk> | yoav: for <img> there's a thing defined in HTML |
| 09:54 | <annevk> | yoav: I'm not aware of anything for <script> |
| 09:54 | <annevk> | yoav: and the thing for <img> likely needs to be generalized in some way and other specifications need to invoke it |
| 09:54 | <yoav> | hmm |
| 09:55 | <annevk> | yoav: basically someone needs to generalize the <img> loading algorithm and get CSS et al to invoke it |
| 09:57 | <annevk> | yoav: the image thing is called "list of available images" |
| 09:57 | <annevk> | yoav: it's rather messy and I think needed for compat |
| 09:59 | <yoav> | annevk: I agree we need to expand the definition of "list of available images" to more generally define resource reuse inside the renderer (e.g. Blink/WebKit's MemoryCache). I guess that as part of that, we'd need to define the concept of not reusing resources of different types (or different request destination) |
| 09:59 | <yoav> | I was hoping something like that is defined (I want to better explain `as` in the preload spec, to ensure compat) |
| 10:00 | <annevk> | yoav: if you have some cycles it'd be great to see image loading getting some more refactoring |
| 10:01 | <yoav> | I might have some time in a few weeks. I'll see if I can squeeze that in |
| 10:10 | <foolip> | annevk: replied |
| 10:13 | <annevk> | ta |
| 10:15 | <yoav> | mkwst_: I'm looking at https://w3c.github.io/webappsec-csp/#effective-directive-for-a-request and wondering why it's not a simple mapping from destination to directive? (other then question marks) |
| 10:15 | <yoav> | Is there a particular reason for that? |
| 10:17 | <yoav> | I'm trying to add some language that would tighten what `as` does, and since `as` is a destination value, deriving directive just from destination would make it easier |
| 10:21 | <yoav> | I guess I could define it all in terms of fetch and CSP would just derive from that... |
| 10:29 | <tobie> | Looking to tighten up the language of the generic sensor spec to make the intervals at which events need to fired more explicit. It the Timer section of the HTML spec a good basis for this? Or are there other things I should be looking at instead? |
| 10:30 | <tobie> | *Is |
| 10:31 | <tobie> | By "good basis" I mean "good source of inspiration." |
| 10:56 | <annevk> | tobie: how do I link to an algorithm? |
| 10:56 | <annevk> | tobie: e.g., "convert an ECMAScript value to ByteString" |
| 10:58 | <tobie> | TabAtkins: ^ (annevk: afaik you currently cannot) |
| 10:59 | <annevk> | I see |
| 10:59 | <annevk> | Fetch uses that algorithm somewhere |
| 11:11 | <tobie> | annevk: you can add a dfn inside of algorithm and algorithm uses it as its name. |
| 11:36 | <tobie> | Mmm. Maybe I can add dfn and export attributes to that div. |
| 11:38 | <annevk> | tobie: per bikeshed docs you can only export <hN> and <dfn> |
| 11:39 | <tobie> | Yeah. |
| 12:08 | <annevk> | Hmm, you can easily deduplicate contacts, but not mark contacts as not duplicatable |
| 12:44 | <gsnedders> | jgraham: gsnedders |
| 12:45 | <Ms2ger> | gsnedders, jgraham |
| 12:47 | <jgraham> | Ms2ger: Ms2ger |
| 12:48 | <gsnedders> | Ms2ger: jgraham |
| 12:53 | <gsnedders> | jgraham: I meant for readthedocs, if you'd forgotten |
| 12:58 | <jgraham> | gsnedders: I had not |
| 12:59 | <jgraham> | gsnedders: Done |
| 16:33 | <gsnedders> | Seems with new charter everyone has to rejoin the Web Platform WG if interested. |
| 16:33 | <gsnedders> | http://www.w3.org/mid/b4b7a03d-3859-8987-d390-2496b5ede2c3⊙wo |
| 18:02 | <jsbell_> | TabAtkins: re: Bikeshed: what's the best way for me to define DOMStringList in IndexedDB? Bikeshed now wants the links to be disambiguated, pointing at the dead entry in DOM |
| 18:02 | <KiChjang> | any news in whatwg.org? |
| 18:02 | <KiChjang> | it's still down for me |
| 18:02 | <KiChjang> | oh nvm, my internet was just slow |
| 18:03 | <Domenic> | jsbell_: this seems like a case for spec= or link-defaults |
| 18:03 | <Domenic> | I guess DOM should get updated though |
| 18:03 | <jsbell_> | Domenic: maybe, but this is for spec internal links, i.e. "ignore DOM's entry, use mine"... |
| 18:03 | <Domenic> | jsbell_: link-defaults then |
| 18:04 | <Domenic> | well, hmm, I don't know how to use link-defaults to point to the spec itself |
| 18:04 | <jsbell_> | Domenic: right :) |
| 18:04 | <jsbell_> | And I don't want to ignore DOM entirely with pre class='ignored-specs' |
| 18:05 | <Domenic> | I think you're supposed to use for=/ |
| 18:05 | <Domenic> | You can also add `Assume Explicit For: yes` to the metadata block |
| 18:06 | <Domenic> | which will make <a>foo</a> ~ <a for=/>foo</a> |
| 18:16 | <annevk> | jsbell_: I mean if it's going to be defined I can just remove it from DOM, right? |
| 18:16 | <jsbell_> | Domenic: for=/ ends up linking to DOM though. |
| 18:17 | <Domenic> | jsbell_: did you update bikeshed to the very very latest? there have been recent changes |
| 18:17 | <jsbell_> | annevk: that would also work |
| 18:17 | <jsbell_> | Domenic: about an hour ago |
| 18:17 | <Domenic> | jsbell_: well then yeah maybe a bikeshed bug/confusion :( |
| 18:19 | <jsbell_> | Hard to fault Bikeshed too much here since we shouldn't have it defined in two places. (ODR for specs: undefined behavior!) But this will probably come up again, e.g when experimenting with replacing a spec. |
| 18:19 | <Domenic> | I mean it's common for <dfn>s though. For interfaces it's a bug yeah. |
| 18:20 | <Domenic> | I was pretty sure this all got straightened out Friday though so I'm surprised it isn't working here |
| 18:20 | <Domenic> | I think maybe the oversight is just not knowing how to use link-defaults to default to yourself |
| 18:32 | <Domenic> | Anyone want to review this? /cc annevk since it's about trusted events. https://github.com/w3c/web-platform-tests/pull/4025 |
| 18:34 | <annevk> | jsbell_: so we can't remove DOMStringList? |
| 18:34 | <annevk> | jsbell_: should we just define it in DOM then? |
| 18:35 | <jsbell_> | annevk: I think we'll be able to replace it with FrozenArrayWithContains<> but no one has spent the time to try doing so yet |
| 18:35 | <jsbell_> | annevk: so pending that I went ahead and spec'd reality in the only spec that needs it. |
| 18:36 | <Domenic> | Yeah keeping it in IDB seems better than in DOM |
| 18:41 | <TabAtkins> | annevk, tobie: All algorithms should have a <dfn> anyway. If that doesn't exist, bug the spec author. |
| 18:42 | <TabAtkins> | jsbell_: What's your use-case? You're *writing* IndexedDB, have a definition for something, and want to point to it? That should work automatically. Or are you writing some *other* spec, and want to point to some non-DOM DOMStringList? |
| 18:43 | <annevk> | TabAtkins: DOM has DOMStringList as "obsolete" interface dfn, causes a clash |
| 18:43 | <jsbell_> | TabAtkins: I'm writing Indexed DB, have a definition for DOMStringList (standard IDL block, nothing fancy), and am getting ambiguous linking errors; if I use {{/DOMStringList}} it links to DOM's DSL |
| 18:44 | <TabAtkins> | That's... weird. Send me latest file so I can debug? |
| 18:44 | <TabAtkins> | Interfaces in IDL blocks should always dfn themselves unless they're partial. |
| 18:44 | <jsbell_> | TabAtkins: up on https://github.com/w3c/IndexedDB - I pushed anyway |
| 18:44 | <TabAtkins> | kk, one sec then |
| 18:44 | <jsbell_> | (I cleaned up all the other amb errors, which were legit) |
| 18:45 | <annevk> | TabAtkins: I was wondering if there's some way to have legacy IDs for enums and such |
| 18:45 | <annevk> | TabAtkins: bikeshed uses enumdef-name, whereas anolis uses just name |
| 18:46 | <annevk> | TabAtkins: currently Fetch has some empty <span>'s sprinkled with IDs on them |
| 18:46 | <TabAtkins> | annevk: There is - https://tabatkins.github.io/bikeshed/#metadata-translate-ids |
| 18:46 | <annevk> | TabAtkins: shit, I wish I had asked before we put this hack in, but I guess it's not too late |
| 18:47 | <TabAtkins> | ^_^ |
| 18:49 | <TabAtkins> | jsbell_: Found the problem - you have a markup error. ^_^ |
| 18:49 | <TabAtkins> | Close your <div dfn-for=request> element. |
| 18:50 | TabAtkins | needs to put more information into that ambiguous-for error. |
| 18:50 | <Domenic> | markup errors, the worst |
| 18:51 | <TabAtkins> | Confusing linking errors are *often* caused by something accidentally nesting most of the page. |
| 18:52 | <TabAtkins> | Luckily easy to spot, since Bikeshed's use of Markdown encourages flat documents. |
| 18:53 | <jsbell_> | TabAtkins: whee, checking... |
| 18:56 | <TabAtkins> | jsbell_: In the future, use indentation when nesting, to remind you that you need to close something. ^_^ |
| 19:00 | <annevk> | TabAtkins: https://github.com/whatwg/fetch/commit/a939a20dd93654362c4b95b653ecf8c1d83624ee very clean |
| 19:00 | <TabAtkins> | I'll never stop loving "typedefdef" |
| 19:08 | <jsbell_> | TabAtkins: yep, that did it; thanks! (brief RL distraction) |
| 19:16 | <Domenic> | annevk: the self-links work, woo! |
| 19:18 | <annevk> | \o/ |
| 19:46 | <tobie> | TabAtkins: so what's the non-boolean algorithm for, then? |
| 19:47 | <tobie> | TabAtkins: the non-boolean algorithm *attribute* |
| 19:58 | <TabAtkins> | tobie: Currently, only making your error messages better. |
| 19:59 | <tobie> | TabAtkins: right--my question was more around the fact that you have two competing ways to name the same thing |
| 19:59 | <TabAtkins> | Yes, I should probably start requiring that your manually-specified algorithm name be the same as the linking texts of one of the <dfn>s inside the algorithm container. |
| 20:00 | <tobie> | TabAtkins: luckily I don't have any of those issues |
| 20:01 | <tobie> | TabAtkins: I'm just using the boolean version when a dfn's enclosed. |
| 20:01 | <TabAtkins> | Yeah, that's reasonable. |
| 20:01 | <tobie> | TabAtkins: would it be possible to use a for attribute to point to an external dfn? |
| 20:02 | <TabAtkins> | for attributes aren't checked in any way whatsoever. They're a meaningless opaque string as far as I care. |
| 20:02 | <TabAtkins> | At some point I should start caring about that, but not for a while yet. It's expensive and difficult. |
| 20:03 | <tobie> | TabAtkins: oh, I meant a for attribute like label has. I forgot you were also using "for" for something else. |
| 20:04 | <tobie> | TabAtkins: Basically, I have case where I have <hn dfn export>to foo a bar</hn><div algorithm="to foo a bar">...</div> |
| 20:05 | <tobie> | TabAtkins: e.g.: https://heycam.github.io/webidl/#create-sequence-from-iterable |
| 20:05 | <TabAtkins> | You can put `algorithm` on a heading! |
| 20:05 | <TabAtkins> | Oh wait can you. |
| 20:05 | TabAtkins | goes to check. |
| 20:14 | <rniwa> | Domenic: maybe you can merge https://github.com/w3c/web-platform-tests/pull/3968? |
| 20:14 | <TabAtkins> | tobie: Anyway, yes you can; it gives the same var-checking benefits as putting it on a container. |
| 20:15 | <rniwa> | zcorpan: did you see my reply on https://github.com/w3c/web-platform-tests/pull/3968 ? |
| 20:15 | <TabAtkins> | It looks like I never infer an algorithm name from a heading-algo right now. I should infer it from the heading if it's also a definition. |
| 20:15 | <tobie> | TabAtkins: for all the content that follows? Neat. |
| 20:16 | <TabAtkins> | Yeah, when looking for a var's algorithm, I check "relevant headings" if there's no algo container. |
| 20:16 | <tobie> | TabAtkins: Does it wrap it up with the same style it regular algos? |
| 20:16 | <TabAtkins> | No. |
| 20:17 | <TabAtkins> | Question for anyone using Bikeshed: If I added a "Max ToC Level" metadata (for automatically excluding deeply-nested headings from the ToC), is "just the top-level stuff" level 1 (because first level in the ToC) or level 2 (because <h2>)? |
| 20:30 | <tobie> | TabAtkins: well, I really wanted to have both my cake and also eat it. |
| 20:40 | <tobie> | TabAtkins: call it Max ToC depth and start numbering with 1 |
| 20:40 | <TabAtkins> | Brilliant. |
| 23:02 | <tobie> | Did I completely dream up the existence of a "fire a simple event" construct? |
| 23:03 | <tobie> | I can't seem to find this anywhere. |
| 23:15 | <Domenic> | tobie: it was removed in favor of "fire an event" |
| 23:15 | <Domenic> | Probably should have been some kind of announcement |
| 23:17 | <tobie> | Domenic: at least I'm not making things up. |
| 23:37 | <Domenic> | rniwa: any thoughts on https://github.com/whatwg/html/pull/1936 ? |
| 23:38 | <rniwa> | Domenic: what is this feature? |
| 23:38 | <Domenic> | rniwa: it is a proposal to add promises to the DOM for various one-time events, starting with a few promises on document for common initialization events (interactive, content loaded, and the load event) |
| 23:39 | <rniwa> | oh I see |
| 23:39 | <rniwa> | Domenic: I'm not sure if adding three new properties on document is a good idea... |
| 23:39 | <Domenic> | rniwa: the concern being web compat? We'd made them [Unscopable] |
| 23:40 | <rniwa> | Domenic: How about something like document.whenReady('interactive') ? |
| 23:40 | <Domenic> | rniwa: that sounds pretty reasonable, but what is the concern concretely? |
| 23:41 | <rniwa> | Domenic: using up more names on document |
| 23:41 | <rniwa> | Domenic: e.g. document.interactive seems like something that could be used for something else |
| 23:41 | <Domenic> | Hmm :-/ |
| 23:41 | <rniwa> | like hypothetical "Interactive API" |
| 23:41 | <rniwa> | not sure what it would do |
| 23:41 | <Domenic> | We'd usually put that on navigator.interactive |
| 23:41 | <rniwa> | Domenic: maybe |
| 23:42 | <Domenic> | I dunno, I think it'd be a win if we can get a pattern of domNode.simpleStateName.then(...) going |
| 23:42 | <Domenic> | e.g. imgEl.loaded.then(...) |
| 23:42 | <Domenic> | and so on |
| 23:42 | <rniwa> | Domenic: I don't think that's much better than |
| 23:42 | <rniwa> | Domenic: image.whenReady('loaded').then(~) |
| 23:43 | <rniwa> | Domenic: or even image.when('loaded').then(~) |
| 23:43 | <TabAtkins> | That's 11 chars more, plus some shift presses. :/ |
| 23:43 | <rniwa> | Domenic: then we can add even more types |
| 23:43 | <Domenic> | Sure, not too much. But it's a little better, and multiplied by how often we'd expect this to be used... |
| 23:43 | <rniwa> | Domenic: e.g. image.when('decoded').then(~) |
| 23:43 | <Domenic> | And I think keeping it open-ended is a bit problematic because it kind of implies we're creating this other parallel event system |
| 23:43 | <Domenic> | Instead of just special-casing for certain very common one-and-done things |
| 23:44 | <rniwa> | Domenic: possibly |
| 23:44 | <Domenic> | We have some precedent for these, e.g. stream.closed.then(...) and fontFaceSet.ready.then(...) |
| 23:44 | <rniwa> | Domenic: those are on stream & fontFaceSet |
| 23:44 | <Domenic> | yeah just saying as part of the web platform we have some precedent for obj.stateName.then(...) |
| 23:44 | <rniwa> | Domenic: which are rather "exotic" ojbect |
| 23:44 | <rniwa> | Domenic: I know that |
| 23:44 | <rniwa> | Domenic: I'm really concerned about document.interative |
| 23:45 | <rniwa> | Domenic: document.loaded seems fine |
| 23:45 | <rniwa> | Domenic: so is document.contentLoaded |
| 23:45 | <rniwa> | Domenic: maybe document.interactiveReady? or document.interactionReady |
| 23:45 | <Domenic> | rniwa: hmm OK yeah we can focus on that in particular. The reason for "interactive" was because that's what the readystate changes to |
| 23:45 | <Domenic> | But it is a bit of a strange one |
| 23:46 | <Domenic> | It's also nice for it to be short since it happens soonest so authors should probably use it more than the others |
| 23:46 | <rniwa> | Domenic: yeah. |
| 23:46 | <rniwa> | Domenic: document.readyToInteractive.then(~) might be okay too |
| 23:46 | <Domenic> | I guess I just wish I knew what we were reserving document.interactive for. |
| 23:46 | <rniwa> | Domenic: I can't say |
| 23:46 | <Domenic> | It is a nice name, bhis seems like probably the best possible use of it. |
| 23:46 | <rniwa> | Domenic: but in general, each name should be as specific as possible |
| 23:46 | <Domenic> | s/bhis/but this/ |
| 23:48 | <rniwa> | Domenic: you may feel that way but are you sure you'll feel the same way in 50 years? |
| 23:48 | <rniwa> | that way now* |
| 23:48 | <Domenic> | rniwa: pretty sure, yeah :) |
| 23:48 | <Domenic> | Insofar as I feel confident about anything I work on lasting 50 years. |
| 23:48 | <Domenic> | Well, I'll leave a note on the thread for us to try to brainstorm alternate names. Would you say WebKit supports the other two at least? :) |
| 23:50 | <rniwa> | Domenic: well, it depends on what those alternative names for "interactive" would be |
| 23:51 | <rniwa> | Domenic: but really, I'm quite indifferent about this API |
| 23:51 | <Domenic> | hmm OK fair. |
| 23:51 | <rniwa> | Domenic: I don't know what others in the WebKit team feels about it |
| 23:51 | <rniwa> | Domenic: but in general, we're a lot more cautious than other vendors when it comes to adding new APIs |
| 23:51 | <Domenic> | that's fair. We can try it out in Gecko and Blink first and let you know how it goes. |
| 23:56 | <rniwa> | Domenic: anyways, i'm done implementing custom elements in WebKit now |
| 23:57 | <Domenic> | rniwa: \o/! |
| 23:57 | <rniwa> | Domenic: it should be fully spec compliant and all that in STP17 |