| 05:04 | <annevk> | jyasskin: not necessarily, session history is a bit broken |
| 05:06 | <annevk> | Mek: yoav: ah, I read past browser, yeah, that is not specified that well; in parallel is sometimes that |
| 05:07 | <annevk> | nox: only when script is inserted later on, aiui |
| 05:20 | <jyasskin> | annevk: Thanks. |
| 05:21 | <jyasskin> | annevk: You may get a PR tomorrow. |
| 06:05 | <annevk> | 😊 |
| 10:07 | <nox> | annevk: I feel like we should do a first patch to the insert algo, that makes differences between fragments and normal nodes disappear. |
| 10:08 | <annevk> | nox: which differences are you thinking of? |
| 10:10 | <nox> | annevk: https://dom.spec.whatwg.org/#concept-node-insert Make steps 7.1-7.3 its own loop, and reloop over each node in nodes for steps 7.4-7-7. |
| 10:11 | <nox> | annevk: Oh also, I'm curious about why step 7 says "For each node in nodes, *in tree order*", nodes is supposed to be a list at that point. |
| 10:11 | <annevk> | nox: that seems like a bug |
| 10:12 | <nox> | annevk: Making two loops make the algo not do dumb stuff if child's index changes. |
| 10:12 | <annevk> | nox: so that means all nodes are inserted by the time we execute scripts? |
| 10:13 | <nox> | annevk: Yes. This is still not exactly what Firefox and Chrome do but it brings us closer. |
| 10:13 | <annevk> | nox: how does that work for <script></script><iframe></iframe>? |
| 10:13 | <nox> | annevk: It doesn't fix that problem, according to the spec the iframe would still not have its insertion steps ran yet. |
| 10:14 | <nox> | It just fix the issue of moving around child during the insertion of multiple nodes from a fragment. |
| 10:14 | <nox> | annevk: I don't know if such partial fixes are a thing, hence me asking you :) |
| 10:14 | <annevk> | nox: I think we should do a complete solution |
| 10:14 | <nox> | Ok |
| 10:14 | <annevk> | nox: as we might well end up with a different setup in the end |
| 10:14 | <nox> | annevk: I have a complete solution in mind |
| 10:15 | <annevk> | nox: e.g., protect against weird indexes or have this separate script loop thingy |
| 10:15 | <nox> | annevk: I don't know how one can protect against weird indexes without two separate non-nested loops though. |
| 10:16 | <nox> | My idea for the script/iframe thing is: make "insertion steps" take a "list of pending script preparations", then after you looped over all elements to run their insertion steps, prepare each script in order in the list. |
| 10:16 | <nox> | (And make scripts' insertion steps just add themselves to that list) |
| 10:19 | <nox> | We may otherwise prefer to make insertion steps take a queue of pending script executions, and change "Immediately execute the script block, even if other scripts are already executing." to "Queue the script on the queue of pending script executations" in the "prepare a script" algo. |
| 10:19 | <annevk> | nox: so that would roughly be the Firefox approach? |
| 10:20 | <nox> | annevk: And the Chrome one, I think? |
| 10:20 | <annevk> | nox: I don't remember 😃 |
| 10:20 | <nox> | annevk: Heh. |
| 10:20 | <nox> | annevk: I would very much prefer if the queue is an argument to the insertion steps, at the very least, |
| 10:21 | <annevk> | nox: so yeah, something like that sounds like the best way forward, perhaps we don't want to call it quite script executions as style stuff was on that queue too, but overall sounds good |
| 10:21 | <nox> | annevk: jdm added a similar concept to Servo, but he made the queue live on document, |
| 10:21 | <nox> | and it was super hard to realise it's specific to DOM tree mutations and can be self-contained in the insertion algo. |
| 10:21 | <annevk> | nox: so we hand the elements a queue they can put stuff in? |
| 10:21 | <nox> | Yeah. |
| 10:21 | <nox> | annevk: Not sure what you mean about styles. |
| 10:21 | <annevk> | nox: iirc there's a case where you can observe when <style> gets its sheet set |
| 10:22 | <annevk> | nox: it happens in that queue iirc |
| 10:22 | <annevk> | nox: I like your approach of not introducing new global state, so +1 if that really works |
| 10:22 | <nox> | Nice |
| 10:23 | <nox> | https://github.com/whatwg/dom/pull/576#issuecomment-368598457 Oh I misread that, I see what you mean. |
| 10:24 | <nox> | annevk: queue of deferred insertion steps? What about a word related to "finalization"? |
| 10:25 | <annevk> | nox: deferred seems good, finalization sounds like weak refs |
| 10:25 | <nox> | annevk: Yeah, just not sure whether having both "insertion steps" and "deferred insertion steps" is a good idea |
| 10:26 | <annevk> | nox: it seems fine, the latter is only a variable |
| 10:26 | <annevk> | nox: could also name it _deferredSteps_ or some such |
| 10:27 | <nox> | Ok |
| 10:30 | <nox> | annevk: About https://github.com/whatwg/dom/pull/576#issuecomment-368598457 |
| 10:31 | <nox> | I'll write a new test just to check something: I'm not sure it's null because it's really supposed to be done after scripts, or if it's null because we go through a fragment. |
| 12:23 | <xPaw> | Heyo, I've had this silly idea and wonder if it's worth trying to pursue or not. JS api that would trigger the emoji picker native to the platform (chrome has a emoji in context menu for any input), with how complicated emojis are with all the modifiers and what not, it might not be a terrible idea |
| 12:24 | <xPaw> | Having a JS api to trigger it would allow web devs to replace any libraries implementing an emoji picker with the one native to the platform (e.g. button click event, call the emoji picker, which would pop up the native one) |
| 12:45 | <annevk> | xPaw: it does seem like a reasonable request given how prominent those kind of widgets are in OS stacks |
| 12:46 | <xPaw> | i don't know where to raise such an issue so it can be discussed or turned into a spec |
| 12:47 | <xPaw> | chrome devs probably have a better idea, since they already had to deal with emoji pickers in each relevant platform |
| 12:49 | <annevk> | xPaw: https://discourse.wicg.io/ seems like a reasonable place to start for this |
| 12:52 | <xPaw> | looks like it was discussed already https://discourse.wicg.io/t/invoke-emoji-input/1030 |
| 12:54 | <annevk> | xPaw: yeah, though that's declarative; seems worth re-raising with the API angle as motivating factor, while acknowledging that past thread |
| 12:54 | <annevk> | anyway, up to you |
| 12:54 | <xPaw> | sure, thanks |
| 12:54 | <annevk> | xPaw: https://whatwg.org/faq#adding-new-features might also be of interest as general guidelines around this |
| 13:03 | <xPaw> | i've created https://discourse.wicg.io/t/js-api-to-trigger-the-platform-native-emoji-picker/3353 |
| 14:10 | <nox> | annevk: Is changing the contents of a Text node in a script element supposed to trigger its preparation? |
| 14:12 | <annevk> | nox: I'm not sure what HTML says, but bz did point out that Firefox at least does some amount of preparation when connected, and then executes the preparation in the deferred steps, so if an earlier deferred step modified the script that probably wouldn't affect what it will execute |
| 14:12 | annevk | looks at what HTML says |
| 14:13 | <nox> | annevk: Pretty sure what Firefox does is the reason why my test with 3 scripts fail on it. |
| 14:13 | <nox> | That's unrelated to my question though. :P |
| 14:14 | <nox> | "If node is a Text node and its parent is not null, run the child text content change steps for node’s parent." when replacing data in a Text element, |
| 14:14 | <annevk> | nox: understood, but I thought I'd mention that distinction here... |
| 14:14 | <nox> | and IIRC HTMLScriptElement doesn't have any child text content change steps. |
| 14:14 | <annevk> | nox: yeah, script element processing model only triggers on being connected |
| 14:15 | <annevk> | nox: and maybe when the src attribute is set for the first time? unclear |
| 14:15 | <nox> | annevk: Is there a test for that? Do you think I should write one? |
| 14:15 | <annevk> | nox: I suspect there might be some tests for that wherever the script element tests are |
| 14:18 | <nox> | Ok! |
| 14:19 | <annevk> | (it is somewhat frustrating that it often feels like it'd be quicker to write a test then to find an existing HTML Standard test) |
| 14:33 | <gsnedders> | annevk: (yeah, that's definitely a problem too often :/) |
| 14:42 | <nox> | Who uses VS Code here? |
| 14:42 | <nox> | Tempted to quickly publish bikeshed syntax as an extension. |
| 14:44 | <nox> | annevk: Aha https://dom.spec.whatwg.org/#concept-node-insert step 7.4 |
| 14:45 | <nox> | Need to test inserting a script and a Text node into a style element and see if the style's child text content change steps get executed before or after the script. |
| 14:46 | <annevk> | nox: sounds to me you're quickly catching up with zcorpan |
| 14:46 | <nox> | Hah |
| 14:46 | <nox> | I'll take that as a compliment, for sure. :D |
| 14:48 | <nox> | annevk: Oh btw, step 3 of https://html.spec.whatwg.org/multipage/#update-a-style-block |
| 14:49 | <nox> | is a shadow root always itself in a document? |
| 14:49 | <annevk> | nox: no |
| 14:49 | <nox> | Is that spec correct, then? |
| 14:51 | <annevk> | nox: I'm not sure, but the combination with the child text content change steps seem a little wrong, yeah |
| 14:52 | <annevk> | nox: pretty sure there was a reason we didn't go with "connected" either though |
| 14:52 | <nox> | I interpreted step 3 as limiting the creation of the stylesheet to style elements which are actually in a document that is actually rendered and whatnot, |
| 14:52 | <nox> | but I guess that it's the wrong interpretation anyway if it's just any document, right? |
| 14:53 | <annevk> | yeah, there are some tests that test these steps |
| 14:54 | <nox> | TIL stylesheets get loaded in any document, the more you know… |
| 14:55 | <nox> | annevk: So do you think the bit about shadow tree is wrong and it should use "becomes connected" instead? |
| 14:55 | <nox> | I.e. we shouldn't create style sheets for style elements that are in a shadow root that is itself not in a document tree? |
| 14:57 | <annevk> | nox: I'm not sure, nothing here changed in a while |
| 14:57 | <nox> | Ok |
| 14:59 | <annevk> | nox: per https://github.com/whatwg/html/issues/1194 it seems intentional |
| 14:59 | <nox> | Amazing |
| 15:00 | <nox> | Almost forgot to forget my sense of logic on this one. |
| 15:01 | <annevk> | 2019 and people still haven't internalized the logic of the web |
| 15:01 | <annevk> | (narrator: and for the better) |
| 15:12 | <nox> | annevk: Heh |
| 15:12 | <nox> | annevk: At the very least, those investigations made me find out about CDATASection which we don't have in Servo, |
| 15:12 | <nox> | and your wonderful comment about waiting to be 30yo to reinstate it, good stuff :D |
| 15:13 | <annevk> | nox: now you need to wait until you're 30yo to impl it |
| 15:14 | <nox> | annevk: Joke's on you, I'm 31 already. :P |
| 15:14 | <nox> | annevk: I'm probs going to make it an easy issue, that interface just exists and doesn't do anything particular, right? |
| 15:14 | <nox> | An intern made a whole tutorial about adding an interface to Servo, may as well make use of it. |
| 15:15 | <annevk> | nox: there might be some Text <> CDATASection stuff around normalize(), I forgot, but nothing too involved |
| 15:15 | <nox> | Ok |
| 21:47 | <jyasskin> | I've forwarded xPaw's discourse thread to the folks who did the Chrome emoji picker. |
| 21:49 | <jyasskin> | nox: I'd love a bikeshed syntax extension. I tried one locally based on the markdown syntax, and realized I don't know .tmLanguage well enough to do it right. |
| 22:12 | <jyasskin> | Should the ->ES part of https://heycam.github.io/webidl/#es-DOMString be using https://tc39.github.io/ecma262/#sec-stringcreate? |
| 22:13 | <TabAtkins> | jyasskin: There's already a tmLanguage for Bikeshed in the bikeshed repo? |
| 22:13 | <jyasskin> | TabAtkins: ... I should have looked there. |
| 22:13 | <TabAtkins> | hahaha |
| 22:14 | <TabAtkins> | It's not, like, perfect, but it does a decent job. |
| 22:22 | <Domenic> | jyasskin: nope, that creates objects like `new String(x)`, whereas we want to create new objects like `String(x)`. (Well, technically `String()` has a special-case for symbols which we don't want, but that's a separate story.) |
| 22:23 | <jyasskin> | Domenic: Ok then. At the very least, "the String value that represents the same sequence of code units that the IDL DOMString represents" isn't precise enough? |
| 22:25 | <Domenic> | jyasskin: it's about as precise as the ES spec, where the equivalent is in https://tc39.github.io/ecma262/#sec-string-literals-static-semantics-stringvalue |
| 22:25 | <Domenic> | "Return the String value whose code units are the SV of this StringLiteral. " |
| 22:26 | <jyasskin> | Huh. Ok, then I won't worry about being more precise when I need to convert a URL's serialization to an ES String. |
| 22:27 | <Domenic> | Yeah, should be fine, although I'm a little worried about the fact that you're in a context where IDL can't shield you from that |
| 22:51 | <jyasskin> | Domenic: Yeah, I'm uncomfortable about that aspect of https://w3c.github.io/network-error-logging/#generate-a-network-error-report. |
| 22:52 | <Domenic> | Ah, right, that one :) |
| 22:52 | <jyasskin> | For now, I've decided that's not my circus. |