| 01:23 | <Hamish Willee> | Yoav Weiss: For Mozilla Developer Network docs, can you please confirm that the device client hints that disappeared from the spec after https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-06 are deprecated (were removed permanently from the spec and have not been moved elsewhere)? Specifically, Content-DPR, DPR, Viewport-Width, Width |
| 02:37 | <timothygu> | Hamish Willee: It was removed from the ID to be moved to other specs. See https://wicg.github.io/responsive-image-client-hints/ for the current spec for image-related client hints |
| 02:37 | <timothygu> | This is the PR that removed the features: https://github.com/httpwg/http-extensions/pull/775 |
| 04:17 | <timothygu> | @jakea:matrix.org Hey, I looked into the GC issue. I’ll comment on the crbug tomorrow, but I think it turns out to be pretty subtle, and may have also exposed a bug in MutationObserver |
| 04:18 | <Hamish Willee> | timothygu: Thanks very much! Can you confirm the summary of the changes:
As a slight aside, one of the examples in the spec appears to omit the SEC- prefix in the Accept-CH - is that OK?: |
| 04:22 | <timothygu> | @hamishwillee:matrix.org I don’t have any info beyond the links I sent, but it’s worth going through the PRs to that spec to understand historical changes. Re the example omission, you could file an issue on GitHub for clarification |
| 06:05 | <Jake Archibald> | @jakea:matrix.org Hey, I looked into the GC issue. I’ll comment on the crbug tomorrow, but I think it turns out to be pretty subtle, and may have also exposed a bug in MutationObserver |
| 07:24 | <Yoav Weiss> | Hamish Willee: The old header names are indeed deprecated in spec, but the Chromium implementation needs to catch up |
| 07:25 | <Yoav Weiss> | Content-DPR was somewhat replaced by https://github.com/whatwg/html/pull/5574 |
| 07:26 | <Yoav Weiss> | (but wasn't removed from Chromium AFAIK) |
| 07:26 | <Yoav Weiss> | Eric Portis (not in here, for some reason) is editing that spec. I believe PRs and corrections would be appreciated |
| 07:27 | <Hamish Willee> | Thanks Yoav Weiss - really helpful. I've created an issue for the problem case. I'm thinking this might be a little early to document for MDN, but am checking internally. Either way will link the old docs to the new spec in some way so that we have this information when ready to start. |
| 08:15 | <annevk> | sideshowbarker: what would be a short term fix for https://github.com/whatwg/encoding/issues/261? |
| 08:33 | <sideshowbarker> | sideshowbarker: what would be a short term fix for https://github.com/whatwg/encoding/issues/261? |
| 08:37 | <annevk> | sideshowbarker: yeah, I guess I can do that too |
| 08:41 | <sideshowbarker> | sideshowbarker: yeah, I guess I can do that too |
| 08:41 | <annevk> | sideshowbarker: I added .*Possible misuse of “aria-label”. (If you disagree with this warning, file an issue report or send e-mail to www-validator@w3.org.).* to .htmlcheckerfilter and it does not appear to work |
| 08:42 | <sideshowbarker> | Ok, I'll take a look at it in a bit |
| 09:06 | <sideshowbarker> | annevk: so yeah it was the parens |
| 09:07 | <sideshowbarker> | since it’s a regex, the parens need to be escaped |
| 09:07 | <sideshowbarker> | for the for record, alternately it can just be .*Possible misuse of “aria-label”.* |
| 09:07 | <sideshowbarker> | that is, it can match on just some portion of the message |
| 09:08 | <sideshowbarker> | it’s not strictly necessary to include the whole message |
| 09:11 | <annevk> | sideshowbarker: thanks, good to know for next time; perhaps we should document that somewhere |
| 09:12 | <sideshowbarker> | I have the general upstream documentation for the feature at https://github.com/validator/validator/wiki/Message-filtering |
| 09:13 | <sideshowbarker> | but that doesn’t provide enough detail I guess |
| 09:13 | <sideshowbarker> | it needs some examples |
| 09:13 | <sideshowbarker> | but anyway it’s wiki, so anybody can make changes to it |
| 09:33 | <annevk> | sideshowbarker: how quick is the filtering of warnings? I do get the impression the build times for Encoding are even worse now |
| 09:37 | <sideshowbarker> | I don't think the filtering adds any noticeable time to a build |
| 09:38 | <sideshowbarker> | That Encoding build has just always taken a long time, as far as I can recall |
| 09:54 | <Andreu Botella (he/they)> | annevk: https://github.com/whatwg/encoding/issues/261 should be closed now |
| 09:54 | <annevk> | Andreu Botella (he/they): should it? I think we still need to decide how to resolve that warning |
| 09:55 | Andreu Botella (he/they) | rereads the log |
| 09:55 | <Andreu Botella (he/they)> | oh, right |
| 13:39 | <sideshowbarker> | annevk: so as far the performance effects from the filtering of warnings: when I test locally with filtering on, it takes 4m16.409s to check all the Encoding documents — but when when test without the filtering, it takes 9m31.435s |
| 13:40 | <sideshowbarker> | that is, with the filtering on, it’s not slower but actually more than twice as fast |
| 13:42 | <sideshowbarker> | well that kind of makes sense to me intuitively, because without the filtering there are literally thousands of warnings getting dumped out — and there’s a system I/O cost to emitting all those, and prior to that, some internal cost to formatting them all for output |
| 13:46 | <annevk> | yeah agreed, I guess what I'm wondering if what the cost for hitting the warning is, even if the warning ends up getting filtered |
| 13:46 | <annevk> | because we hit it a lot |
| 13:46 | <sideshowbarker> | yeah |
| 13:48 | <sideshowbarker> | well, given that the accessibility people have said that putting aria-label on td elements is not good for AT users in current AT, it seems like rightly what we should be doing is, not putting aria-label on all those td elements |
| 13:53 | <annevk> | sideshowbarker: it would be good to know what to do instead though |
| 13:55 | <sideshowbarker> | it seems like one possibility is that there actually isn’t anything to do instead |
| 13:55 | <sideshowbarker> | that is, we drop the attributes and don’t replace them with anything else |
| 13:56 | <sideshowbarker> | there are some limitations in AT that it’s not within our domain knowledge to figure out how to overcome |
| 13:57 | <sideshowbarker> | there are people whose full-time occupation is figuring out how to solve problems like this for paying customers |
| 13:58 | <sideshowbarker> | I seem to recall having Cc’ed somebody on that issue, but we didn’t get any specific suggestions from them about how to fix it |
| 14:11 | <jgraham> | Wait, what, you're saving 4 minutes just not outputting warnings? Terminals must surely allow output at at least 1-10Mb/s, which suggests like 240Mb-2.4Gb of output, if that was the main bottleneck. |
| 14:12 | <annevk> | jgraham: we're talking about a lot of non-conforming table cells here, so it wouldn't surprise me |
| 14:12 | <DerekNonGeneric> | sideshowbarker: there is plenty more info wrt table a11y in this section for the gridcell role https://www.w3.org/TR/wai-aria-1.1/#gridcell |
| 14:14 | <DerekNonGeneric> | depending on the table, role="rowheader" and scope="row" may be necessary too |
| 14:15 | <DerekNonGeneric> | government websites are mandated by law to provide AT support nowadays |
| 14:15 | <DerekNonGeneric> | well, at least there were several laws passed in the US about it |
| 14:17 | <annevk> | The question is how to convey the type-identifying background color in table such as https://encoding.spec.whatwg.org/windows-1252.html |
| 14:20 | <jgraham> | 240Mb of warnings would be > 3kB of output per BMP character. Not impossible of course, but quite a lot. It's of course also possible that something internally is really slow so the estimate of 1Mb/s of output is high. But it at least feels suspicious when something is that slow. |
| 14:23 | <annevk> | jgraham: well, but each encoding has a BMP table, plus at least one other table |
| 14:23 | <annevk> | There might still be something wrong, but there's definitely a lot of output as well |
| 14:24 | <DerekNonGeneric> | annevk: hmm, you may want to look into aria-describedby and move the legend (key) onto the same document https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Gridcell_role#describing_the_position_of_gridcells_when_the_overall_structure_is_unknown |
| 14:27 | <DerekNonGeneric> |
The
|
| 14:31 | <annevk> | But that isn't entirely true either right? The headers do provide information about the cell. They just don't convey this other information that's really a property of the contents of the cell. |
| 14:34 | <DerekNonGeneric> | The headers do provide information about the cell. |
| 14:35 | <DerekNonGeneric> | that does not appear to be the case |
| 14:36 | <DerekNonGeneric> | the headers are simply numbers, but i do see that there aria-label="Two bytes, contiguous" on each cell, which was probably done seeing as how the key is on another page and the headers don't provide any descriptive info whatsoever afaik |
| 14:37 | <annevk> | They are numbers, yes, but in the context of encodings they are highly relevant |
| 14:39 | <DerekNonGeneric> | oh, okay well it's an interesting problem and that is one of the most funky tables i have ever seen (definition list w/ one item in it per cell) lol |
| 14:42 | <DerekNonGeneric> | it reminds me a lot of a periodic table of the elements |
| 14:43 | <DerekNonGeneric> | surely someone has made one of those w/ full a11y support; perhaps that would be a good way to see how it's done |
| 14:52 | <DerekNonGeneric> | annevk: ohh this one looks promising! it has an aria-labelledby attribute referencing some id of an item in the legend http://dylanb.github.io/periodic-aria-roles.html |
| 14:53 | <annevk> | DerekNonGeneric: but that doesn't have meaningful row/column headers |
| 14:54 | <DerekNonGeneric> | i thought that you could not use headers for some reason? |
| 14:54 | <DerekNonGeneric> | obviously that would be the best way to do it if you can |
| 14:56 | <DerekNonGeneric> | well, not sure if the numbers in the current header are what you had in mind |
| 15:06 | <DerekNonGeneric> | wow, til that there is even headers attribute that you can use to specify multiple headers in the event that the table is more complex https://www.davidmacd.com/blog/csun/files/complex-tables.html |
| 15:14 | <DerekNonGeneric> | that table is missing a lot of things, at the very least you should add scope="row" to the th that are in the tbody element (!) |
| 15:20 | <annevk> | I'm pretty sure that the scope of the headers is correct per the HTML Standard, a bunch of that doesn't have to be explicitly stated |
| 15:40 | <DerekNonGeneric> | surely the markup is valid, not saying it's not, but w/o specifying the scope as row, i don't think those headers will be describing the data in the row... might also want to check out what the spec says, since it doesn't look like that somehow gets autodetected https://html.spec.whatwg.org/multipage/tables.html#attr-th-scope-row |
| 17:22 | <annevk> | If you keep reading you'll get to it |
| 17:31 | <DerekNonGeneric> | is it the part about the
thought that the part in the example that states:
was only commentary applicable to that example? please send me a 🔗 to that part if you can 😅 i read so much of it already 🥵 |
| 17:40 | <DerekNonGeneric> | please send a link -- i read it quite thoroughly; 🥵 if it was stated, i don't think it was clear |
| 21:21 | <Thomas Sikma> | #®Ωγ |
| 21:21 | <Thomas Sikma> | #jems ? |
| 22:09 | <sideshowbarker> | jgraham: 466MB total, 2,134,130 messages is the output from running the checker on those Encoding files |
| 22:09 | <sideshowbarker> | as unbelievable as that may sound |
| 22:12 | <sideshowbarker> | and that’s basically the same message 2,134,130 times (there are a few other messages it emits that I’m not filtering out locally) |
| 22:14 | <sideshowbarker> | and I think due to the way the code is written, that message string isn’t even getting interned |
| 22:17 | <sideshowbarker> | I guess for the general behavior of the checker, interning or not of messages wouldn’t make any noticeable performance difference in the normal case. But it seems like it would in this case. |
| 22:51 | <Andreu Botella (he/they)> | When WebIDL says to get a copy of the bytes held by a buffer source, the actual "getting a copy of the bytes" part is not formalized in terms of the ECMAScript spec operations |
| 22:52 | <Andreu Botella (he/they)> | and so it's not clear if for [AllowShared] BufferSources, that copy should be raw or atomic |
| 23:06 | <Domenic> | Andreu Botella (he/they): https://github.com/heycam/webidl/pull/987 |
| 23:07 | <Andreu Botella (he/they)> | I went looking for issues, not PRs 🤦 |
| 23:15 | <Andreu Botella (he/they)> | Domenic: So copies and writes are unordered, and WebIDL doesn't provide anything to make them SeqCst? |
| 23:45 | <etportis> | @hamishwillee:matrix.org Just replied to your responsive image client hints questions on GH (thanks for the issues!). Your three-bullet summary of the changes looks accurate. I'll be around here going forward, if you have questions about the spec. |