| 00:42 | <TabAtkins> | Domenic: BTW, I was looking at FormData and noticed the passive-aggressive note (^_^) and realized you can get around what Bikeshed's angry about and get the overloads to have the same argument name again. |
| 00:42 | <TabAtkins> | If you instead use: |
| 00:42 | <TabAtkins> | interface FormData { |
| 00:42 | <TabAtkins> | void append(USVString name, USVString value); |
| 00:42 | <TabAtkins> | void append(USVString name, Blob blobValue, optional USVString filename); |
| 00:42 | <TabAtkins> | } |
| 00:43 | <TabAtkins> | Ugh, sorry, bad copy-paste. One sec. |
| 00:44 | <TabAtkins> | interface FormData { |
| 00:44 | <TabAtkins> | void foo(USVString name, (USVString or Blob) value); |
| 00:44 | <TabAtkins> | void foo(USVString name, Blob value, USVString filename); |
| 00:44 | <TabAtkins> | }; |
| 00:44 | <TabAtkins> | There we go. Same meaning, but the signatures no longer clash. |
| 02:50 | <Domenic> | annevk ^ |
| 03:53 | <MikeSmith> | TabAtkins: about https://github.com/w3c/csswg-drafts/pull/2169 as I just noted in my comment there, the problem remains that the CSS Align spec as currently written doesn’t define align-items: left and align-items: right as valid |
| 03:54 | <TabAtkins> | MikeSmith: I'm confused. As I said, we *don't* want them to be valid in align-items. |
| 03:59 | <MikeSmith> | TabAtkins: ah I was assuming what you had told me previously here was true |
| 03:59 | <MikeSmith> | https://freenode.logbot.info/whatwg/20180104#c1392608 |
| 03:59 | <TabAtkins> | Nah man, I wrote the comment about consulting with fantasai *after* I told you the opposite here in chat. ^_^ |
| 04:00 | <MikeSmith> | got it |
| 04:00 | <MikeSmith> | thanks |
| 06:59 | <annevk> | Domenic: TabAtkins: that is not semantically equivalent when passing undefined as the third parameter |
| 06:59 | <annevk> | Domenic: TabAtkins: another strong reason for fixing Bikeshed as I really hope folks are not working around Bikeshed in the way you suggest and moving away from idiomatic JavaScript |
| 06:59 | <TabAtkins> | Ah, indeed. Nm then. |
| 07:00 | <TabAtkins> | No, everyone else who's ever dealt with overloads and told me about it has been fine with making the argument names different. |
| 07:02 | <annevk> | That doesn't make it okay... |
| 07:02 | <TabAtkins> | There's no way to "fix" Bikeshed here. Tons of specs depend on Bikeshed recognizing things according to the argument names. The most I could do is add a completely separate linking strategy that autolinks based on argument types instead, and figure out some way to syntactically distinguish that from referring to argument names. And you wouldn't use it except in these precise two instances. |
| 07:02 | <TabAtkins> | (Since almost all of the time, you can instead get away with autolinking without args at all.) |
| 07:03 | <annevk> | That is true, ideally there's no overloads to begin with |
| 07:03 | <TabAtkins> | Overloads are just frustrating, is what I'm saying. |
| 07:14 | <MikeSmith> | annevk: added some outline-relevant use counters to the checker |
| 07:15 | <MikeSmith> | https://validator.w3.org/nu/stats.html |
| 09:02 | <annevk> | MikeSmith: 0.245 means 25%? |
| 09:02 | <annevk> | MikeSmith: that'd be a lot of <h1> usage |
| 09:05 | <MikeSmith> | annevk: yeah, 25% |
| 09:11 | <annevk> | If those documents also use <section> and <article> there'd be a lot of potential for improvement there AT-wise |
| 09:14 | <MikeSmith> | I can probably add a more granular use counter, to check if more than one <section> element is open at the point where it finds an additional <h1> |
| 09:15 | <annevk> | MikeSmith: ideal would be article, aside, nav, or section |
| 11:07 | <annevk> | smaug____: does https://github.com/whatwg/html/issues/3407 address your concerns with hit regions? |
| 12:08 | <smaug____> | I need to page in hit regions to my mind |
| 12:11 | <annevk> | smaug____: https://github.com/whatwg/html/issues/1030#issuecomment-208989397 had some of your thoughts on the previous iteration, if that helps |
| 14:28 | <wanderview> | JakeA: ah... i thought I saw something about devrel all being in SF, so thought maybe we lapped the planet and were back |
| 14:29 | <wanderview> | ^we^you |
| 14:47 | <wanderview> | annevk: do you know why FetchEvent.clientId might have gone from null to empty string for indicating "no client id"? Is that conforming to an overall spec convention or something? |
| 14:49 | <annevk> | wanderview: I'm not sure; I might have argued that if it cannot be the empty string it always being a string seeming nicer |
| 14:49 | <wanderview> | ok |
| 16:58 | <jyasskin> | annevk/hsivonen: Can you give me a clue about how a metaformat should specify its error handling? It's tricky because not all formats based on CBOR will be happy with the web's "stop on error" policy. I'm kinda hopeful I can land a patch to CBORbis that allows formats to either stream output or return a full item at once, and either stop on error or replace the offending item and resume at a defined byte. Is that good |
| 16:58 | <jyasskin> | enough? |
| 17:14 | <annevk> | jyasskin: basically you need to have an answer for any arbitrary byte sequence |
| 17:14 | <annevk> | jyasskin: I don't really know CBOR so it's hard to go into specifics |
| 17:16 | <annevk> | jyasskin: I think ideally if there's some kind of subsetting going on that's made explicit by parser choices |
| 17:16 | <annevk> | jyasskin: so you'd invoke the CBOR parser with "streaming" and "stop on error" or some such and then everything ends up being well-defined |
| 17:16 | <annevk> | jyasskin: does that make sense? |
| 17:18 | <jyasskin> | annevk: Ok, cool. Yep, that should be straightforward. |
| 17:18 | <jyasskin> | Thanks! |
| 17:28 | <annevk> | Domenic: pushed a small commit to the data: URL tests that writes out the full MIME type everywhere |
| 17:28 | <annevk> | Domenic: if you r+ I'm gonna land all the things and see if I need any new browser bugs |
| 23:22 | <MikeSmith> | annevk: added more-granular stats https://validator.w3.org/nu/stats.html |
| 23:23 | <MikeSmith> | the 25% for multiple h1 that it was showing previously was due to a mistake in the initial logic that is now corrected |
| 23:24 | <MikeSmith> | the percentage of documents with multiple h1s appears to in fact be quite lower |
| 23:25 | <MikeSmith> | more like only 4% or 5% |
| 23:25 | <MikeSmith> | but anyway we should get data through other means to compare that against |
| 23:26 | <MikeSmith> | I think Steve may already have data on multiple h1 too. Or at least he has a corpus he can run a query on |
| 23:26 | <MikeSmith> | and maybe foolip can run one |
| 23:34 | <MikeSmith> | note that maybe should instead be made to count h1s with section/article/aside/nav ancestors rather than just parents |
| 23:35 | <MikeSmith> | because I notice that there are cases where the document has thigns like <section><div>h1 or <section><header><h1> |
| 23:37 | <MikeSmith> | also noticing more cases than I would have expected of multiple h1 without any section/article etc at all, but instead the document just uses nested <div>s with h1s at arbitrary levels |
| 23:38 | <a-ja> | MikeSmith, curious as to how expensive enabling outlines by default would be |