| 00:00 | <tantek> | FWIW I say keep it as plain text. Markdown in templates is kinda junky. |
| 00:00 | <tantek> | also markdown was supposed to *be* plain text, so if you're ever asking the question of markdown vs. plain text, pick plain text becuase no "real" markdown would be breaking principle 1 and not actually be plain text |
| 02:17 | <miketaylr> | annevk: yeah :(, allhands as a manager get... busy fast. i'll shoot you an email tomorrow and maybe we can find some vidyo time (or just use email) |
| 07:14 | <domfarolino> | annevk: If I were to set {referrer: "http://same-origin.url:80";} on a request object `x`, would `x.referrer` be expected to return "http://same-origin.url"; or "http://same-origin.url"; |
| 07:17 | <domfarolino> | I ask because tests 8-11 always fail in http://w3c-test.org/fetch/api/request/request-init-001.sub.html and I feel like the test could be updated? |
| 07:39 | <annevk> | domfarolino: yeah those tests are wrong |
| 07:40 | <annevk> | domfarolino: the URL is indeed expected to be parsed and then serialized |
| 07:40 | <domfarolino> | annevk: ok I will submit a PR. Makes sense |
| 07:40 | <annevk> | domfarolino: I suspect browsers don't notice this since they locally don't run the tests over the default port |
| 07:40 | <annevk> | domfarolino: it's a longstanding issue with the WPT setup |
| 07:41 | <domfarolino> | That makes sense |
| 07:44 | <domfarolino> | annevk: So the tests now will accidentally be correct for non-default port usages, but are technically wrong, and would be right if they don't check the port right? |
| 07:45 | <annevk> | domfarolino: they would be right if they don't expect the default port but expect a port otherwise |
| 08:08 | <domfarolino> | annevk: ok. I’ll take a closer look at it tomorrow morning (for me) to mend it |
| 08:10 | <annevk> | domfarolino: nn then, I suppose |
| 09:06 | <Ms2ger> | foolip, I started looking at https://github.com/w3c/web-platform-tests/pull/8748 , but it ended up more complicated than expected. Could you review? |
| 10:07 | <annevk> | foolip: hmm, now I have to patch HTML's usage of cyphertext |
| 13:07 | <foolip> | Ms2ger: will do |
| 14:30 | kochi | feeling tough for making a decision. |
| 14:30 | <kochi> | (re webcomponents#713) |
| 14:32 | <annevk> | kochi: yeah, that's painful |
| 14:32 | <annevk> | kochi: I think you did the right thing though |
| 14:32 | <annevk> | if that helps |
| 14:33 | <kochi> | annevk: thanks, well, I think what's right would be having a place where everyone can join... |
| 14:36 | <kochi> | smaug____: you originally booked rooms in the Toronto office in the week of Feb. 19, but is it okay to ask you to book the week of Mar. 5? |
| 14:36 | <smaug____> | kochi: I just updated the reservation |
| 14:36 | <smaug____> | Mar 5-6 |
| 14:36 | <kochi> | smaug____: thanks!!!! |
| 14:36 | <smaug____> | er, 6-7 |
| 14:36 | <annevk> | kochi: that'd be the most right, yes |
| 14:37 | <smaug____> | kochi: 6-7 is right, right? |
| 14:37 | <annevk> | the rightest |
| 14:37 | <smaug____> | Tue, March 6, 2018 – Wed, March 7, 2018 |
| 14:37 | <annevk> | hai |
| 14:38 | <kochi> | smaug____: yeah, if it's in Toronto, we'd prefer Mar. 6-7 (Tue-Wed) |
| 14:38 | <smaug____> | I guess I could extend that, just in case... |
| 14:39 | <smaug____> | Mon, March 5, 2018 – Wed, March 7, 2018 |
| 14:41 | <kochi> | interesting, probably I'd travel to get there on Sunday, just in case for storm/delay, but then I can have a free Monday in Toronto. maybe having a pre-meeting with people there is good. |
| 14:46 | <kochi> | I honestly don't understand Feature Policy, but I feel history API in iframes in shadow DOM can be controlled by Feature Policy. |
| 14:47 | <annevk> | kochi: well, maybe, but that'd make it even more complicated, right? |
| 14:47 | <kochi> | (re webcomponents#184) |
| 14:52 | <kochi> | annevk: (I need to understand Feature Policy first, but I imagine) the owner of <iframe> can specify whether the history in iframe can join the joint session history, or make it have its independent session history. |
| 14:57 | kochi | goes to bed |
| 14:57 | <annevk> | kochi: yeah I guess, though within a closed shadow tree we wouldn't want to allow that |
| 14:57 | <annevk> | kochi: nn |
| 15:24 | <Ms2ger> | annevk, r? https://github.com/whatwg/html/pull/3308 |
| 15:24 | <annevk> | Domenic: so we have a set of algorithms that are dangerous for other specification editors to touch; ideally we have some consistent messaging around these effectively deprecated internal APIs |
| 15:24 | <annevk> | domfarolino: so we could redirect them all to some Infra thingy perhaps but then we couldn't provide local issue filing support |
| 15:25 | <annevk> | Domenic: ^^ thoughts? |
| 15:25 | <annevk> | sorry domfarolino, though your thoughts are welcome too 😃 |
| 15:25 | <Domenic> | annevk: example? |
| 15:25 | <domfarolino> | 👍 |
| 15:26 | <annevk> | Domenic: "same-origin domain" (and also the document.domain algorithm) came to mind today |
| 15:27 | <Domenic> | I guess just class="warning" seems OK to me; I'm not sure about the need for consistency, as you'll need to explain the reasons why they're bad in any case. |
| 15:28 | <annevk> | Ms2ger: r+ with some newline removal |
| 15:28 | <annevk> | Domenic: okay, I guess that's fine too |
| 15:28 | <annevk> | Domenic: I'm sensing some kind of pattern, but maybe too early |
| 15:29 | <Ms2ger> | annevk, any newlines in particular? (Did you forget to publish a review comment?) |
| 15:29 | <Ms2ger> | There it is, nvm |
| 15:29 | <annevk> | \o/ |
| 15:30 | <annevk> | (I was a little slow) |
| 15:31 | <Ms2ger> | I stole that pattern of newlines from the next <ol>, is there a guideline published somewhere? |
| 15:33 | <annevk> | Ms2ger: I guess I should update https://github.com/whatwg/html/blob/master/CONTRIBUTING.md#source-formatting |
| 15:33 | <annevk> | Ms2ger: let me do that |
| 15:34 | <Ms2ger> | Okay, I looked at that, and if I'd paid more attention, that would have avoided half your comments :) |
| 15:35 | <Ms2ger> | (And fixed) |
| 16:57 | wanderview | never knows whether to ping people on IRC for WPT reviews or just hope they see it in their deluge of github mail... |
| 16:58 | <wanderview> | JakeA: jungkees: if either of you have a chance, I have a small WPT test fix I could use review on: https://github.com/w3c/web-platform-tests/pull/8743 |
| 16:59 | <Shreya> | Can anyone please review https://github.com/whatwg/html/pull/3303? |
| 19:39 | <domfarolino> | Domenic: for that console formatting issue, are you thinking we should invoke the Symbol’s toString() instead of just throwing? |
| 19:42 | <domfarolino> | So like do a type check before just deferring to ToString() maybe |
| 19:51 | <Domenic> | domfarolino: I don't know about invoking toString(), maybe just composing our own string like "Symbol(" + symbol.[[Description]] + ")" ? But yeah a type-check. |
| 19:52 | <Domenic> | Wow Firefox really does print nothing, interesting. |
| 19:57 | <Domenic> | annevk: force-pushed over https://github.com/whatwg/html/pull/3305, I should've done a new commit so it'd email you, oh well. |
| 19:58 | <domfarolino> | Domenic: Hm alright wouldn’t that produce an identical string to toString() is there a reason to not invoke it? Just curious (not super familiar with Symbols yet) |
| 19:59 | <Domenic> | domfarolino: it'd differ in the case of someone overriding Symbol.prototype.toString. I guess it's worth testing what browsers do in those cases. |
| 20:01 | <Domenic> | domfarolino: it looks like ES already has something for us: https://tc39.github.io/ecma262/#sec-string-constructor-string-value |
| 20:13 | <annevk> | Domenic: I was out too so... |
| 20:14 | <annevk> | Domenic: I'll be out until January 3 or so soonish |
| 20:14 | <Domenic> | Ah OK, sounds good |
| 20:14 | <annevk> | Domenic: probably won't bring my laptop either |
| 20:14 | <Domenic> | I'll be similar starting Friday |
| 20:15 | <Domenic> | annevk: do you want to help shepherd https://github.com/whatwg/html/pull/3308 through to the end (addColorStop) or should I familiarize myself with everyone's review comments? |
| 20:16 | <domfarolino> | Domenic: Good call. Will check out link soon, driving for a bit soon and on mobile now |
| 20:17 | <annevk> | Domenic: I guess I'm happy to leave it until the new year; I suppose Ms2ger isn't in a hurry either for a clarification PR |
| 20:17 | <Domenic> | ah ok |
| 20:17 | <annevk> | Domenic: I'm happy to finish it for Ms2ger at that point |
| 20:18 | <annevk> | Domenic: that is, it seems junov made some good points that require either follow-up issues or be addressed directly |
| 20:49 | annevk | gives a lone vote for the Paris F2F backup plan |
| 20:50 | <annevk> | Being able to go to a F2F by train would be the best, although likely I'd still end up flying |
| 22:05 | <adiabatic> | I'm trying to place a <style> element as a child of <body> because I'm lazy and want to keep some CSS with the blog post that it applies to. That said, the w3c validator says that <style> may be used where metadata content is expected…but the diagram in §3.2.5.2 shows that some metadata content is also flow content like <p> is… |
| 22:05 | <adiabatic> | …and the w3c validator says: "Contexts in which element style may be used: … In the body, where flow content is expected." |
| 22:06 | <adiabatic> | So why am I getting an error? |
| 22:06 | <adiabatic> | (I get a similar error from validator.nu) |
| 22:07 | <Domenic> | adiabatic: In the HTML Standard (not any W3C forks) <style> is not allowed inside <body>. I'm not sure about those checkers but I do know https://checker.html5.org/ is up to date with that. |
| 22:12 | <adiabatic> | OOoooh, OK. If <style> were metadata _and_ flow content like <noscript> it'd say. Thanks! |
| 22:13 | <adiabatic> | That's kind of a shame; it seems to work in all the browsers I use… |
| 22:17 | <Domenic> | Yeah, it works in browsers, just is bad for performance, so it causes validation failures |
| 22:18 | <adiabatic> | why, because it can trigger a whole-page repaint when the page is half- or 3/4 downloaded? |
| 22:18 | <Domenic> | Exactly |
| 22:20 | <adiabatic> | weird. I'd figure "it'd make your page slow" would be cause for a warning, not an error |
| 22:22 | <Domenic> | I mean, it's way more serious than using <strong><em>foo</strong></em> or similar, as it actually affects your users. |