| 01:21 | <MikeSmith> | CZ |
| 05:22 | <botie> | zcorpan, at 2017-06-25 09:26 UTC, MikeSmith said: should the checker not report an error for `&;`? https://github.com/validator/validator/issues/529 |
| 05:49 | <MikeSmith> | of course nm that zcorpan |
| 05:49 | <MikeSmith> | very old |
| 05:50 | <zcorpan> | Yeah, saw it was resolved already |
| 07:31 | <annevk> | smaug____: https://github.com/whatwg/html/issues/2710 |
| 07:35 | <annevk> | zcorpan: would you have time to review the WPT changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1389274? |
| 07:35 | <annevk> | zcorpan: I'll have a look as well, but it seems you'd know more about how that method works at this point than I do |
| 07:40 | <annevk> | zcorpan: I think the specification is wrong actually |
| 07:59 | <zcorpan> | annevk: https://github.com/w3c/csswg-drafts/pull/1505 is probably relevant |
| 08:00 | <annevk> | zcorpan: making omitted and undefined different is pretty grotesque |
| 08:00 | <annevk> | zcorpan: there's only a couple of legacy APIs that need that |
| 08:01 | <zcorpan> | annevk: the new change makes them not be different |
| 08:02 | <annevk> | zcorpan: sorry, I assumed false was the default |
| 08:02 | <annevk> | zcorpan: are the dictionary defaults also the same as passing true? |
| 08:03 | <zcorpan> | annevk: no, they are not. {} is center-center, rationale is that center-center is a common case so there should be a convenient way to do that |
| 08:04 | <tobie> | zcorpan: the boolean's there for backwards compat, right? |
| 08:04 | <zcorpan> | annevk: but i think this is not yet interoperable so there is still room to change it |
| 08:04 | <zcorpan> | tobie: yeah |
| 08:05 | <annevk> | zcorpan: shouldn't you have gone with a bunch of enum values then if you wanted convenience? |
| 08:05 | <tobie> | zcorpan: I was just wondering if it might be worth keeping it as two overloading methods for the sake of pointing that out. |
| 08:06 | <annevk> | zcorpan: I don't think it's a good idea that for some APIs {} is magical and gives you different defaults than undefined |
| 08:06 | <annevk> | tobie: overloading is generally best avoided imo |
| 08:06 | <annevk> | tobie: it just leads to confusing argument handling, especially around omission and undefined |
| 08:07 | <tobie> | annevk: oh, that's a good point. I was just going for the split legacy stuff from non-legacy stuff. But maybe that causes more issues than it solves. |
| 08:07 | <zcorpan> | annevk: an enum argument isn't as extensible as a dictionary |
| 08:08 | <zcorpan> | annevk: personally i think i would prefer if {} means the same as passing true |
| 08:08 | <tobie> | zcorpan: are you suggesting there's a finite number of strings? |
| 08:08 | tobie | ducks |
| 08:08 | <annevk> | zcorpan: that's true, but if there's also a low-level pixel instruction set you might not need much high-level flexibility |
| 08:09 | <annevk> | zcorpan: I think you should make that change, having this API be different from others for the sake of convenience for the couple of folks that remember it's different isn't worth it |
| 08:10 | <zcorpan> | annevk: ok. i'll follow up. thanks |
| 08:10 | <annevk> | zcorpan: I filed https://github.com/w3c/csswg-drafts/issues/1720 btw |
| 08:28 | <annevk> | zcorpan: also filed https://github.com/w3ctag/design-principles/issues/73 to get this all covered in the design principles |
| 08:29 | <zcorpan> | annevk: thanks. I just finished drafting an issue, I'll comment it in your issue instead :-) |
| 09:21 | <annevk> | Hmm, could it be that atob(_X_) and data:;base64,_X_ are identical? |
| 09:22 | <annevk> | The YQ and YR examples from atob() produce identical results |
| 09:26 | <annevk> | Browsers actually using a shared primitive is somewhat surprising |
| 09:31 | <annevk> | Wow, it seems shared |
| 09:31 | <annevk> | Hurray? |
| 09:44 | <annevk> | beverloo: is https://github.com/whatwg/html/issues/351 still something you want to pursue? |
| 09:52 | <annevk> | TimothyGu: btw, as a reference, html/webappapis/atob/base64.html has 370 tests for btoa/atob; so a hundred or so tests could be just for base64 handling |
| 10:09 | <zcorpan> | https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8536472/ ๐ (Align the innerText setter with the spec and Gecko FIXED, FLIGHTED) |
| 10:18 | <Ms2ger> | I wonder who "Simon P." and "Arron E." are |
| 10:25 | <zcorpan> | Simon P. would be me |
| 10:28 | <jgraham> | zcorpan: If only they had waited another 8 days |
| 10:29 | <Ms2ger> | Or four |
| 10:31 | <zcorpan> | I guess Arron E. is https://github.com/arronei |
| 10:33 | <zcorpan> | jgraham: why? |
| 10:33 | <jgraham> | zcorpan: Just so it took exactly one year from filing to fixing |
| 10:34 | <Ms2ger> | Is it showing different dates to you? |
| 10:35 | <JakeA> | annevk: thinking more about this AbortSignal thing. It still feels like firing the event before the algorithms makes sense. This would match other events like "click" where the event comes before the default action. |
| 10:37 | <annevk> | JakeA: you mean that when the event needs to be forwarded it fires later on the signal that forwarded it? |
| 10:37 | <annevk> | JakeA: I'm fine with the current behavior, I was mostly wondering whether we should run it by some other people |
| 10:38 | <annevk> | JakeA: I'm okay with just going for it and having at least one test and attempt to revisit if it's a fatal issue somehow (which seems doubtful) |
| 10:39 | <JakeA> | annevk: I'll create an issue for it. Any idea who to cc? mkwst & jyasskin as they're the other users of AbortSignal I guess |
| 10:41 | <annevk> | JakeA: Domenic and maybe bterlson and wycats? |
| 10:41 | <JakeA> | ta |
| 10:49 | <jgraham> | Ms2ger: I saw filed on the 18th and fixed on the 10th |
| 10:50 | <Ms2ger> | Doh |
| 10:50 | <zcorpan> | foolip: thanks for taking care of DOMRectList PRs |
| 11:07 | <mkwst> | JakeA: Short answer: I don't have strong feelings about the timing semantics of the signal. I think your suggestion around timing makes sense, but I think WebAuthn will be fine either way. |
| 11:08 | <mkwst> | So, +1 to consistency, but I'm happy to defer to folks with opinions if there's a good reason for the current ordering. |
| 11:10 | <JakeA> | mkwst: ta! |
| 11:11 | <mkwst> | While I'm here: annevk, how would you feel about not treating `gopher` as a totally special scheme anymore? |
| 11:12 | <annevk> | mkwst: doesn't seem worth the churn, but okay if everyone wants that |
| 11:14 | <mkwst> | annevk: Sounds reasonable. It's not a valuable change in any real sense, but I don't like that Chrome's URL library has special cases for `gopher`. It would be nicer to remove them, given that we're never ever going to add support for the underlying protocol. |
| 11:15 | <annevk> | mkwst: yeah, I never quite understood why that existed to be fair |
| 11:24 | <TimothyGu> | annevk: wow, I mean thanks |
| 11:29 | <jgraham> | annevk: Want to approve https://github.com/w3c/web-platform-tests/pull/6858 ? |
| 11:30 | <hsivonen> | MikeSmith: if https://lists.w3.org/Archives/Public/public-review-announce/2017Aug/0004.html passes, are you going to trim http://www.w3.org/1999/xhtml ? |
| 11:32 | <foolip> | zcorpan: no problem, and welcome back! |
| 11:33 | <zcorpan> | thanks |
| 11:35 | <foolip> | zcorpan: wanna stamp https://github.com/w3c/web-platform-tests/pull/6870? |
| 11:36 | <zcorpan> | done |
| 11:37 | <foolip> | zcorpan: tack |
| 11:38 | <annevk> | jgraham: I rejected it |
| 11:39 | <jgraham> | annevk: That's fine too |
| 11:39 | <annevk> | good ๐ |
| 11:40 | <annevk> | hsivonen: that namespace document should also have a big fat warning not to copy the address bar |
| 11:41 | <annevk> | hsivonen: otherwise it goes pretty quickly from follow your nose to fall on your nose |
| 11:42 | <hsivonen> | annevk: indeed! |
| 11:44 | <annevk> | JakeA: can you squash and merge yourself these days? |
| 11:44 | <annevk> | JakeA: https://github.com/w3c/web-platform-tests/pull/6736 is good to go, just needs a new commit title/body |
| 11:45 | <JakeA> | annevk: I can! |
| 11:45 | <JakeA> | Will do that now |
| 11:53 | <hsivonen> | annevk: FWIW, telemetry says that on Firefox release 55, of 4.9 million sessions opted into opt-in telemetry, 714 had the ISO-2022-JP decoder instantiated at least once |
| 11:54 | <hsivonen> | annevk: well, at least it's more than <isindex>... |
| 11:54 | <annevk> | hsivonen: between 0.01 and 0.02% if I did that right |
| 11:54 | <annevk> | hsivonen: seems above treshold |
| 11:56 | <hsivonen> | annevk: what's the threshold? |
| 11:59 | <annevk> | hsivonen: for Chrome it's 0.003% iirc, but I believe they stopped using that (not sure in favor of what, but likely more conservative) |
| 12:00 | <annevk> | hsivonen: I don't think Mozilla has a number |
| 12:00 | <hsivonen> | annevk: ok |
| 12:10 | <zcorpan> | annevk: in favor of better understanding of compat impact. in some cases things can be successfully removed with higher usage. usage number alone is not enough information |
| 12:44 | <annevk> | TimothyGu: make sure to add yourself to https://heycam.github.io/webidl/#acknowledgements next time |
| 12:45 | <annevk> | TimothyGu: and maybe fix the glaring Oxford comma bug while there |
| 13:25 | <TimothyGu> | annevk: okay I will |
| 13:27 | <annevk> | TimothyGu: https://gist.github.com/annevk/4287452653921b2b7de35e4208b4a985 now has some draft text for data URL processing |
| 13:27 | <annevk> | TimothyGu: need to clean it up a bit still and decide where to put it |
| 13:42 | <TimothyGu> | annevk: why is ;base64 only searched at the end of the mime type? e.g. data:text/plain;base64;charset=UTF-8,5Lit5paH works in Chrome and Firefox |
| 13:44 | <annevk> | TimothyGu: oh, I thought that only worked in a subset of UAs |
| 13:44 | <annevk> | TimothyGu: should have tested first I guess |
| 13:45 | <annevk> | TimothyGu: it doesn't work in Safari |
| 13:45 | <TimothyGu> | to be exact firefox ignores anything that comes after ;base64 in that case, but it still reads the data in base64 |
| 13:45 | <TimothyGu> | :( |
| 13:46 | <annevk> | TimothyGu: the RFC also requires it to be last |
| 13:46 | annevk | writes test that can run in Edge |
| 13:47 | <TimothyGu> | yay more incompatibility |
| 13:48 | <annevk> | TimothyGu: Edge supports it |
| 13:48 | <MikeSmith> | hsivonen: Iโve not been involved at all with the https://lists.w3.org/Archives/Public/public-review-announce/2017Aug/0004.html plans so I donโt know if they include trimming http://www.w3.org/1999/xhtml |
| 13:49 | <annevk> | TimothyGu: supporting that is worse though as there's much more edge cases that way |
| 13:50 | <TimothyGu> | yeah well, too bad most browsers already support it |
| 13:51 | <annevk> | I hope they don't substring |
| 13:51 | <annevk> | Not sure what to do then |
| 13:55 | <AutomatedTester> | annevk: hey, got a weird case and need your thoughts. What would a property return on an element when its in a data url like data:text/html;charset=utf-8,<a href%3Dfoo>foobar</a>. e.g. what should document.querySelector('a').href return ? |
| 13:56 | <annevk> | TimothyGu: yeah, they do substring matching |
| 13:57 | <TimothyGu> | :\ |
| 13:57 | <annevk> | AutomatedTester: typically the input value |
| 13:57 | <annevk> | AutomatedTester: because it cann be resolved |
| 13:57 | <annevk> | AutomatedTester: well, if it's a URL attribute anyway |
| 13:58 | <AutomatedTester> | annevk: ahh cool, thank you |
| 13:59 | <annevk> | TimothyGu: hmm, not quite substring either, data:x;base64x,WA ends up with length 2 |
| 14:00 | <annevk> | TimothyGu: so I guess it's ends with ;base64 or contains ;base64; now |
| 14:51 | foolip | finds that the FAQ started at http://web.archive.org/web/20070821014820/http://blog.whatwg.org/faq/ |
| 14:53 | <annevk> | TimothyGu: https://github.com/whatwg/fetch/pull/579 if you want to review (there should be Preview/Diff links in a bit) |
| 14:59 | annevk | updates OP with a TODO list |
| 15:45 | <TimothyGu> | annevk: will do. |
| 15:46 | <TimothyGu> | anybody have any idea why typeof document.all returns "undefined" on both Chrome and Firefox? bug or just plain weirdness with document.all? |
| 16:30 | <annevk> | TimothyGu: https://github.com/tc39/ecma262/pull/673 |
| 16:32 | <Domenic> | TimothyGu: oh wow, we get to introduce you to https://html.spec.whatwg.org/multipage/obsolete.html#dom-document-all |
| 16:39 | <Domenic> | annevk: it looks like the base64 RFC doesn't have an algorithm, or is it hidden somewhere? |
| 16:41 | <annevk> | Domenic: I think you have to infer it from the description per usual |
| 16:41 | <Domenic> | Sigh |
| 16:42 | <Domenic> | I guess we can create an algorithm and say it's compatible with the RFC or something |
| 16:42 | <Domenic> | BTW we can just return null instead of throwing an DOMException to keep it at the Infra level |
| 16:43 | <annevk> | Domenic: we already have an algorithm |
| 16:43 | <annevk> | Domenic: it's how we define window.atob() as I've said a few times |
| 16:43 | <annevk> | Domenic: we just need to make that reusable |
| 16:43 | <annevk> | Domenic: I discovered this morning implementations share the code path |
| 16:44 | <Domenic> | Sorry, poor choice of words "create" |
| 16:44 | <Domenic> | I was just kind of hoping we could avoid the layering question by letting the RFC do the work |
| 16:47 | <annevk> | Hah, I've yet to find that RFC |
| 16:49 | <annevk> | Domenic: Infra seems fine btw, it also has things like namespaces, so a base64-with-errors seems reasonable |
| 16:49 | <annevk> | more like base64-with-some-errors |
| 17:38 | <smaug____> | foolip: does blink have usage data about alert/confirm/prompt ? |
| 18:04 | <Domenic> | smaug____: yes... around 1% or 2% IIRC for alert |
| 18:05 | <Domenic> | smaug____: I misremembered, it's lower. https://www.chromestatus.com/metrics/feature/timeline/popularity/950 + https://www.chromestatus.com/metrics/feature/timeline/popularity/951 + https://www.chromestatus.com/metrics/feature/timeline/popularity/952 |
| 18:06 | <smaug____> | ahaa, even alert() is quite low |
| 22:49 | <TimothyGu> | annevk/Domenic: wat |