| 00:00 | <smaug> | I'm not sure that is too vague, but "relative to the origin of the padding edge of the target node" |
| 00:01 | <smaug> | when is the calculation done |
| 00:02 | <smaug> | my interpretation is that there shouldn't be any caching, so when offset* is accessed, "relative to the origin of the padding edge of the target node" should be recalculated |
| 01:00 | <foolip> | yeah, that would make sense |
| 01:00 | <foolip> | to require it to be calculated at any specific time would mean that it has to be calculated even if not later used, so that wouldn't be great either |
| 05:46 | <MikeSmith> | the upvote/downvote pile-on pattern in https://github.com/gpuweb/admin/issues/1 is.. interesting |
| 05:49 | <MikeSmith> | github should add buttons with rage-comics emoji |
| 05:53 | <annevk> | Hmm, Chrome decides to communicate now that they don't want to actually implement trailer() |
| 05:53 | <annevk> | Thanks for letting me work out all the details fir st I guess |
| 06:07 | <foolip> | annevk: what's trailer()? |
| 06:07 | <foolip> | https://github.com/whatwg/fetch/issues/34? |
| 06:13 | <annevk> | foolip: oops, yeah, an attribute: https://fetch.spec.whatwg.org/#dom-response-trailer |
| 06:15 | <annevk> | foolip: I mean, Chrome raised the issue, Google infrastructure folks wants the feature, Chrome devrel (or is igrigorik an engineer?) advocated for the feature, Chrome engineers helped review the feature before it landed in the Fetch standard |
| 06:15 | <annevk> | foolip: and now some of the very same folks are suggesting to wontfix it the moment I file the bug report |
| 06:15 | <annevk> | I mean, it's fine, it's only a couple days at most of lost work, but still |
| 06:16 | <foolip> | igrigorik is on DevRel, yes |
| 06:17 | <foolip> | seems like rsleevi was quite clearly opposed all along, but that nobody else on Chrome worked out the situation with him? (just skimming the thread) |
| 06:18 | <annevk> | foolip: I would have expected a "we'll never implement" after https://github.com/whatwg/fetch/issues/34#issuecomment-235318684 |
| 06:18 | <annevk> | foolip: instead three Googlers help review https://github.com/whatwg/fetch/pull/344 |
| 06:22 | <foolip> | annevk: I've commented on https://bugs.chromium.org/p/chromium/issues/detail?id=691599#c4 |
| 06:24 | <foolip> | mkwst_: you seem like the perfect person to tell me what I should think about trailers and exposing them to the web. what are my thoughts? |
| 08:31 | <annevk> | hsivonen: did you see the issue I filed on the encoding detector in Chrome? |
| 08:31 | <annevk> | hsivonen: I'll study it later today and maybe comment |
| 08:31 | <annevk> | hsivonen: been some follow-up overnight apparently |
| 10:02 | <JakeA> | wanderview: ah, yeah, the SW parts haven't landed yet. I'll chase it |
| 10:31 | <zcorpan> | annevk: i checked the stackoverflow threads, and indeed it seems a lot people are running in to this issue, and the workarounds seem pretty messy... the least messy is maybe removing disabled onsubmit and adding it again after, but that results in a flash-of-enabled-controls... |
| 10:31 | <annevk> | zcorpan: it's also a rather trivial change to the processing algorithm, just need to decide on how to expose it |
| 10:32 | <annevk> | zcorpan: one thing that seemed rather nice to me was disabled="submit", but the API-side of that would be less clean |
| 10:32 | <zcorpan> | yeah i think we should have a new attribute |
| 10:33 | <zcorpan> | but "anyway" is not clear what it's referring to |
| 10:33 | <annevk> | zcorpan: I'm in favor I suppose of moving forward here, specifics hopefully sorted out by someone else |
| 10:33 | <zcorpan> | submitdisabled="" maybe |
| 10:33 | <annevk> | zcorpan: could also be a flag on <form> potentially |
| 10:33 | <zcorpan> | per-control is more flexible |
| 10:34 | <annevk> | disabled="submit" could work if you reflect it through disabledState |
| 10:35 | <zcorpan> | we also have <fieldset disabled> which is a bit special |
| 10:35 | <annevk> | Oh stuff inherits? |
| 10:35 | <annevk> | Hmm okay |
| 10:36 | <zcorpan> | inherits except into the <legend> |
| 10:47 | <zcorpan> | considering <fieldset disabled> i think it should be a separate attribute. you may want to toggle disabled for a whole fieldset, but always submit a specific control inside |
| 10:50 | <hsivonen> | annevk: thanks for filing the Chrome bug |
| 10:56 | <annevk> | zcorpan: wouldn't that still be possible though? |
| 10:57 | <annevk> | zcorpan: anyway, new attribute seems fine |
| 10:58 | <zcorpan> | annevk: you'd have to set both disabled on fieldset and disabled=submit on the specific control instead of only setting disabled on fieldset |
| 10:58 | <zcorpan> | (when toggling with script) |
| 10:59 | <annevk> | zcorpan: disabled on fieldset should be set either way, right? |
| 10:59 | <annevk> | zcorpan: and for the control you'll also need to toggle *something* either way |
| 11:00 | <zcorpan> | annevk: yes for the first question. i think no for the second question. let me show with markup what i mean so we're talking about the same case |
| 11:04 | <zcorpan> | annevk: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4891 |
| 11:07 | <annevk> | zcorpan: ah okay |
| 11:07 | <annevk> | zcorpan: pretty obvious indeed |
| 11:10 | zcorpan | finds 302 matches of '<fieldset(?:s[^>]+)?sdisabledb' in httparchive |
| 12:43 | <annevk> | hsivonen: so I think we should add a comment on the Chrome bug indicating what the rough situation in Gecko looks like now |
| 12:44 | <annevk> | hsivonen: with respect to Japanese and Cyrillic and what those mean in terms of labels |
| 12:44 | <annevk> | hsivonen: and hope that Chrome aligns with that (or a smaller set) |
| 12:45 | <annevk> | hsivonen: for Japanese it seems we want to sniff between EUC-JP and Shift_JIS |
| 12:45 | <annevk> | hsivonen: I don't recall the Cyrillic situation, but since you do, maybe you can comment? |
| 13:52 | <annevk> | hsivonen: I added a comment since I didn't want to forget about it |
| 18:06 | <annevk> | Domenic: dherman says you can find out Script vs ModuleScript |
| 18:06 | <annevk> | Domenic: or whatever the terminals are called |
| 18:06 | <Domenic> | annevk: CONTEXT? |
| 18:06 | <botie> | CONTEXT is https://github.com/validator/validator/issues/284 |
| 18:06 | <Domenic> | (capslock) |
| 19:41 | <annevk> | Domenic: context isn't so important, but it seems we could maybe use that instead of trying to change destination types and such |
| 19:41 | <Domenic> | annevk: I guess I don't really understand how that is possible; you know how things are to be parsed based on type="module" or not. |
| 19:42 | <annevk> | Domenic: hmm, if you run into him at TC39 ask? |
| 19:42 | <annevk> | Domenic: I could email too, tomorrow |
| 19:42 | <Domenic> | yeah, I won't be at TC39 until May most likely |