02:36 | <sideshowbarker> | annevk: https://twitter.com/jub0bs/status/1432025056234835980 |
06:00 | <freddy> | that's what we call a "simple request" though, isn't it? Also looking at https://twitter.com/bcrypt/status/1422243807328804882 and responses in the thread (e.g., https://twitter.com/shhnjk/status/1423013294860767237) |
06:28 | <sideshowbarker> | freddy: yeah I know;
…but I think in practice there are many servers that have broken content-type handling for JSON |
06:30 | <annevk> | sideshowbarker: that's been known for ages I think, there's an open issue against the specification about it |
06:31 | <sideshowbarker> | ah OK |
06:32 | <sideshowbarker> | well I guess a similar real-world case is maybe https://stackoverflow.com/a/45752919/441757 |
06:33 | <annevk> | sideshowbarker: text/plain; application/json isn't actually the evil example, https://github.com/whatwg/fetch/issues/838 has the worse attacks |
06:33 | sideshowbarker | looks |
06:33 | <sideshowbarker> | aha |
06:33 | <annevk> | The only complete solution here would be for the browser to take ownership of setting Content-Type, but I think that ends up breaking things, but it could be tried again I suppose |
06:35 | <annevk> | stephanluis: writing a polyfill or library and making it popular is often the first step toward something becoming part of the platform. This doesn't work for all features, but it would work for a duration input box. |
06:36 | <sideshowbarker> | The only complete solution here would be for the browser to take ownership of setting Content-Type, but I think that ends up breaking things, but it could be tried again I suppose |
06:37 | <sideshowbarker> | …like CORB but from the client side — for requests rather than responses |
06:38 | <annevk> | sideshowbarker: we cannot tell the type of a body |
06:38 | <sideshowbarker> | ah OK |
06:39 | <annevk> | I guess we could try to parse all bodies to see if they are JSON, but I'm pretty sure rejecting those would break the web at this point |
06:39 | <sideshowbarker> | yeah, parsing the bodies is what I had in mind, and yeah I think it would definitely break a lot people’s stuff |
06:40 | <sideshowbarker> | e.g., it would break requests to the Slack API from frontend code, as in that https://stackoverflow.com/a/45752919/441757 case |
06:43 | <sideshowbarker> | anyway, I’m not on Twitter so I can’t reply myself to that https://twitter.com/jub0bs/status/1432025056234835980 tweet. But if somebody cares to take the time, might be worthwhile to reply to that tweet with a link to https://github.com/whatwg/fetch/issues/838 |
08:22 | <freddy> | annevk: in a URL, how would you call a hostname that does not contain any dots? bare hostname? non-dotted hostname? I was looking for "prior" art in our UriFixup files and the whatwg url spec, but found none. |
08:27 | <annevk> | freddy: maybe a single-label domain, but we don't have solid terminology at that level |
08:28 | <annevk> | freddy: and I'm also not sure if people would consider x. a two-label domain; probably more a single-label-domain-with-trailing-dot |
08:29 | <annevk> | sideshowbarker: btw, I ended up not replying as they mostly figured it out themselves and the person posting had it from 2018 research; can't 386 them all |
08:46 | <sideshowbarker> | ah OK |
08:55 | <freddy> | annevk: Thanks :) |
09:19 | <stephanluis> | * stephanluis: writing a polyfill or library and making it popular is often the first step toward something becoming part of the platform. This doesn't work for all features, but it would work for a duration input box. |
09:24 | <stephanluis> |
annevk: So what's the best way to structure the polyfill? I'd like to keep all the functionality of the time input, but make all browsers use a 24h clock so that can be used as a twenty-four hour duration input. 'Phase 2' would be deciding how to represent days and that would be to either expand hours beyond 24 or have days:hours:min:sec.microsec . I think 24 hour days are universal!!?? |
09:28 | <stephanluis> | annevk: how do you recommend commandeering the time input? or do you think I should use another strategy? |
09:54 | <annevk> | stephanluis: not sure, if I were to work on this I'd probably look at existing libraries to get some inspiration |
09:56 | <dbaron> | (I think my client is telling me someone mentioned me in this channel, but it's not up to usefully telling me how many pages up that mention is...) |
09:57 | <Ms2ger 💉💉> | If you use the web client, there's a bell icon in the top right corner |
09:57 | <sideshowbarker> | dbaron: that was me, I think — at https://matrixlogs.bakkot.com/WHATWG/2021-09-02#L23 |
09:58 | <dbaron> | Ms2ger 💉💉: yeah, I clicked that but it takes me to the wrong place, as usual |
09:58 | <stephanluis> | annevk: I have, they're pretty dismal I think this is the best https://nadchif.github.io/html-duration-picker.js/ ... the control requires additional buttons and looses the most of the key functions present for time input. So haven't looked at the source. |
10:02 | <stephanluis> | https://dan503.github.io/time-input-polyfill/ initially looked more promising, but ran into problems with that too. Can't remember exactly what it was, looked at it a while ago. |
10:04 | <stephanluis> | I think the problem was that it the polyfill didn't handle milliseconds. |
10:24 | <stephanluis> | Having had another look at the Time Input Polyfill I may be able to start with that. Will keep you updated. Still feel that duration input should probably be in the standard as it's the 'universal'/ not region or language dependant part of a time input ! |
17:28 | <sideshowbarker> | TabAtkins: about https://github.com/tabatkins/bikeshed/pull/2094 is there something more I should do there before we can move forward with what you outlined in https://github.com/tabatkins/bikeshed/pull/2094#issuecomment-873145774 ? |
17:38 | <TabAtkins> | sideshowbarker: No, with those changes I'd be happy to accept the PR. |
17:39 | <sideshowbarker> | oh, then I guess I’m not clear on how to actually make those changes |
17:41 | <sideshowbarker> | I’ll need to go back and look at it |
17:43 | <sideshowbarker> | e.g., for “Formalize domintro sections a little bit more, ensuring they're fit for this purpose” I wasn’t sure if that concretely amounted just to “Require an ID on them, and visibly expose that anchor like we do for headings and such, so it's easy to spot what should be linked to”, or if there was something more than just that which you had in mind |
22:29 | <DerekNonGeneric> | sideshowbarker: is #css on irc.w3.org still a thing or has that channel been bridged to somewhere else? (have some questions about how CSS modules being imported to JS should behave) |
22:34 | <DerekNonGeneric> | /cc maybe TabAtkins where do my CSS questions go? 😄 |
22:35 | <TabAtkins> | The W3C still operates its chat rooms, feel free to ask there |
22:35 | <TabAtkins> | sideshowbarker: Nope, that's what I meant. ^_^ |
22:37 | <DerekNonGeneric> | cool, my question is there -- hope it doesn't seem obnoxious, but aside from MIME types, not sure what else JS is expected to do w/ an imported CSS file |
22:41 | <DerekNonGeneric> | (even JS has no idea about MIME types, but what should be asserted is confusing me) |
23:24 | <GPHemsley> | are there any Edge developers in here? |