| 00:09 | <othermaciej> | So I just filed this issue but I realized I can't possibly be the first person to raise this: https://github.com/whatwg/streams/issues/732 |
| 00:10 | <othermaciej> | What is the deal with the pseudo-ECMAScript interface definitions in Streams? |
| 00:11 | <MikeSmith> | [trigger sound of can of worms opening] |
| 00:13 | <MikeSmith> | ah Domenic already responded there |
| 00:17 | <othermaciej> | yep |
| 01:20 | <weinig> | Domenic: I thought of one other question :). Why can’t ReturnTypes have extended attributes? I mean, they can, if you use a typedef, but there is no direct syntax to associate an extended attribute with an operation’s return type |
| 01:21 | <Domenic> | Hmm, that might just be an oversight... |
| 01:22 | <Domenic> | Especially with the typedef thing |
| 01:22 | <weinig> | want me to file an issue? |
| 01:22 | <Domenic> | Yeah, that'd be great :) |
| 01:22 | <weinig> | k, thanks |
| 01:23 | <Domenic> | Although, this might be intentional, as bz says in https://github.com/heycam/webidl/pull/286#issuecomment-275307976 " ReturnType definitely shouldn't have attributes. " I don't quite understand why though, and we should if nothing else close the typedef loophole |
| 03:50 | <domfarolino> | Domenic: Just a heads up regarding my inactivity on console - lots of exams and school work going on as the semester comes to a close - will be resuming as more time is available |
| 06:53 | <KiChjang> | is web.archive.org the only way to get a previous version of a spec? |
| 07:00 | <MikeSmith> | annevk: in Fetch terms does a 50x result in a “network error”? |
| 07:01 | <MikeSmith> | KiChjang: yes basically, though https://platform.html5.org/history/ has archived copies of some |
| 07:01 | <MikeSmith> | but just for the HTML spec |
| 07:09 | <annevk> | MikeSmith: what is a 50x result?, is that like a 10x developer? |
| 07:09 | <annevk> | MikeSmith: oh wait, it's a status code, no it doesn't |
| 07:12 | <MikeSmith> | annevk: yeah specifically meant a 504 |
| 07:13 | <MikeSmith> | if a server responds to a fetch with a 504 is there any way to get to the response? |
| 07:13 | <MikeSmith> | is CORS not relevant in that case? |
| 07:14 | <annevk> | MikeSmith: CORS is relevant if we're talking about a cross-origin request |
| 07:14 | <MikeSmith> | yeah cross-origin |
| 07:14 | <annevk> | MikeSmith: in that case the 504 also needs to include the relevant CORS headers |
| 07:14 | <MikeSmith> | OK so if the server sends CORS headers, can you get the status message from teh response? |
| 07:15 | <MikeSmith> | doesn’t the fetch hit the .catch()? |
| 07:15 | <annevk> | MikeSmith: yes and no |
| 07:16 | <annevk> | MikeSmith: it might be tricky to configure the server to send CORS headers for 5xx though |
| 07:16 | <MikeSmith> | OK |
| 07:17 | <MikeSmith> | well if it does send CORS headers can you get to the status code/message somehow from JavaScript? |
| 07:17 | <MikeSmith> | context is https://stackoverflow.com/questions/43361789/fetch-api-how-to-get-response-body-in-catch/43361959#43361959 |
| 07:18 | <MikeSmith> | so feel free to answer there, or comment to correct anything |
| 07:19 | <MikeSmith> | the OP just has the typical problem of wanting to get specific details from their JavaScript code about why exactly the fetch failed |
| 07:20 | <MikeSmith> | (maybe this is already answered well somewhere else at stackoverflow) |
| 07:21 | <annevk> | I added an answer |
| 07:21 | MikeSmith | goes back to working on PRs |
| 07:21 | <MikeSmith> | ah cool |
| 07:21 | <MikeSmith> | thanks |
| 07:21 | <MikeSmith> | looking now |
| 07:27 | <MikeSmith> | cheers |
| 07:27 | <MikeSmith> | restored my answer, which I think is still correct |
| 07:28 | <MikeSmith> | but if not lemme know, or comment there |
| 07:29 | <annevk> | MikeSmith: yeah, I think you were correct, I decided to leave a new reply since yours became a little confusing with the strike through and comments |
| 07:30 | <MikeSmith> | at some point I want to mine some cors/fetch answers out from stackoverflow and use them to update the related MDN docs |
| 07:30 | <MikeSmith> | annevk: yeah that’s better, and shorter, and clearer |
| 07:30 | <MikeSmith> | I have a hard time writing succinctly |
| 07:31 | <MikeSmith> | anyway I 'as long as |
| 07:31 | <MikeSmith> | oofs |
| 07:32 | <MikeSmith> | anyway I’m happy as long as somebody ends up with an understanding that helps them |
| 07:32 | <MikeSmith> | so many people show up on stackoverflow so very confused about CORS and often really frustrated |
| 07:32 | <MikeSmith> | and very confused about fetch as well |
| 07:33 | <MikeSmith> | they are often accustomed to using jQuery $.ajax or (nowadays) axios or something, and they are confused about why fetch doesn’t work the same way |
| 07:34 | <MikeSmith> | confused that fetch is not doing some automatic magic for them |
| 08:09 | <annevk> | mkwst: maybe we should add nonce to all elements that might end up using it? |
| 08:09 | <annevk> | mkwst: all elements with src/href I guess? |
| 08:11 | <mkwst> | annevk: *shrug* I'm fine with that. It would basically move back to the patch against HTML, and just make more elements implement the interface. |
| 08:12 | <mkwst> | I'm not sure that's significantly different than putting it on `Element`, but it would reduce the perf overhead for things like `<div>` and `<span>`, which has to be good. |
| 08:13 | <annevk> | mkwst: well, yes, that would be the difference; I wouldn't necessarily make all those elements implement the interface though, just the attribute munging |
| 08:18 | <mkwst> | Ah. So change their insertion steps? |
| 08:18 | <mkwst> | And I guess cloning steps? |
| 08:18 | <mkwst> | I mean, at that point they might as well implement the interface. |
| 08:19 | <annevk> | mkwst: just insertion steps, they only need the slot and cloning when you'd actually add the feature to them |
| 08:20 | <mkwst> | I guess. But Firefox has apparently already added it to some set of elements beyond the spec. I wonder if we should try to support those or punt on it. |
| 08:20 | <annevk> | Yeah, that seems a little weird and I wonder how that happened |
| 08:21 | <annevk> | Clearly there's still stuff shipping without going through a vetted intent to ship |
| 08:23 | <mkwst> | *shrug* I can imagine it was an oversight. I don't know much about mozilla's loading infrastructure, but it might have been easier to pass everything through rather than special-casing scripts. |
| 08:24 | <mkwst> | But that's something of a side-concern. I'd be fine with what you're suggesting, I think. |
| 08:25 | <mkwst> | It's a lot of copy/paste, and I'm not sure it'll make bz any happier, but I'm happy to spec it if that's what you'd like to see. |
| 08:28 | <annevk> | mkwst: alright, I'll make that suggestion on blink-dev and see what bz says later today? |
| 08:30 | <mkwst> | Thanks! |
| 08:56 | <zcorpan> | jgraham: miketaylr: do you know who at mozilla might have opinions about https://github.com/whatwg/html/issues/2464#issuecomment-290421056 |
| 09:06 | <smaug> | Budget API is interesting. I don't really understand at all what it is for |
| 09:06 | <smaug> | especially the cost part |
| 09:09 | <smaug> | beverloo: why does blink want to ship parts of the API which is super vague |
| 09:18 | <smaug> | beverloo: why https://wicg.github.io/budget-api/#budgetservice doesn't use SecureContext? |
| 09:18 | <smaug> | but explicitly check secure context in the algorithm |
| 09:20 | <jgraham> | zcorpan: No idea, sorry |
| 09:22 | <zcorpan> | smaug: do you have any opinion ? https://github.com/whatwg/html/issues/2464#issuecomment-290421056 |
| 09:24 | <smaug> | zcorpan: using toolbar for the noopener case feels like a hack |
| 09:26 | <zcorpan> | smaug: i guess. maybe noopener should have been specified in a new argument with a dictionary, but now it's implemented as a "feature" |
| 09:27 | <smaug> | zcorpan: why is toolbar special? |
| 09:27 | <smaug> | I would expect a new window with toolbar to be shown |
| 09:28 | <zcorpan> | smaug: because it's special in firefox (it opens a "full" browser window rather than a minimal-chrome window) |
| 09:29 | <smaug> | yes, sounds like FF's behavior is the expected one |
| 09:30 | <smaug> | zcorpan: how does one then open a new proper window with toolbar and all? |
| 09:30 | <zcorpan> | smaug: ok. in non-firefox browsers that is not possible |
| 09:30 | <zcorpan> | smaug: before the recent change in chromium you'd always get a minimal-chrome popup |
| 09:31 | <zcorpan> | smaug: in safari/chrome/opera/edge |
| 09:31 | <smaug> | what does Edge do? |
| 09:32 | <zcorpan> | smaug: and empty or missing features argument opens a tab (but then you can't use noopener if you *want* a tab) |
| 09:32 | <smaug> | er, you said edge |
| 09:32 | <zcorpan> | right |
| 09:32 | <zcorpan> | edge also doesn't support noopener here |
| 09:32 | <zcorpan> | afaik (maybe changed in edge15) |
| 09:33 | <smaug> | I might like more some new value |
| 09:34 | <smaug> | which actually tells to the API user what is probably happening |
| 09:34 | <smaug> | zcorpan: does just having 'toolbar' open a tab, even with any other features like size? |
| 09:35 | <zcorpan> | smaug: yes |
| 09:35 | <smaug> | confusing |
| 09:37 | <zcorpan> | smaug: thanks for the feedback. could you also clarify what you would like to see instead? |
| 09:37 | <smaug> | zcorpan: so for API users, shouldn't it be something like openInTab |
| 09:37 | <smaug> | new feature |
| 09:38 | <smaug> | zcorpan: what does Chrome do if you first open a new window (no toolbars) and then open a new window with 'toolbar' ? |
| 09:39 | <zcorpan> | smaug: note that all browsers already have ability to open in a new tab from window.open - http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5007 |
| 09:39 | <smaug> | sure |
| 09:40 | <smaug> | I'm not talking about that |
| 09:41 | <zcorpan> | smaug: it first opens a popup and then a tab... http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5008 |
| 09:42 | <smaug> | zcorpan: you're opening from the same window |
| 09:42 | <smaug> | first open without toolbar, and then that one opens with toolbar |
| 09:42 | <zcorpan> | oh, i see |
| 09:46 | <zcorpan> | smaug: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5009 it opens a tab in the first window |
| 09:47 | <smaug> | huh |
| 09:48 | <smaug> | ok, I didn't know blink has this weird behavior |
| 09:48 | <zcorpan> | it's pretty new and hasn't shipped yet |
| 09:50 | <zcorpan> | CL https://codereview.chromium.org/2773573002 |
| 09:56 | <smaug> | but why does it open a tab in an existing window |
| 13:07 | <annevk> | If anyone is waiting on for something it would be good if you could remind me, since I think I've officially lost track |
| 13:08 | <annevk> | (apart from that assert_throws PR zcorpan) |
| 15:15 | <MikeSmith> | TabAtkins: curl https://api.csswg.org/bikeshed/ -F url=https://raw.githubusercontent.com/w3c/ServiceWorker/246340fce702bab2cce35b046f090606389b279a/docs/index.bs -F output=err |
| 15:15 | <MikeSmith> | LINK ERROR: No 'attr-value' refs found for 'serviceworker'. |
| 15:15 | <MikeSmith> | <a data-link-type="attr-value" data-lt="serviceworker" data-link-for="link/rel">serviceworker</a> |
| 15:16 | <MikeSmith> | hsivonen: I wonder if maybe it’s time to close https://bugzilla.validator.nu/ to new bugs |
| 15:18 | <MikeSmith> | hsivonen: just noticing https://bugzilla.validator.nu/show_bug.cgi?id=1033 from Aaron Leventhal (will comment to ask that he re-raise it in the github tracker) |
| 15:29 | <Domenic> | domfarolino: no problem, completely understandable! |
| 15:30 | <Domenic> | MikeSmith: re previous versions, we also have /commit-snapshots/ |
| 15:33 | <Domenic> | MikeSmith: It's supposed to be data-dfn-for and data-dfn-type per https://tabatkins.github.io/bikeshed/#dfn-contract |
| 15:35 | <TabAtkins> | That's dfn vs link |
| 15:35 | <TabAtkins> | And none of that has to be typed out for a .bs spec |
| 15:36 | <TabAtkins> | (I'll check the spec in a sec - are you sure the term is correctly defined already?) |
| 16:03 | <Domenic> | Oh I see that's the bikeshed error message containing link- |
| 16:39 | <MikeSmith> | TabAtkins: the preprocessed source for the HTML spec has this: |
| 16:39 | <MikeSmith> | <dfn data-dfn-for="link/rel" data-dfn-type="attr-value" data-export=""><code |
| 16:39 | <MikeSmith> | data-x="rel-serviceworker">serviceworker</code></dfn> |
| 16:39 | <MikeSmith> | the processed HTML output has this: |
| 16:39 | <MikeSmith> | <dfn data-dfn-for="link/rel" data-dfn-type="attr-value" data-export=""><code>serviceworker</code></dfn> |
| 16:40 | <MikeSmith> | oh I see that output is exactly the same as the source |
| 16:40 | <MikeSmith> | ah not exactly |
| 16:41 | <MikeSmith> | the output drops the data-x="rel-serviceworker" |
| 16:45 | <TabAtkins> | Which is weird? That's not something Bikeshed removes. |
| 16:45 | <TabAtkins> | Oh, that's HTML source. |
| 16:46 | <MikeSmith> | yeah |
| 16:47 | <MikeSmith> | this is in a heading element btw |
| 16:47 | <MikeSmith> | dunno of that throws bikeshed off |
| 16:48 | <MikeSmith> | <h5 id="link-type-serviceworker">4.6.6.18 Link type "<dfn data-dfn-for="link/rel" data-dfn-type="attr-value" data-export=""><code>serviceworker</code></dfn>"<a href="#link-type-serviceworker" class="self-link"></a></h5> |
| 16:49 | <TabAtkins> | Shouldn't. Checking. |
| 16:50 | <MikeSmith> | TabAtkins: btw as far as xrefs to the HTML spec, for adding xrefs to the xref database, Bikeshed processes the HTML-output published spec? Or does it process the source file? |
| 16:50 | <TabAtkins> | Always HTML output. The db-builder is a separate project entirely, that just spiders a bunch of specs. |
| 16:51 | <TabAtkins> | (Which is one of the reasons naive ReSpec usage is so terrible - you just get unprocessed source.) |
| 16:54 | <MikeSmith> | ah OK |
| 17:05 | <TabAtkins> | Ah, I see the problem. The <dfn> doesn't have an ID on it, so it obviously can't be picked up as an anchor. |
| 17:06 | <annevk> | I guess we should put it all on the <h5> then |
| 17:06 | <TabAtkins> | You can either put an ID there, or move the dfn attributes up to the heading instead (including data-lt, since the text content will no longer be your desired linktext) and remove the <dfn> element. |
| 17:07 | <TabAtkins> | Y'all should probably lint for ID-less <dfn> elements. |
| 17:08 | <annevk> | I don't think so, they're auto-generated |
| 17:08 | <annevk> | It's just that it's slightly different from Bikeshed with headings, so maybe we should lint headings that contain <dfn> |
| 17:08 | <MikeSmith> | TabAtkins: OK, thanks |
| 17:09 | <TabAtkins> | annevk: Well, it doesn't auto-generate in that case, is the issue. |
| 17:09 | <MikeSmith> | yeah |
| 17:09 | <MikeSmith> | annevk: I wonder will it work if I put <dfn id=rel-serviceworker> |
| 17:10 | <MikeSmith> | in the source |
| 17:10 | <MikeSmith> | or I guess the real fix may need some wattsi change |
| 17:11 | <MikeSmith> | but I dunno block this serviceworker xref on that |
| 17:11 | <MikeSmith> | *don’t want to block |
| 17:13 | <annevk> | TabAtkins: it's a feature, since we want links to go to the heading |
| 17:14 | <TabAtkins> | annevk: Ah, kk. In that case, yeah, lint for "<dfn>s in headings that people marked up for Bikeshed, accidentally thinking it would get an ID". ^_^ |
| 17:14 | <annevk> | MikeSmith: I'd prefer exporting from the heading over creating a new ID |
| 17:14 | <annevk> | TabAtkins: yeah |
| 17:16 | <MikeSmith> | exporting from the heading loses the value of being able to refer to it with just <{link/rel/serviceworker}> in bikeshed, right? |
| 17:16 | <MikeSmith> | the problem I want to solve here is just to be able to use <{link/rel/serviceworker}> |
| 17:16 | <annevk> | MikeSmith: no, you should still be able to do that |
| 17:16 | <TabAtkins> | MikeSmith: No, it's fine - headings can be definition-providers just like <dfn>. |
| 17:17 | <MikeSmith> | ah OK |
| 17:17 | <MikeSmith> | will raise a PR that does it that way, then |
| 17:18 | <MikeSmith> | though I guess the next thing that we are gonna wonder about is, should I change all the other link-relation headings/dfn in the same way |
| 17:19 | <MikeSmith> | wait though |
| 17:19 | <MikeSmith> | nm |
| 17:19 | <MikeSmith> | will just try it for the serviceworker heading from now |
| 17:24 | <MikeSmith> | TabAtkins: OK so the following HTML will work as far as what Bikeshed needs? |
| 17:24 | <MikeSmith> | <h5 data-dfn-for=link/rel id=link-type-serviceworker data-dfn-type=attr-value data-export="">4.6.6.18 Link type "<dfn><code>serviceworker</code></dfn>"<a href=#link-type-serviceworker class=self-link></a></h5> |
| 17:25 | <TabAtkins> | You want data-lt=serviceworker on there (unless you really want the attribute value to be "4.6.6.18 Link Type "serviceworker""). And you can remove the `<dfn>` element entirely. |
| 17:26 | <MikeSmith> | haha |
| 17:26 | <MikeSmith> | ah OK yeah |
| 17:36 | <MikeSmith> | TabAtkins: annevk Domenic https://github.com/whatwg/html/pull/2524 |
| 18:04 | <Domenic> | TabAtkins: what is the incantation to link to things that are for-now-not-exported? I thought there was something you could put in link-defaults? |
| 18:05 | <TabAtkins> | spec=foo on the link, or a link-defaults line (which includes a spec:foo; entry) |
| 18:05 | <Domenic> | Hmm I tried `spec: URL; text: base URL` and it complained at me |
| 18:06 | <TabAtkins> | Definitely need at least a "type" in link defaults. |
| 18:06 | <TabAtkins> | Did it complain properly, telling you what was missing? |
| 18:07 | <TabAtkins> | (If not, that's a Bikeshed bug.) |
| 18:07 | <Domenic> | It did say it needed a type, but I am surprised since URL already defines the type (as dfn) |
| 18:07 | <TabAtkins> | Yeah, but Bikeshed needs to know what the type is so it can actually match things up. |
| 18:07 | <Domenic> | But now I did `spec: URL; type: dfn; text: base URL` and it's complaining `[1;33mLINK ERROR:[0m No 'dfn' refs found for 'base url' that are marked for export.` |
| 18:07 | <TabAtkins> | Okay, will check in a sec, in an interview rn. |
| 18:08 | <Domenic> | ok! |
| 19:41 | <dcheng> | smaug: It's because of the NavigationPolicy we pick |
| 19:42 | <dcheng> | smaug: I suppose we could make it always create a new window if it's created from a popup, would that make it less weird? |
| 19:43 | <smaug> | yes |
| 21:04 | <MikeSmith> | TabAtkins: so https://html.spec.whatwg.org/ now has this: |
| 21:04 | <MikeSmith> | <h5 data-dfn-for=link/rel id=link-type-serviceworker data-dfn-type=attr-value data-lt=serviceworker data-export="">4.6.6.18 Link |
| 21:04 | <MikeSmith> | type "<dfn><code>serviceworker</code></dfn>"<a href=#link-type-serviceworker class=self-link></a></h5> |
| 21:04 | <MikeSmith> | yet: |
| 21:04 | <MikeSmith> | curl https://api.csswg.org/bikeshed/ -F url=https://raw.githubusercontent.com/w3c/ServiceWorker/246340fce702bab2cce35b046f090606389b279a/docs/index.bs -F output=err |
| 21:04 | <MikeSmith> | still gives: |
| 21:04 | <MikeSmith> | LINK ERROR: No 'attr-value' refs found for 'serviceworker |
| 21:07 | <Domenic> | MikeSmith: it probably will take a day for it to propagate :-/ |
| 21:07 | <MikeSmith> | aha |
| 21:07 | <Domenic> | annevk: UTF-8 decode produces a scalar value string, not a JavaScript string, right? |
| 21:09 | <MikeSmith> | never any instant gratification in working on the web runtime 😞 |
| 21:09 | <TabAtkins> | MikeSmith: kNah, it's already there. |
| 21:09 | <TabAtkins> | Just updated a few minutes ago to check, and it's returned by `bikeshed refs --text=serviceworker` |
| 21:10 | <MikeSmith> | well wtf then |
| 21:11 | <MikeSmith> | I got <{link/rel/serviceworker}> in teh Service Worker source |
| 21:11 | <TabAtkins> | Oh, hm, it doesn't have a for value in the db. |
| 21:12 | <MikeSmith> | ah yeah the full error is LINK ERROR: No 'attr-value' refs found for 'serviceworker' with for='link/rel'. |
| 21:12 | <TabAtkins> | That's weird tho |
| 21:12 | <TabAtkins> | Gonna yell at plinss about it. |
| 21:12 | <MikeSmith> | it doesn’t recognize data-dfn-for=link/rel ? |