| 00:41 | <Domenic> | I'd render unstable Web IDL with a // unstable that's bold or red or something similar |
| 00:41 | <Domenic> | maybe blinking ;) |
| 07:23 | <hsivonen> | I wonder what a typical performance-sensitive case of UTF-16 to UTF-8 conversion in browsers is like |
| 07:26 | <annevk> | hsivonen: does UTF-16 include internal representation of most things? |
| 07:27 | <annevk> | hsivonen: because then maybe URLs? |
| 07:33 | <hsivonen> | annevk: I mean other than URLs and form submessions, which apply to other enodings |
| 07:33 | <hsivonen> | annevk: yes, UTF-16 is the internal representation of most things |
| 07:34 | <hsivonen> | so serializing stuff for XHR POST would do UTF-16 to UTF-8 |
| 07:34 | <rniwa> | zcorpan: added more test cases on https://github.com/w3c/web-platform-tests/pull/3968 |
| 07:35 | <hsivonen> | URLs are almost always ASCII |
| 07:35 | <hsivonen> | form submissions in non-Latin scripts are almost entirely non-ASCII |
| 07:36 | <hsivonen> | but I wonder if there are real-world cases where mixed ASCII/non-ASCII matters for perf for UTF-16 to UTF-8 |
| 07:37 | <hsivonen> | I have a pretty good idea what metric I should be optimizing for decode |
| 07:37 | <hsivonen> | also for URL use case encode |
| 07:37 | <annevk> | hsivonen: maybe it matters more in a world where more is done in UTF-8 or WTF-8 internally, although maybe then UTF-16 would almost never be used |
| 07:37 | <hsivonen> | but I don't have a good idea what metric I should be optimizing for UTF-16 to UTF-8 encode |
| 07:38 | <hsivonen> | annevk: in a world where the internal representation is Rust-style guaranteed-valid UTF-8, encode takes zero time. :-) |
| 07:39 | <annevk> | hsivonen: sure, but I'm not sure Rust-style can be the end game given JavaScript |
| 07:39 | <hsivonen> | annevk: we might get away with UTF-8 DOM |
| 07:40 | <hsivonen> | annevk: and break pages that expect to be able to put lone surrogates in the DOM and join them later |
| 07:40 | <annevk> | hsivonen: anyway, not sure what there is beyond URLs, forms, saving to disk, and perhaps some very cool OS that uses UTF-8 for strings everywhere |
| 07:40 | <hsivonen> | annevk: within the JS engine, there needs to be a way to have lone surrogates, sure |
| 07:40 | <hsivonen> | annevk: saving to disk is rare and not a worthy perf target |
| 07:41 | <annevk> | hsivonen: agreed, was just trying to enumerate targets |
| 07:41 | <hsivonen> | annevk: there's XHR POST |
| 07:41 | <annevk> | hsivonen: mkay, fetch() and new Blob() too indeed |
| 07:41 | <hsivonen> | annevk: and TextEncoder |
| 07:42 | <hsivonen> | trouble is, I have no clue what the usage patterns for those are |
| 07:42 | <annevk> | hsivonen: WebSocket (though that'll disappear in favor of fetch()) |
| 07:42 | <hsivonen> | what I'm looking for is a natural interleave of ASCII and non-ASCII |
| 07:42 | <annevk> | hsivonen: I doubt that with all these I/O things encoding is going to be the bottleneck |
| 07:42 | <annevk> | hsivonen: we'd be in a pretty nice place then |
| 07:43 | <annevk> | hsivonen: which is why URLs still seem like the only "real" thing, despite a lot of them being ASCII-only |
| 07:43 | <hsivonen> | FWIW, for decode, I took Wikipedia as the natural interleave of ASCII and non-ASCII |
| 07:43 | <annevk> | (it also feels a bit morally wrong that we have all these ASCII fast-paths btw) |
| 07:44 | <hsivonen> | hey, that's my change to outperform the competition |
| 07:44 | <hsivonen> | *chance |
| 07:45 | <annevk> | Does the competition have clever parallel decoding/encoding? Although I guess the hardware might not be ubiquitous enough as we discussed earlier |
| 07:45 | <hsivonen> | It's not morally wrong for decoders as longs as the bulk of HTML/CSS/JS/URL syntax is ASCII |
| 07:46 | <annevk> | That's fair, but it's kinda sad that you get a massive drop in performance if you stick an emoji in your JavaScript resource (happens in Chrome) |
| 07:46 | <hsivonen> | annevk: ICU has manually unrolled loops but not manual SIMD at least for single-byte |
| 07:46 | <hsivonen> | annevk: Windows has something faster than ICU internally |
| 07:46 | <annevk> | Or for that matter, a non-ASCII comment |
| 07:47 | <hsivonen> | annevk: The Rust standard lib optimizes ASCII with ALU word-sized operations when the right. no explicit SIMD |
| 07:47 | <annevk> | "the ? right"? |
| 07:47 | <hsivonen> | annevk: uconv has SIMD for x86 ASCII and ALU word for ARM but for UTF-8 decode only |
| 07:48 | <zcorpan> | rniwa: sweet, looking now |
| 07:48 | <rniwa> | zcorpan: thanks! |
| 07:48 | <annevk> | Optimizing UTF-8 over others seems totally fair game btw |
| 07:48 | <hsivonen> | annevk: those were just repeated spaces. I get repeated characters thanks to a build in another VM making this one deal with the keyboard too slowly |
| 07:49 | <hsivonen> | oh. there was a mord missing |
| 07:49 | <hsivonen> | word |
| 07:49 | <hsivonen> | "when the alignment is right" |
| 07:49 | <annevk> | ah |
| 07:50 | <hsivonen> | glibc is so slow that I doubt is has any fancy optimizations |
| 07:51 | <hsivonen> | for IBM mainframes, it has a fast path for ISO-8859-1 to some EBCDIC flavor, but the stuff we use over here in the non-IBM world is slow |
| 07:56 | <hsivonen> | one option is that I test encode with URL and form submission -like workloads |
| 07:57 | <hsivonen> | but it really bothers me that I don't know what XHR POST and TextEncoder workloads really look like |
| 07:57 | <hsivonen> | FWIW, I've been designing for form submission work loads to be very slow anyway |
| 07:58 | <hsivonen> | on the theory that form submission perf (for non-UTF-8 targets) doesn't matter much |
| 07:59 | <hsivonen> | interestingly, I discovered that currently in Gecko, EUC-KR *decode* is super-slow |
| 07:59 | <hsivonen> | yet, I don't recall anyone noticing it enough to complain |
| 08:01 | <hsivonen> | annevk: do you happen to know if the emoji slowness in Chrome is about promoting an ISO-8859-1 target buffer to an UTF-16 target buffer or the emoji just messing up memory alignment afterwards? |
| 08:04 | <annevk> | hsivonen: I believe it's the former |
| 08:04 | <annevk> | (pretty sure) |
| 08:09 | <hsivonen> | maybe I should take a look at what goes over the wire in a Gmail mail composition session and see what the wire format is like |
| 08:36 | <hsivonen> | I'm rather surprised that Gmail uses application/x-www-form-urlencoded;charset=utf-8 is its XHR wire format instead of using JSON |
| 08:36 | <hsivonen> | s/is/as/ |
| 08:38 | <annevk> | hsivonen: does Gmail still offer the JS-less version? Might be because of that |
| 08:48 | <hsivonen> | annevk: I don't know. |
| 08:49 | <younder> | I like yaml, butjson is good too. All is better than the verbosity of XML |
| 08:50 | <younder> | The line noise and the st-udder it gets to you |
| 08:52 | <younder> | OK. mathML 3 is awful, but it is a standard. And in DOM it starts to make sense |
| 08:53 | <younder> | Persona: I am a software developer, educated at University of Oslo |
| 08:53 | <younder> | I have worked for Opera software in the core development team |
| 08:54 | <annevk> | younder: oh, when? |
| 08:55 | <younder> | I am now exploring developing MathML, from scratch, in blink |
| 08:56 | <younder> | No faulty WebKit implementation |
| 08:56 | <younder> | annevk, 2000 |
| 08:57 | <annevk> | younder: for a while or only that year? |
| 08:57 | annevk | was there 2005-2012 |
| 08:59 | <younder> | annevk, 1999-2000 |
| 09:00 | <annevk> | That was early days still, must have been pretty exciting |
| 09:00 | <younder> | annevk, It was we were 40 people in Opera back then. |
| 09:01 | <annevk> | heh, I was 251 iirc |
| 09:06 | <younder> | I worked under CSS developer Håkon Lie |
| 09:19 | <annevk> | jochen__: so why the setSecurityOrigin() call? |
| 09:20 | <annevk> | jochen__: that seems to be the thing that might be upsetting to bz, though you said it wasn't needed if you were same-origin anyway |
| 09:22 | <annevk> | jochen__: I can also ask in the issue directly if that's preferable |
| 10:20 | <hsivonen> | Evernote Web seems to have a chatty GWT-based wire protocol |
| 10:21 | <hsivonen> | not particularly interesting in terms of encoder performance: bunch of ASCII, then user-supplied content, then bunch of ASCII |
| 11:22 | <younder> | Most implementors of the web speak English. (Even if they are not English) |
| 11:23 | <younder> | I am Norwegain... |
| 11:24 | <younder> | like ,I suppose, annevk |
| 11:50 | <annevk> | younder: Dutch |
| 11:52 | <younder> | sorry... (Opera, Norway et al) |
| 12:12 | <annevk> | Hmm, currently downloading a 100 MiB or so just to amend a PR |
| 12:12 | <annevk> | Must be a more efficient way to do that GitHub |
| 12:16 | <younder> | blink does an incredible 50 000 file compile. Drowns any download concers |
| 12:17 | <younder> | 1 hr on a 8 core xenon |
| 12:17 | <younder> | Firfox get's none in 11 minutes |
| 12:18 | <younder> | s/none/done/ |
| 12:18 | <jochen__> | annevk, I think back then that was required to make the origin an alias |
| 12:18 | <jochen__> | annevk, not sure whether that's still a thing? |
| 12:25 | <annevk> | jochen__: alias these days is basically a pointer to the same origin object |
| 12:26 | <annevk> | jochen__: however, it's unclear to me what the effect would be if you already have a same-origin check preceding it |
| 12:33 | <jochen__> | it can be same origin without being the same origin object still, no? |
| 12:34 | <annevk> | jochen__: yes |
| 12:34 | <annevk> | jochen__: though not for opaque origins |
| 12:34 | <annevk> | jochen__: but with opaque origins they'd already have to be the same, so aliasing doesn't make sense |
| 12:36 | <annevk> | jochen__: ah, I guess it's observable when they are not aliased, then you do window.open(), then you do document.domain on one side and somehow still get access? |
| 12:37 | <annevk> | if they're aliased document.domain would change both origins, if they're not aliased you'd be isolated |
| 12:37 | <annevk> | "isolated" |
| 13:07 | <annevk> | SimonSapin: you around? |
| 13:08 | <annevk> | SimonSapin: can you check the checkbox in https://github.com/whatwg/url/pull/113 that makes your PR mutable? |
| 13:09 | <SimonSapin> | annevk: done |
| 13:09 | <annevk> | ta |
| 13:38 | <nox> | Is <script>document.write('<template>')</script> as insane as I think? |
| 13:39 | <zcorpan> | No new notifications. \o/ |
| 13:40 | <zcorpan> | nox: what's insane about it? |
| 13:40 | <jochen__> | annevk, right |
| 13:41 | <nox> | zcorpan: That everything following that will end up in the template contents I guess? |
| 13:42 | <annevk> | jochen__: I wonder if that's tested in WPT already, but I guess we'll make sure once we make this change |
| 13:42 | <zcorpan> | nox: ok, yeah, but nothing new for <template>; that also happens for e.g. <title> or <plaintext> (the latter can't even be closed) |
| 13:42 | <nox> | zcorpan: Why can't it be closed? :o |
| 13:43 | <zcorpan> | because it's <plaintext> :-D |
| 13:43 | <zcorpan> | it's the text/plain of HTTP/0.9 |
| 13:47 | <jochen__> | no |
| 13:47 | <jochen__> | I still have it on my todo list though :-/ |
| 14:00 | <ondras> | hmm, elements with position:fixed appear somehow buggy during a transition that modifies their parent's transform. both ff+chrome. hard to reduce right now; is this a known thing? |
| 14:38 | <annevk> | jochen__: talked a bit with bz, the way he'd like us to proceed is come up with a plan for changes and some number of tests demonstrating they actually match impl and then bring him back into the conversation (he unsubscribed for now, bit of a sensitive topic) |
| 14:39 | <annevk> | jochen__: which seems totally reasonable to me |
| 14:39 | <annevk> | rbyers: "(and I know there was discussion with Anne somewhere, but I can't find it at the moment)" I think we only had one in person |
| 15:03 | <annevk> | Domenic: activation behavior name changes look okay? did you have a look at the commit message I proposed? |
| 15:03 | <annevk> | Domenic: I think I'm good with both, but was thinking to wait for you to wake up just in case |
| 15:03 | <annevk> | Domenic: (DOM side landed already with review from MikeSmith) |
| 15:04 | <Domenic> | annevk: yeah, I'm awake and have read all my emails; I think I had a commit message nit, let me page it back in |
| 15:05 | <annevk> | Domenic: https://github.com/whatwg/html/pull/1925#issuecomment-255052832 |
| 15:05 | <Domenic> | annevk: OK yeah, LGTM. |
| 15:05 | <Domenic> | The no-longer-being-conditionally-associated thing is interesting |
| 15:06 | <Domenic> | On the face of it it's a normative change |
| 15:06 | <Domenic> | But because <input> can never be nested inside <input> it's not |
| 15:07 | <annevk> | They can be nested through script, but I don't think that affects anything |
| 15:07 | <Domenic> | That is, HTML's old "nearest activatable element" + conditional association vs. DOM's new walk-until-you-find-activation-behavior could in theory be different, but in practice not |
| 15:07 | <Domenic> | Yeah |
| 15:07 | <Domenic> | Well hmm |
| 15:07 | <Domenic> | <button>text <input disabled> </button> |
| 15:08 | <annevk> | The conditional association mostly affects other things doing conditional testing on these things |
| 15:08 | <Domenic> | https://jsbin.com/zimege/edit?html,console,output |
| 15:08 | <Domenic> | I guess this becomes about hit testing |
| 15:09 | <Domenic> | which UI events talks about in terms of activation behavior https://w3c.github.io/uievents/#event-flow-activation |
| 15:09 | <Domenic> | I don't think this is worth holding up the train for, just interesting |
| 15:09 | <annevk> | That is something worth looking into indeed |
| 15:10 | <annevk> | So yeah, I guess that should look at things being disabled instead |
| 15:10 | <annevk> | Just like click() already does and a number of other things do too |
| 15:10 | <Domenic> | I think HTML might need to bring back some concept of "activatable" |
| 15:10 | <Domenic> | which is roughly "activation behavior + not disable" |
| 15:11 | <annevk> | It's unfortunate we only noticed that now, since the commit message could have enunciated that more |
| 15:11 | <Domenic> | :-S |
| 15:14 | <annevk> | Domenic: I think the spec actually made a change for the better though |
| 15:14 | <annevk> | Domenic: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4594 |
| 15:14 | <annevk> | Domenic: if you comment out child.disabled = true you'll see only the child getting checked |
| 15:15 | <annevk> | Domenic: but either way it doesn't reach the parent, even though the child was disabled and did not have "activation behavior" per the old HTML text (which was therefore wrong) |
| 15:15 | <Domenic> | Ah yeah, nice. |
| 15:19 | <annevk> | I should add a test for that tomorrow |
| 15:19 | <annevk> | Hopefully I remember |
| 15:30 | <tobie> | jyasskin: is the long term plan to keep the registry in the permission spec or are you waiting on partial enums to have each power feature include it in its own spec? |
| 15:35 | <jyasskin> | tobie: Once we have partial enums, I think we'll have Bikeshed generate an index into the permissions spec, but have each feature spec define its own enum value. |
| 15:35 | <tobie> | jyasskin: what do you mean by: "we'll have Bikeshed generate an index into the permissions spec" |
| 15:37 | <jyasskin> | TabAtkins has an index element that he's used for CSS, which will let the permissions spec link to all the individual permissions. |
| 15:38 | <tobie> | jyasskin: oh. a secret feature? That's awesome. |
| 15:44 | <jyasskin> | Yep. |
| 16:38 | <TabAtkins> | Secret because I haven't given it a ton of thought yet. But it's probably ready for primetime. |
| 16:45 | <TabAtkins> | It's what's used to generate https://drafts.csswg.org/indexes/ right now. |
| 17:10 | <annevk> | Domenic: also confirmed with <form onsubmit="w(1); return false"><button type=submit>test <input type=checkbox disabled></button><form> that disabled doesn't influence the activatable target |
| 17:10 | <annevk> | Domenic: it does seem that Firefox does strange hit testing for <button> |
| 17:11 | <annevk> | Domenic: and basically bypasses any children |
| 17:11 | <Domenic> | hmmm |
| 17:11 | <annevk> | Domenic: but in Chrome that will not submit the form when you click the checkbox |
| 17:12 | <annevk> | Domenic: I think HTML might have some open issues around <button> already and how it should be handled and I think Firefox has an open bug too with respect to hit testing / activation |
| 17:12 | <annevk> | Domenic: anyway, will turn these two examples into tests since I have some time now |
| 17:26 | <annevk> | Domenic: https://github.com/w3c/web-platform-tests/pull/4043 |
| 19:36 | <jsbell> | Thanks for the feedback, Domenic! |
| 20:35 | <KiChjang> | https://w3c.github.io/charter-html/group-charter.html |
| 20:36 | <KiChjang> | does this WG have any relationship with WHATWG? |
| 20:40 | <terinjokes> | I'm going to guess the relationship, if one can call it that, is specified in the section labelled "External Groups" |
| 20:43 | <gsnedders> | KiChjang: what terinjokes said |
| 20:44 | <KiChjang> | it seems unnecessary for another WG to work on the same things as whatwg? |
| 20:51 | <Domenic> | KiChjang: sometimes the W3C likes to copy and paste our work and put their logo on it for various reasons. It sucks and is a waste of a ton of peoples' time, but is outside our control. |
| 20:52 | <KiChjang> | is there no copyright/patent laws preventing that from happening? |
| 20:52 | <KiChjang> | copyleft* |
| 20:52 | <Domenic> | Our specs are licensed under liberal licenses |
| 20:53 | <gsnedders> | KiChjang: the main reason why those involved in the WHATWG don't kick up an even bigger fuss is the patent protection provided by W3C RECs |
| 20:54 | <Domenic> | https://lists.w3.org/Archives/Public/www-archive/2014Apr/0034.html is relevant |