| 02:08 | <Domenic> | MikeSmith: TabAtkins: it seems like the solution would be to accumulate text/language pairs, then send some mega-JSON to the python process to get it all highlighted in one go, then go back and update the nodes? |
| 06:12 | <MikeSmith> | Domenic: yeah I guess so, if we wanted to optimize for speed. But that would amount to a major rewrite of what the wattsi code has now |
| 06:14 | <MikeSmith> | and it’d feel sad to have to move yet more of the cost of it into the wattsi code to make up for limitiations in the desing of the Python VM |
| 06:16 | <MikeSmith> | especially given we started out on doing it this way, with needing to write a JSON serializer in the wattsi code to make up for the poor performance of HTML parsing in Python |
| 06:25 | <MikeSmith> | to make the rewrite work, I guess we’d have to make wattsi generate a unique ID for each <pre> node (be making a hash for it whatever), then until we get to the end of the spec source document, collecting/holding all the JSON for the <pre>s of each class into memory with the JSON including their IDs, and pass those bundles (three I guess -) along to the highlighter as an attribute so that it gets |
| 06:25 | <MikeSmith> | included in the generated |
| 06:26 | <MikeSmith> | ...output for the highlighter |
| 06:28 | <MikeSmith> | but then we’d need to go back and do another pass through the HTML source to do a lookup of each <pre> against the giant output we get back from the highlighter to looko for the corresponding node |
| 06:29 | <MikeSmith> | but we need HTML output from the highlighter, not JSON, so if we did that lookup against the HTML contents we get back, then we’re gonna need to (re)parse it in wattsi |
| 06:30 | <MikeSmith> | so actually given all that I don’t even see a way to make it work in practice in wattsi ー no practical way to bundle up all the <pre>s |
| 06:33 | <MikeSmith> | I mean, the way the current wattsi code is overall, we need to write each modified <pre> node to the spec output right after we read the unmodified source for it |
| 06:34 | <MikeSmith> | and that’s also why we need to do that 4 times for each <pre> instead of once for each |
| 06:35 | <MikeSmith> | because we are writing/building 4 different spec versions |
| 09:44 | <annevk> | JakeA: https://github.com/whatwg/html/issues/2806 seems to contain a proposal for doing range requests for images |
| 09:44 | <annevk> | JakeA: and also some confusion about whether that needs to be standardized |
| 09:45 | <JakeA> | annevk: will jump in, cheers! |
| 10:23 | <Domenic> | MikeSmith: hmm I thought there would be a way to keep references to all pre nodes in memory, with no IDs or lookups or second pass. |
| 10:24 | <Domenic> | (Then correlate them by index-in-pre-array <-> index-in-HTML-output-array) |
| 12:57 | <MikeSmith> | Domenic: the problem with doing it that way is, there’s content that gets added to the pre nodes by wattsi |
| 12:58 | <MikeSmith> | so the highlighter needs to operate not on the raw source by instead on the wattsi-modified/preprocessed versions |
| 12:59 | <MikeSmith> | but I have to admit that at this point, I have a somewhat vague recollection of why it needed to be implemented the way I did |
| 13:00 | <MikeSmith> | ...because I implemented the basis of it 7 or 8 months ago and had a much clearer idea of why then |
| 13:01 | <MikeSmith> | but in the mean time it sat for all those months |
| 13:09 | <MikeSmith> | anyway as far as the highlighter, it’s not clear to me if there’s something that would prevent the highlighter from being wrapped in a simple web server so that it could run persistently and we avoid repeating the VM startup costs 1121 x 4 times |
| 13:32 | <MikeSmith> | similar to teh Bikeshed http service or to wptserve or whatever |
| 13:45 | <jsx> | Hello |
| 13:45 | <jsx> | I'm trying to use HTML's maxlength attribute to limit character input. This works as expected with English character, but when I enter Japanese character, it allows me to enter any number of characters, but once the input field is blurred, the text is automatically truncated to fit the maxlength limit. |
| 13:45 | <jsx> | The issue is found only when entering Japanese, Chinese and Korean characters. |
| 13:46 | <jsx> | Is this the expected behavior for maxlength for these characters? |
| 13:46 | <jsx> | https://jsbin.com/?html,js,output (works for English chars) |
| 13:47 | <jsx> | sry, wrong link |
| 13:47 | <jsx> | https://jsfiddle.net/bwtf4ake/ |
| 13:58 | <JakeA> | Any setTimeout experts here? Is there any reason setTimeout(cb, 10) would call cb in less than 10ms, according to Date.now()? It seems to happen in everything but Safari |
| 13:58 | <JakeA> | https://static-misc.glitch.me/set-timeout-delay |
| 14:22 | <zcorpan__> | JakeA: maybe they "cheat" to get better score on some benchmark? dunno |
| 14:23 | <zcorpan__> | or it takes a while for the first task to be surfaced |
| 14:24 | <JakeA> | Either would be against the spec I think |
| 14:24 | <wanderview> | JakeA: how much earlier than 10ms? |
| 14:24 | <annevk> | jsx: I suspect that's a bug due to usage of an IME, or are you not using that to enter those characters? |
| 14:24 | <JakeA> | wanderview: Seems like 9 in Chrome & Firefox. Edge seems to go lower. Saw 5. |
| 14:24 | <wanderview> | JakeA: at one point I tried to make firefox never fire early and I believe it caused some interop issues or made things skew too late on average |
| 14:24 | <JakeA> | innnnnteresting |
| 14:25 | <wanderview> | JakeA: in my tests edge seems to be doing much more aggressive coalescing of timers to 5ms boundaries... probably a big win for battery |
| 14:26 | <JakeA> | also interesting! |
| 14:26 | <annevk> | wanderview: hmm, now I wonder whether timers can be used as a sidechannel |
| 14:27 | <wanderview> | JakeA: at least in firefox we have primitives that only allow sleeping at milliseconds boundary, but you can time things at sub-millisecond level with performance.now() (and internal timing APIs) |
| 14:27 | <wanderview> | JakeA: so we have to decide to round-up or round-down at some point |
| 14:30 | <JakeA> | makes sense |
| 14:31 | <wanderview> | anyway, we could always round up... but then all the error will be biased to be late and things will be more likely to drift |
| 14:31 | <wanderview> | JakeA: for setInterval() chrome actually has drift correction code that will purposely fire early if the last interval was late... there is a spec issue somewhere to standardize that |
| 14:32 | <JakeA> | wanderview: yeah, it makes a lot more sense for setInterval, although yeah it isn't spec'd |
| 14:32 | <wanderview> | annevk: its hard to say for the sidechannel... this could get more precise in the future (or not as edge is doing)... I do think it would be hard to rely on precise setTimeout() firing in a cross-browser way |
| 14:33 | <wanderview> | JakeA: here is the spec issue... I think we have some amount of agreement to do the drift correction: https://github.com/whatwg/html/issues/3151#issuecomment-339000314 |
| 14:37 | <annevk> | wanderview: I was thinking that if they are coalesced you might be able to determine what other timers are running |
| 14:39 | <wanderview> | not sure I understand |
| 14:43 | <annevk> | wanderview: it seemed a little similar to the things described in chapter 6 of https://tom.vg/papers/cross-browser-tracking_woot17.pdf |
| 14:46 | <wanderview> | annevk: I'll have to read that a little later |
| 14:46 | <wanderview> | annevk: coalescing timers is observable, though... like if you use postMessage() you can see that coallescing re-orders setTimeout(0) in relation to the postMessage |
| 15:36 | <smaug____> | env() sounds really bizarre "user agents may define additional undocumented environment variable" |
| 15:37 | smaug____ | is surprised one even proposes such thing to the web |
| 15:37 | <smaug____> | s/variable/variables/ |
| 15:39 | <lgrahl> | We were wondering if there's an existing "write to file" API for a ReadableStream in browsers... or something planned? |
| 16:05 | <annevk> | lgrahl: what does "file" mean? |
| 16:09 | <lgrahl> | annevk: Basically, the use case we had in mind was about downloading a stream to a file. So, you get the download "save to disk" dialog thingy and then stream the data into it. |
| 16:10 | <wanderview> | I believe you can do that with a service worker and content-disposition header |
| 16:11 | <lgrahl> | wanderview: Is there an example for this? |
| 16:12 | <wanderview> | lgrahl: I think JakeA had an example of service-worker content-disposition to download an .epub file or something... then it would just be normal fetch API body stream support |
| 16:12 | <wanderview> | sorry, I don't have anything handy at the moment |
| 16:12 | <wanderview> | I have to step away |
| 16:14 | <Mek> | fwiw I do also plan to start looking into more explicit writable file type APIs (again, since it's not like we haven't had many attempts at that already)... although downloading a stream to a file isn't quite a use case I had in mind for that work... |
| 16:16 | <lgrahl> | Since we have high hopes that we'll get streams into data channels, this would be really good to have, since one of the core use cases is P2P file sharing. |
| 16:17 | <lgrahl> | So far, the only example we can bring up is "pipe an HTTP response into a data channel" which is... interesting but a rather rare use case. :) |
| 16:20 | <lgrahl> | Unless of course there are other APIs using (byte) streams I'm not aware of. |
| 17:29 | <foolip> | annevk: I assume you've checked that you're using the right account on crbug.com? Still not working now? |
| 17:31 | <annevk> | foolip: I'm still using the same account as before and no, it's not |
| 17:31 | <annevk> | foolip: that is, I only see a comment field, not the giant list of options I got before |
| 17:32 | <annevk> | foolip: I checked with my Mozilla account and that has the same non-privileges; don't think I've got more accounts |
| 19:42 | <smaug____> | Domenic: am I missing something, or does https://html.spec.whatwg.org/multipage/custom-elements.html#dom-customelementregistry-upgrade end up upgrading already-upgraded elements again? |
| 19:42 | <smaug____> | I mean, if one for example call the method twice with same param, elements are upgraded twice |
| 19:46 | <smaug____> | ah, no, https://html.spec.whatwg.org/multipage/custom-elements.html#upgrades will return early |
| 22:15 | <Domenic> | Heh, I guess it makes the example in step 1 kinda funny though, since you can now trigger it much more easily. |