| 07:32 | <annevk> | bakkot: I thought that when you detached a view its [[ByteLength]] would be 0? |
| 07:43 | <bakkot> | annevk: you detach buffers, not views |
| 07:44 | <bakkot> | detaching a buffer does indeed set its [[ArrayBufferByteLength]] to 0 but it doesn't reach out and also update the views of that buffer |
| 08:03 | <annevk> | bakkot: it seems implementations treat it as 0 so I guess we some kind of length getter that accounts for detachment |
| 08:03 | <annevk> | Assuming https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0As%20%3D%20new%20Uint8Array(new%20ArrayBuffer(8))%3B%0ApostMessage(s%2C%20%22*%22%2C%20%5Bs.buffer%5D)%3B%0Aw(new%20TextEncoder().encodeInto(%22fd%22%2C%20s))%3B%0A%3C%2Fscript%3E is a valid test |
| 09:25 | <annevk> | zcorpan: Can you help me understand https://github.com/web-platform-tests/wpt/blob/master/css/css-ui/compute-kind-widget-generated/kind-of-widget-fallback-checkbox-input-background-attachment-001.html and friends? If you disable the auto appearance, wouldn't you get appearance:none? But that's not what's expected. |
| 10:49 | <zcorpan> | annevk: sure. The test is correct, but the title is misleading/incorrect. |
| 10:52 | <zcorpan> | annevk: looks like the build script doesn't know what the pass condition should be, it's only in the reference. I can make the title not say what is expected |
| 11:03 | <zcorpan> | annevk: https://github.com/web-platform-tests/wpt/pull/44138 |
| 14:41 | <bkardell> | annevk: no pressure but just want to check that on https://github.com/whatwg/html/pull/9804 you are not waiting for me for something? It can get hard for me to follow these are all resolved, but I believe this is back to you now, right? |
| 15:05 | <bkardell> | thank you annevk |
| 16:05 | <annevk> | bakkot: hey so are you sure about ByteLength? That might be a bug as at least implementations do set it to 0 |
| 16:05 | <annevk> | bakkot: see https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0As%20%3D%20new%20Uint8Array(new%20ArrayBuffer(8))%3B%0Aw(s.buffer.byteLength)%0Aw(s.byteLength)%3B%0ApostMessage(s%2C%20%22*%22%2C%20%5Bs.buffer%5D)%3B%0Aw(s.buffer.byteLength)%0Aw(s.byteLength)%3B%0Aw(new%20TextEncoder().encodeInto(%22fd%22%2C%20s))%3B%0A%3C%2Fscript%3E |
| 16:14 | <annevk> | bakkot: https://tc39.es/ecma262/#sec-get-%typedarray%.prototype.bytelength suggests to me you're prolly wrong |
| 16:29 | <annevk> | Panos Astithas: it seems i18n might wanna discuss a number of things in Feb: https://github.com/w3c/i18n-activity/labels/Agenda%2BI18N%2BWHATWG |
| 23:39 | <Ari Entlich> | Hello all. I've identified a slight difference in behavior between Firefox and Chrome that is causing a health insurance website I use to malfunction in Firefox. The difference appears to be that, when the checkedness of a radio button is set (via the checked property), Firefox sets the dirty checkedness flag on all inputs in its radio button group, while Chrome does not. The reproduction is here: https://jsfiddle.net/9j6wcxqu/2/ . On Firefox, this testcase logs false false, while on Chrome it logs false true. I can't find any discussion of this. Does my assessment of the issue seem correct? If so, which behavior is more correct? I can't find any explicit statement in the spec supporting Firefox's behavior, but it might have some logic to it. |