| 00:01 | MikeSmith | looks |
| 00:04 | <MikeSmith> | "this approach effectively replaces all of the HTML Imports machinery with straight-up ES Modules plumbing and leaves only a handful of HTML-specific bits" |
| 00:04 | <MikeSmith> | nice |
| 00:05 | <MikeSmith> | wonder if anybody from Apple or Mozilla have commented on that yet |
| 00:12 | <MikeSmith> | ah I guess not, since Domenic was asking, "Has everyone seen dglazkov's HTML modules"... :) |
| 00:27 | <miketaylr> | did the single page spec @ https://html.spec.whatwg.org/c get removed? |
| 00:27 | <miketaylr> | maybe that should 302 to https://html.spec.whatwg.org/ |
| 00:27 | <miketaylr> | oh my bad. |
| 00:28 | <miketaylr> | whatwg.org/c is the shortcut |
| 07:23 | <annevk> | Domenic: re https://github.com/whatwg/html/issues/550#issuecomment-173831401 if those two execution modes are indistinguishable, arguably user agents are allowed to do that already (you can probably observe through the server, but we've mostly come to agreement that doesn't count I believe) |
| 07:23 | <annevk> | Domenic: as for CORS, note that classic workers currently have to be same-origin |
| 08:50 | Ms2ger | will be out from this afternoon until next Friday |
| 08:51 | <annevk> | tobie: I saw you're still looking for information on Observables, maybe in #jslang on Mozilla IRC, though from what I've heard there's still a lot of controversy around it and not really done |
| 08:51 | <annevk> | tobie: and unclear how it works with Streams |
| 08:53 | <tobie> | annevk: Thanks. I'm vaguely aware of the controversy. |
| 08:54 | <tobie> | annevk: my main issue is that I specifying stuff that could work in both node and the browser |
| 08:55 | <tobie> | And I cant do the former because no common event pattern |
| 08:59 | <tobie> | annevk: ty for the #jslang pointer, btw. Wasn't aware it was a thing. |
| 09:00 | <annevk> | It seems to be the TC39-counterpart to #whatwg |
| 09:00 | <tobie> | indeed |
| 10:27 | <ritsyy1> | annevk: as per the spec https://html.spec.whatwg.org/multipage/tables.html#the-th-element , the "sorting th element" needs to be removed as the "the table sorting model" has been removed from the spec, right? |
| 10:36 | <Ms2ger> | ritsyy1, sounds correct |
| 10:39 | <ritsyy1> | Ms2ger: okay |
| 11:53 | <ritsyy1> | getting this error while doing the rebase https://paste.kde.org/po3wmemsv |
| 11:53 | <ritsyy1> | annevk: ^ |
| 12:05 | <MikeSmith> | ritsyy1: so there's probably no way to fix those merge conflicts automatically |
| 12:06 | <MikeSmith> | if you open the source file in an editor and search for ">>>>" you'll find the actual conflict |
| 12:07 | <MikeSmith> | the normal way to fix those conflicts is by manually editing the file to make it say with you want it to say |
| 12:07 | <MikeSmith> | after reviewing the conflict |
| 12:07 | <MikeSmith> | so you edit it do read as it should, and remove the conflict markers |
| 12:08 | <MikeSmith> | ritsyy1: this is for https://github.com/whatwg/html/pull/526 right? |
| 12:10 | <ritsyy1> | MikeSmith: yes it's for this PR |
| 12:11 | <MikeSmith> | ritsyy1: OK yeah I'm looking at the conflict myself now |
| 12:12 | <ritsyy1> | MikeSmith: the errors are for the image files i removed |
| 12:12 | <annevk> | ritsyy1: no, it's for source, "CONFLICT (content): Merge conflict in source" |
| 12:13 | <MikeSmith> | ritsyy1: yeah I see the messages about the image files for those are just informative, telling you that they are actually being removed |
| 12:13 | <annevk> | ritsyy1: you'll have to figure out what the conflict is, resolve it, and then some combination of git add/git rebase --continue |
| 12:14 | <annevk> | Merge conflicts are no fun 😟 |
| 12:14 | <ritsyy1> | MikeSmith: yeah i am seeing that now, thank you |
| 12:15 | <MikeSmith> | the conflict appears to be with the part of the table that has <th> <code data-x="">sizes</code> and <th> <code data-x="">sortable</code> and <th> <code data-x="">sorted</code> |
| 12:15 | <MikeSmith> | yeah, merge conflicts are PITA. Everbody hates dealing with them |
| 12:16 | <ritsyy1> | MikeSmith: i didn't find any ">>>>" in the file |
| 12:16 | <MikeSmith> | ritsyy1: I would guess you want to keep the <th> <code data-x="">sizes</code> part but not the parts for "sortable" and "sorted" there |
| 12:16 | <MikeSmith> | oh it might be that it puts different conflict markers |
| 12:17 | <MikeSmith> | the conflict is at line 114569 of the source file |
| 12:17 | <ritsyy1> | MikeSmith: okay i am seeing that |
| 12:17 | <MikeSmith> | that is the Attributes index I guess |
| 12:18 | <MikeSmith> | so it's not a big problem |
| 12:18 | <MikeSmith> | but it should be made to match what's in the body of the text |
| 12:19 | <MikeSmith> | so if the "sortable" and "sorted" attibutes have been dropped, then you shoudl (re)remove them from that table of the index |
| 12:19 | <MikeSmith> | but leave the "sizes" row |
| 12:19 | <MikeSmith> | I think |
| 12:19 | <MikeSmith> | I'm not sure why you ended up with that conflict, but you can fix it that way |
| 12:19 | <ritsyy1> | MikeSmith: yes got that, yeah you are right |
| 12:20 | <MikeSmith> | OK. I have to step away for a bit but will be back in another hour or so if you still need help with unwinding it |
| 12:20 | <MikeSmith> | but in the mean time it looks like annevk is back around now too |
| 12:20 | <ritsyy1> | MikeSmith: no no i'll do this fix now, thanks :) |
| 12:22 | <annevk> | I guess zcorpan recently added sizes="" so that's probably why there's a conflict |
| 12:23 | <zcorpan> | yep |
| 12:47 | <ritsyy1> | annevk: yeah it was because of that commit, but i did that mistake of removing sizes row too, conflicts free PR looks good https://github.com/whatwg/html/pull/526 :) |
| 13:23 | <annevk> | ritsyy1: should I review seamless first? |
| 13:28 | <ritsyy1> | annevk: yeah i did the fixes in that too, i thought to tell you here, but forgot that :-/ |
| 13:30 | <annevk> | ritsyy1: it seems one sentence there is still over a 100 characters |
| 13:30 | <annevk> | ritsyy1: ' <dfn><code data-x="dom-iframe-srcdoc">srcdoc</code></dfn>, <dfn><code data-x="dom-iframe-name">name</code></dfn>, and' |
| 13:31 | <annevk> | oh maybe I'm not looking at the correct version |
| 13:32 | <annevk> | Indeed, I was not, looking good |
| 13:32 | <ritsyy1> | annevk: yay |
| 13:37 | <annevk> | I filed https://github.com/Fyrd/caniuse/issues/2232 against caniuse.com so the warning can be removed from the build script |
| 13:42 | <ritsyy1> | annevk: great, thanks \o/ |
| 13:43 | <annevk> | I also closed the bugs mentioned in the build script |
| 13:46 | <ritsyy1> | annevk: oh yeah those 2 bugs, great :) |
| 14:01 | <hsivonen> | UTF-16 variants turn into UTF-8 in form submission and URLs and replacement encodes like UTF-8. Is there a defined term for the encoding that's used for output (i.e. UTF-8) in these cases? |
| 14:01 | <hsivonen> | annevk: ^ |
| 14:02 | <hsivonen> | annevk: OK if I mint a concept "output encoding" and define that the output encoding of an encoding is the encoding itself except UTF-8 for utf-16be, utf-16le and replacement |
| 14:02 | <hsivonen> | (that is, I want a term for the docs I'm writing and I want consistent terminology in case WHATWG specs mint a term for the same concept in the future) |
| 14:06 | <hsivonen> | actually, docs are secondary. I want to name a method in an API |
| 14:06 | <annevk> | There is no term right now, though "output" and "encoder" don't quite align perhaps? |
| 14:08 | <hsivonen> | I'm not sure I understand the non-alignment |
| 14:08 | <hsivonen> | it's not "output encoder" but "output encoding" |
| 14:09 | <hsivonen> | then you'd create an encoder for the output encoding |
| 14:09 | <hsivonen> | and if we remove the UTF-16 encoders from the platform, I'd change the definition of new_encoder() API call to create an encoder for the output encoding of this encoding |
| 14:10 | <hsivonen> | anyway, I'm looking for a qualifier for "encoding" that means the encoding that's used for form submission and URL query strings |
| 14:11 | <hsivonen> | from the point of view of this encoding where this encoding is the encoding of the page |
| 14:12 | <annevk> | Perhaps the non-alignment is that in the spec "replacement" would still be the encoding, it's just that replacement's encoder is utf-8's encoder |
| 14:12 | <hsivonen> | could be "submission encoding" instead of "output encoding" assuming that "submission" is considered to cover the query string, too, which is kinda related to submission |
| 14:14 | <annevk> | Although maybe that is wrong and there is indeed a need for an output encoding instead, since if we mention the encoding somewhere we wouldn't want to say "replacement" |
| 14:14 | <hsivonen> | annevk: indeed, but consider: if you use script to add a form to a doc whose encoding is replacement, would you want the _charset_ field to say "replacement" or "utf-8"? |
| 14:14 | <hsivonen> | I'd say "utf-8", since "replacement" is not a label |
| 14:15 | <annevk> | I think you are correct, but this will require some cleaning up in the specification too |
| 14:17 | <annevk> | I will file an issue |
| 14:17 | <hsivonen> | annevk: thanks |
| 14:31 | <zcorpan> | TabAtkins: pls check https://github.com/tabatkins/bikeshed/issues/572 when you have time :-) |
| 14:47 | <JakeA> | wanderview: I really want to link to my favourite bit https://www.youtube.com/watch?v=TFzR00NzQ1c - but there's an editing glitch towards the end :/ |
| 14:47 | <JakeA> | Getting them to fix it |
| 15:08 | <annevk> | TabAtkins: I updated bikeshed, now when I generate DOM a whole set of IDs changes |
| 15:08 | <annevk> | TabAtkins: e.g., https://dom.spec.whatwg.org/#canceled-flag would no longer work if I committed this |
| 15:08 | <annevk> | TabAtkins: that seems bad |
| 15:33 | <annevk> | TabAtkins: Compat Standard is bikeshed too |
| 15:34 | <annevk> | TabAtkins: Streams (perhaps a variant, or with additional processing), Notifications |
| 15:46 | <annevk> | MikeSmith: did you know about https://w3c-html-ig-zh.github.io/notifications/whatwg/? |
| 15:46 | <annevk> | MikeSmith: seems pretty cool, bit out of date, but still |
| 16:04 | <nox> | annevk: How are standards' translations received, in general, around here? |
| 16:05 | <annevk> | I think it's great |
| 16:06 | <annevk> | Sadly we don't have the resources of the EU, to make this stuff accessible to all |
| 16:06 | <annevk> | And sadly keeping up with the everchanging landscape is hard |
| 16:39 | <beverloo> | annevk, do you have any strong feelings about having a `notificationclose` event or not? |
| 16:40 | <beverloo> | I argued for removing it a year or two ago, but some fair use-cases have come up since and we might want to introduce it again |
| 16:56 | <TabAtkins> | annevk: Yeah, had to start disambiguating anything with a `for`. Otherwise <dfn for=Foo>bar</dfn> and <dfn for=Baz>bar</dfn> would both try to generate a #bar id. |
| 16:58 | <TabAtkins> | I'm happy to find the changing IDs and give you a PR that locks them into their old values. |
| 17:00 | <TabAtkins> | (I can't just let it generate a simple ID and only disambiguate if there's a collision, as that would make IDs unstable from unrelated edits.) |
| 17:01 | <TabAtkins> | (I could leave it alone entirely and let people hit the "two things have the same ID" error when it happens, but it seems friendlier for the future to make it silently work, and eat a little bit of compat pain now.) |
| 17:05 | TabAtkins | will work on the ID-locking PR this mornign. |
| 17:05 | <Domenic> | annevk: the execution modes are distinguishable, becuase you can run code between imports. So e.g. `import './a.js'; foo(); import './b.js';` where `b.js` 404s. If we do a two-stage async version, foo never executes (the error occurs in the first stage). If we do a sync import, then foo executes and the error only occurs on the `import './b.js'` line. |
| 17:06 | <annevk> | TabAtkins: ta |
| 17:06 | <annevk> | beverloo: nah |
| 17:06 | <annevk> | beverloo: been trying to get some Mozillians involved that work on the implementation, but no luck thus far |
| 17:06 | <TabAtkins> | annevk: I think DOM is the heaviest user of the "dfn-type definition with a for" pattern right now, so you're the most affected. ^_^ |
| 17:07 | <beverloo> | annevk, yeah, Jonas' new focus is kind of a bummer for us |
| 17:07 | <annevk> | TabAtkins: url too, though I think I use a lot of explicit IDs there |
| 17:07 | <annevk> | beverloo: pretty happy he's not doing Firefox OS anymore, personally |
| 17:07 | <beverloo> | annevk, hah :) |
| 17:07 | <beverloo> | I read your blog post |
| 17:07 | <annevk> | new project seems much more exciting |
| 17:08 | <beverloo> | I'm sure, but it still leaves a bit of a gap in Mozilla-side feedback on the functional bits of the API |
| 17:08 | <beverloo> | thanks for trying to engage other people |
| 17:18 | jgraham | wonders what he is doing now |
| 17:18 | <jgraham> | sicking I mean |
| 17:18 | <jgraham> | Although I also often wonder what I am doing |
| 17:19 | <annevk> | jgraham: https://github.com/flyweb |
| 17:23 | <jgraham> | Ah right |
| 17:24 | <jgraham> | Definitely an element of Opera Did It First to that |
| 17:37 | <TabAtkins> | annevk: Ok, PR ready. Do you want dom.html included? Only changes are the date, obvs, and a few small updates to boilerplate markup, which doesn't affect the spec visually at all (I checked). |
| 17:38 | <annevk> | TabAtkins: both is fine |
| 17:43 | <TabAtkins> | k, PR waiting for you now. Sorry for the disruption, but it's for the future best. ^_^ |
| 18:10 | <annevk> | ta |
| 18:35 | <smaug____> | jgraham: how does one add a new wpt test |
| 18:35 | <smaug____> | add the file and then what? |
| 18:36 | <smaug____> | there was some magic one need to do after that |
| 18:36 | <smaug____> | (this is in mozilla tree) |
| 18:37 | <yury`m> | smaug____: there is README.md https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/README.md |
| 18:38 | <yury`m> | smaug____: mach web-platform-tests-create will do the magical manifest update |
| 18:39 | <smaug____> | mach web-platform-tests --manifest-update <path> is perhaps the one I need |
| 18:40 | <smaug____> | yury`m: thanks |
| 18:41 | <smaug____> | that caused some rather unexpected changes though |
| 18:42 | <yury`m> | smaug____: it needs to update manifest(s) |
| 18:43 | <smaug____> | sure, but it made some totally unrelated changes |
| 18:43 | <smaug____> | but should be now after manually fixing those cases |
| 18:44 | <smaug____> | s/now/fine now/ |
| 18:49 | <jgraham> | smaug____: There's also mach web-platform-tests-create these days |
| 18:51 | <smaug____> | I used the script which is used for other tests too |
| 18:55 | <jgraham> | Out of interest, what were the unexpected manifest changes? |
| 18:58 | <smaug____> | jgraham: it moved random stuff in MANIFEST.json |
| 18:59 | <smaug____> | the expected one was to add a new file to MANIFEST.json |
| 18:59 | <smaug____> | perhaps someone has modified that file manually and the script uses some different ordering for file entries? |
| 19:27 | <jgraham> | smaug____: OK. If it happens again send me a diff, perhaps? |
| 19:50 | <smaug____> | jgraham: one thing not clear to me is when to create a new test |
| 19:50 | <smaug____> | and when to just put more assert_*() inside the function |
| 19:52 | <smaug____> | I already added function is(val, expected, comment) { test(function() {assert_equals(val, expected, comment )}) }, but decided to remove it since perhaps it isn't the wpt style |
| 20:15 | <jgraham> | smaug____: Each test is a unit of pass/fail and will stop at the first assert that fails. So generally more tests is better than more unrelated asserts in the same test, but it's obviously better to have more asserts in a single test than to not write the tests at al |
| 20:17 | <smaug____> | jgraham: well, I would assume all the asserts in a file are related |
| 20:18 | <smaug____> | but ok, this is up to the test writer to split to smaller tests or just have one test and several asserts in it |
| 20:44 | <smaug____> | jgraham: how do I see (in terminal perhaps) the output from all the asserts? |
| 21:27 | <jgraham> | smaug____: You can't |
| 21:30 | <smaug____> | ok |
| 21:30 | <smaug____> | jgraham: see my question in moznet #content |