| 00:50 | <Domenic> | annevk: I think that's called a merge commit |
| 00:51 | <Domenic> | I don't use it often so I don't remember the commands but it seems pretty legit |
| 00:51 | <Domenic> | tobie: yeah, that is kind of the plan; nobody should really care, so it's probably not worth making the distinction. |
| 00:52 | <Domenic> | I would really like bz to review but every time I ping him he's busy, so maybe we should go ahead and he can review post-facto if he finds anything... It would be good to un-block the SharedArrayBuffer work. |
| 01:43 | <Domenic> | tantek: MikeSmith: do you have thoughts on https://github.com/whatwg/html/issues/2351 ? |
| 01:44 | <tantek> | well that's always a good sign, to be paired with MikeSmith |
| 01:44 | tantek | looks |
| 01:45 | <tantek> | really we have no rel-canonical "spec" per se? I find that a bit, surprising. Let me look a bit. |
| 01:45 | <tantek> | "This article is a stub" πππ http://microformats.org/wiki/rel-canonical |
| 01:46 | <tantek> | well we have a *stub* of a spec |
| 01:46 | <tantek> | seems like people though it was "obvious" enough to not need a spec? |
| 01:46 | <tantek> | (which of course isn't the best reasoning obv) |
| 01:46 | <tantek> | adding to issue |
| 01:49 | <Domenic> | \o/ |
| 01:49 | <tantek> | Thanks for the heads-up Domenic |
| 01:51 | <tantek> | hope the comments on the issue are helpful |
| 02:11 | <MikeSmith> | Domenic: do UAs do anything with rel=canonical? |
| 02:12 | <Domenic> | MikeSmith: not browser UAs I think, but lots of other UAs |
| 02:12 | <MikeSmith> | OK |
| 02:13 | <MikeSmith> | well if we do this systematically maybe we could consider setting a usage threshold for what rel values we include in the spec |
| 02:13 | <MikeSmith> | I could add a use counter to the checker |
| 02:13 | <MikeSmith> | and Simon could do a query |
| 02:13 | <tantek> | maybe we could start with determining the usage #s for the *existing* values in the spec? |
| 02:13 | <MikeSmith> | yeah that too |
| 02:14 | <MikeSmith> | good point |
| 02:14 | <tantek> | to see if usage-based-inclusion makes sense at all? |
| 02:14 | <tantek> | (not saying it doesn't just saying we can check the "control" as it were ;) ) |
| 02:14 | <tantek> | meanwhile I pinged kevinmarks to braindump his thoughts/knowledge of rel=canonical into the wiki page in spec-ese |
| 02:14 | <tantek> | (in the gh issue of course0 |
| 02:14 | <tantek> | ) |
| 02:15 | <tantek> | might as well start writing things up formally, whereever they end up |
| 02:15 | <MikeSmith> | I guess I would expect the ones we already have in the spec to have relatively high usage, but that some values we donβt yet have in the spec, like rel=canonical, might have even higher usage than some already in the spec |
| 02:16 | <tantek> | yeah, plus I'd expect some in the spec to have low usage because they may have been more, um, aspirational as it were ;) |
| 02:17 | <tantek> | rel values in general have been falling out of vogue too - e.g. in #microformats and #indieweb we've largely switched over to using properties of objects, because rel values are nearly only useful for page-level-scope, and many things (like blog posts) can occur multiple times on a page |
| 02:17 | <tantek> | might as well document the ones that are in use though (published and consumed) |
| 02:17 | <tantek> | also would be good to get an updated survey since the 2004/2005 one that Hixie did |
| 02:18 | <tantek> | we're likely to have different results today than 12ish years ago |
| 03:11 | <MikeSmith> | Domenic: OK I just added a rel=canonical use counter to the W3C HTML checker |
| 03:11 | <MikeSmith> | running results are at https://validator.w3.org/nu/stats.html |
| 03:12 | <MikeSmith> | currently 170 documents out of 522 have rel=canonical |
| 03:12 | <MikeSmith> | 33% |
| 03:13 | <MikeSmith> | which seems high but am pretty sure my code is right |
| 03:13 | <MikeSmith> | https://github.com/validator/validator/commit/c8013ba526d639aab742020c7b71584f27a2bad2?diff=unified#diff-5c9743fbd69f36c7a9eb6a7a91bce31fR441 |
| 03:14 | <MikeSmith> | the use counter only logs it once per document |
| 03:31 | <MikeSmith> | still, 33% seems very high |
| 03:36 | <MikeSmith> | https://cdn.rawgit.com/operasoftware/devopera-static-backup/869f534a/http/dev.opera.com/articles/view/mama-head-structure/index.html#link |
| 03:36 | <MikeSmith> | https://cdn.rawgit.com/operasoftware/devopera-static-backup/869f534a/http/devfiles.myopera.com/articles/575/linkrellist-url.htm |
| 04:08 | <annevk> | Domenic: a merge commit often seems to involve all of master and is therefore not super clear, but I could be missing something |
| 04:10 | <Domenic> | annevk: I've seen at least some cases where it creates a single commit like "merged remote tracking branch origin/master" which basically includes all changes to master since the base point. If the merge is not trivial then that commit also includes changes made to reconcile. Then when you diff the whole result (pr commits + merge commit) against the current |
| 04:10 | <Domenic> | master, you see PR changes + changes made during the merge commit to reconcile with latest master |
| 05:56 | <annevk> | I guess I have to see one again to remember why that isn't quite what I want |
| 05:57 | <annevk> | Making rebasing work is usually a fairly trivial though easy to get wrong operation, but a merge commit doesn't really show it clearly as such |
| 05:59 | <annevk> | Domenic: you want to add null/false/true? |
| 06:00 | <Domenic> | annevk: not immediately; while in Tokyo focusing on streams + modules. But I can definitely take it in the next few weeks if you're not in a rush. |
| 06:00 | <Domenic> | What does servo use for xml? |
| 06:00 | <annevk> | Domenic: html5ever I think |
| 06:00 | <Domenic> | So no XML? |
| 06:01 | <annevk> | Domenic: "XML5", it's part of the same package |
| 06:01 | <annevk> | Domenic: reuses a bunch of logic |
| 06:02 | <Domenic> | Ah OK |
| 06:02 | <annevk> | Unfortunately WebKit doesn't seem interested in refactoring that code |
| 06:03 | <annevk> | I think Gecko would eventually replace its XML parser with something better |
| 06:03 | <Domenic> | Well we're not fans of libxml over in Blink either, /cc dominicc |
| 06:03 | <annevk> | If everyone did we'd have our HTML parser escape |
| 06:03 | <Domenic> | Constant security bugs |
| 06:03 | <Domenic> | So thinking about replacements |
| 06:04 | <annevk> | XML would end up winning after all, with a slight "HTML5" touch to remove its worst aspects |
| 06:04 | <Domenic> | cc nox |
| 06:04 | <Domenic> | It seems like there are several possibilities though https://crates.io/search?q=xml |
| 06:07 | <Domenic> | Hmm I'm not sure things like omitting <!DOCTYPE> entity substitution is web compatible |
| 06:07 | <annevk> | Domenic: XML5 handles that |
| 06:07 | <annevk> | At least the version I wrote originally |
| 06:07 | <Domenic> | Interesting, xml-rs does not |
| 06:08 | <annevk> | Oh, xml-rs seems like something else |
| 06:08 | <annevk> | I don't think Servo uses that |
| 06:09 | <Domenic> | Yeah, it's the most popular when searching for "xml" |
| 07:08 | <nox> | Domenic: We use xml5ever. |
| 07:09 | <nox> | Domenic: XML and Rust don't quite fit together for now. |
| 07:35 | <annevk> | Domenic: adding noncharacter to Infra seems fine, but note that it's only used for conformance requirements |
| 07:35 | <Domenic> | hmm |
| 07:36 | <Domenic> | seems fine I guess |
| 08:02 | <annevk> | Domenic: what platform feature is driving writable streams? |
| 08:02 | <Domenic> | annevk: mostly transform streams :) |
| 08:02 | <annevk> | Domenic: and those are driven by text encoding/decoding? |
| 08:02 | <tobie> | Domenic: catching up on extended attributes for types, my only concern is the lack of clarity as to whether the annotated types are types of their own or not. |
| 08:03 | <Domenic> | annevk: text is the easy case, but we have lots more lined up; gzip and media off the top of my head |
| 08:03 | <Domenic> | tobie: hmm I think I made it pretty clear they are? |
| 08:03 | <annevk> | Domenic: ta |
| 08:03 | <Domenic> | annevk: also https://streams.spec.whatwg.org/#example-pipe-as-chunks-receiver |
| 08:03 | <tobie> | Domenic: OK, I thought so, but then doesn't that affect the overload resolution algorithm? |
| 08:04 | <Domenic> | tobie: hmmm I guess I didn't consider that fully; I should check. |
| 08:04 | <tobie> | Domenic: I think the right thing to do would be to have something similar to inner types for nullables |
| 08:04 | <Domenic> | tobie: agreed |
| 08:05 | <Domenic> | nullable is the right model here |
| 08:05 | <tobie> | Domenic: and then just grab those in the overload resolution algorithm |
| 08:05 | <tobie> | Domenic: well, except the relation is a one to many here, not a one to one. |
| 08:06 | <tobie> | Domenic: plus you can have an annotated type which is also nullable, no? |
| 08:07 | <Domenic> | yeah, there's a general "inner type" concept hiding I guess |
| 08:07 | <Domenic> | ? suffix is just shorthand for [Nullable] prefix in this framework, at least conceptually. Probably not worth actually doing that though. |
| 08:07 | <tobie> | Domenic: oh! |
| 08:09 | <tobie> | Domenic: that seems like the right model. |
| 08:10 | <tobie> | Domenic: it also looks like quite a lot of work to rework. :-/ |
| 08:11 | <tobie> | Domenic: I think you'll need to figure out the relationship with inner type either way, though. |
| 08:11 | <tobie> | Domenic: Alright, I'll finish my review and send it over. |
| 08:12 | <tobie> | Domenic: I'm pretty confident given the various threads on this topic that we can land this once we fix this last thing |
| 08:13 | <tobie> | Domenic: and bz can file against the spec if he bumps on issues down the road |
| 08:14 | <Domenic> | tobie: sounds great, thanks so much for looking into it |
| 08:15 | <tobie> | Domenic: I should have done that a ling time ago. Apologies for not looking into it before. It looked sort of daunting tbh. |
| 08:16 | <MikeSmith> | zcorpan: wonder if you could please run a query for rel=canonical usage |
| 09:02 | <annevk> | If we get [Nullable] we might be able to start using [Undefinedable] too if there's still appetite for that |
| 09:02 | <annevk> | Although I guess we could already if we just had an undefined value |
| 09:03 | <annevk> | Domenic: why is ? not short for " or null"? |
| 09:03 | <Domenic> | annevk: it is but "or null" can be modeled in terms of [Nullable] applied to the type i.e. it creates a new type |
| 09:09 | <tobie> | Domenic: alright, pushed the review. |
| 09:11 | <Domenic> | Good review :). It's getting late in Tokyo so I'll work on it tomorrow. |
| 09:15 | <tobie> | Domenic: oh, that's where you are. Enjoy! |
| 10:20 | <zcorpan> | MikeSmith: yeah i'll do that now |
| 10:21 | <zcorpan> | MikeSmith: only on <link>? |
| 10:28 | <zcorpan> | MikeSmith: 278679 matches |
| 10:43 | <jochen__> | what spec defines how e.g. <xsl:import> loads resources in a browser? |
| 10:45 | <gsnedders> | jochen__: none does |
| 11:23 | <jochen__> | perfect :/ |
| 11:25 | <wanderview> | annevk: is there any discussion towards this "html modules" proposal here: https://github.com/dglazkov/webcomponents/blob/html-modules/proposals/HTML-Imports-and-ES-Modules.md |
| 11:26 | <wanderview> | basically building a system similar to html imports on es module loader infrastructure |
| 11:26 | <annevk> | wanderview: there was a discussion at TPAC, most folks expressed a desire for ES modules to get some adoption first before looking into it further |
| 11:27 | <wanderview> | annevk: ok, thanks |
| 11:27 | <annevk> | wanderview: note that it's unclear to me at this point that the Loader idea is going to make it, it might be that service workers is sufficient |
| 11:27 | <wanderview> | annevk: service workers is a replacement for html imports use case? |
| 11:27 | <annevk> | (assuming you were referring to that, and not JS module loading in general) |
| 11:28 | <annevk> | wanderview: just for the hooks defined by Loader |
| 11:28 | <annevk> | https://whatwg.github.io/loader/ |
| 11:28 | <wanderview> | annevk: the idea being that a service worker could synthesize the document with the stuff already in it? |
| 11:29 | <Domenic> | wanderview: annevk: kochi is interested in working on HTML modules |
| 11:29 | <annevk> | wanderview: I didn't mean to suggest service workers as a replacement for HTML modules, just for the hooks defined by Loader |
| 11:37 | <MikeSmith> | zcorpan: thanks |
| 11:37 | <MikeSmith> | zcorpan: 278679 matches out of what total? |
| 11:38 | <zcorpan> | MikeSmith: 17,103,665 resoures from 481,455 sites |
| 11:40 | <zcorpan> | MikeSmith: i guess you need to filter the results by unique `page` (or group by page) if you want to know the number of sites |
| 11:46 | <MikeSmith> | ok |
| 11:58 | <felixjet> | is there any <link> or <meta> tags that accepts content? |
| 11:58 | <felixjet> | like: <link>content</link> |
| 11:59 | <Domenic> | <a> |
| 12:08 | <Domenic> | I wonder where n1tm, our Gecko dialog implementer, went :( |
| 20:32 | <zcorpan> | gsnedders: \o/ |
| 20:48 | <zcorpan> | Domenic: maybe we should merge the logical props dialog change and tests without their sanity check |
| 20:56 | <TabAtkins> | tobie: Why are you and Yehuda suddenly so interested in that BlinkOn thread of mine? |
| 20:58 | <tobie> | dunno. just saw it now. |
| 20:58 | <tobie> | TabAtkins: thought it was current |
| 20:59 | <TabAtkins> | Ah, kk. |