| 07:05 | <galant> | why when I paste few letters in text node that is in contenteditable element it splits nodes at te place where I paste the letters? this is making me very big troubles |
| 07:49 | <galant> | http://jsfiddle.net/jMKX5/ first write some letters in that section, then copy paste few letters in it, you will see when you paste the letters it will split the text nodes at the place of the paste. Why this is happening? This is making me a lot of troubles |
| 08:32 | <annevk> | Ms2ger: now http://dom.spec.whatwg.org/#nodeiterator detach() does nothing, referenceNode can be Node rather than Node? right? |
| 08:34 | <Ms2ger> | annevk, that looks correct |
| 12:24 | <JonathanNeal> | good morning |
| 12:41 | <MikeSmith> | anybody have parser tests for <template> yet? |
| 12:42 | <annevk> | MikeSmith: they're in html5lib afaik |
| 12:43 | <MikeSmith> | ah ok |
| 12:43 | <MikeSmith> | thanks |
| 13:06 | <annevk> | Hmm http::apple.com/ parses differently given a base URL |
| 13:13 | <zewt> | people sure like to have things both ways |
| 13:13 | <zewt> | "this thing is better than this other thing! and you can't argue against it because we're only talking about consistency here" |
| 13:40 | <Ms2ger> | irc.m.o having issues for anyone else? |
| 13:40 | <Ms2ger> | Ah, there we are |
| 14:48 | <matjas> | can anyone confirm that `I'm ¬it; I tell you` is a parse error, even if it occurs in an attribute value? (trying to make sure I understand http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenizing-character-references correctly) |
| 14:48 | <annevk> | marcosc: promises will end up in JS, but not in any timeframe we can work with |
| 14:49 | <annevk> | marcosc: same for event loop, same problem |
| 14:52 | <gsnedders> | matjas: No parse error, per how I read it. |
| 14:53 | <gsnedders> | Or maybe there is? |
| 14:53 | <gsnedders> | I dunno. |
| 14:53 | <gsnedders> | We just changed html5lib so it wasn't based on my original reading, but now I can read the spec either way. |
| 14:55 | <gsnedders> | matjas: I believe it is not. A match is made (¬), so that paragraph doesn't apply. The following paragraph only raises a parse error if the following character is an equals sign, which it is not. |
| 14:55 | <gsnedders> | That's my opinion. |
| 14:58 | <annevk> | yeah, it's just ignored |
| 15:07 | <matjas> | thanks |
| 15:07 | <matjas> | so in attribute values, e.g. `&` without trailing semicolon is perfectly valid |
| 15:08 | <matjas> | or `¬`, to stick to the previous example |
| 15:08 | <matjas> | right? |
| 15:09 | <annevk> | yeah, I think we didn't want to flag many URLs as invalid |
| 15:12 | <matjas> | gsnedders ^ ? |
| 15:13 | <hallvors> | http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin - "For scripts" part says nothing about Workers. Is the origin of the worker script the origin of the document that controls the worker? |
| 15:13 | <gsnedders> | matjas: Well, no, it will all get unconsumed and come out as the literal string "&", it's not just not a parser error. |
| 15:14 | <gsnedders> | Well, in the above ¬it; example. |
| 15:14 | <gsnedders> | It depends what character follows &, ¬, etc. |
| 15:14 | <matjas> | ok, got it |
| 15:14 | <gsnedders> | If it's an alphanumerical character, you get the literal string "&" and no parse error. If it's an equals sign, you get the literal string and a parse error. |
| 15:15 | <gsnedders> | If it's neither, you get "&" and no parse error. |
| 15:15 | <gsnedders> | *If it's neither, you get "&" and a parse error. |
| 15:15 | <matjas> | outside of attribute values, e.g. & is always a parse error, inside of attribute values it’s only a parse error when followed by = |
| 15:16 | <matjas> | or am i oversimplifying there? |
| 15:18 | <gsnedders> | Yes. It's only a parse error if it gets converted to "&" *or* it is followed by = in an attribute. |
| 15:18 | <matjas> | gsnedders: thanks! |
| 15:18 | <Ms2ger> | gsnedders, clearly your entire stack should be written in Coq |
| 15:20 | <gsnedders> | Ms2ger: :) |
| 15:20 | <gsnedders> | Ms2ger: Not sure how viable it really is to have a wholly proven stack, as nice as the idea is. |
| 15:21 | <gsnedders> | (Even ignoring the viability of the time it would take!) |
| 15:21 | <Ms2ger> | gsnedders, yeah, proving stuff tends to be hard |
| 15:22 | <gsnedders> | I mean, Coq can nowadays export compilable code, but then you're at the mercy of unproven compilers, so I'm not convinced it helps you /that much/. |
| 15:22 | <gsnedders> | It saves you writing stuff twice, sure. |
| 15:54 | <hallvors> | minor question for annevk (should he return and look at logs) or Ms2ger - any thoughts on this test? https://critic.hoppipolla.co.uk/showcomment?chain=280 |
| 15:56 | <hallvors> | (Most of the test code is in a worker script - see https://critic.hoppipolla.co.uk/showfile?sha1=8c50d4a4ed37ca0293bac5a547f08be6022bfccd&path=XMLHttpRequest/resources/workerxhr-origin-referrer.js&review=134 ) |
| 16:05 | <Ms2ger> | Needs more spaces ('if (foo) {', not 'if(foo){') |
| 16:14 | <annevk> | If hallvors were here I could tell him I don't follow the test |
| 16:48 | <Hixie_> | so... Document.getComputedStyle(element) returns a CSSStyleDeclaration, as do element.specifiedStyle, element.defaultStyle, element.computedStyle, element.usedStyle, and element.style. |
| 16:49 | <Hixie_> | pop quiz. which of the last five, if any, is equivalent to the first one? |
| 17:01 | <gsnedders> | Hixie_: userdStyle? |
| 17:01 | <Hixie_> | nope |
| 17:05 | <annevk> | Hixie_: none? |
| 17:06 | <Hixie_> | anne is correct! |
| 17:06 | <Hixie_> | getComputedStyle() returns the resolvedStyle, which you can't get straight from the element for some reason |
| 17:07 | <annevk> | ooh GetStyleUtils, that's new |
| 17:07 | <Hixie_> | and computedStyle returns the computed style, unlike getComputedStyle |
| 17:07 | <Hixie_> | i really think we should rename computedStyle on the API. I know the specs are confusing, but making the API confusing too is not good. |
| 17:07 | <annevk> | I guess the idea is that nobody would use getComputedStyle anymore |
| 17:08 | <annevk> | although it's unclear how they're solving pseudo-elements... |
| 17:08 | <Hixie_> | unless we're planning on dropping it from the spec, that's not gonna happen. |
| 17:08 | <Hixie_> | pseudos are exposed in the DOM more directly |
| 17:08 | <annevk> | oh |
| 17:11 | <Hixie_> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=22528 |
| 17:14 | <annevk> | ah ele.pseudo("::before").style |
| 17:14 | <annevk> | I wonder why they didn't drop the "::" bit for that API |
| 17:18 | <Hixie_> | i kinda like it. makes it more obvious that it's a pseudo. |
| 17:18 | <Hixie_> | when scanning the code. |
| 17:19 | <SimonSapin> | Does this work? ele.pseudo(":before") |
| 17:24 | <Hixie_> | SimonSapin: see the spec :-) |
| 17:24 | <Hixie_> | (http://dev.w3.org/csswg/cssom/) |
| 17:24 | <SimonSapin> | Thanks Hixie_ |
| 17:25 | <SimonSapin> | (I guess the underlying question was: which spec is this in) |
| 17:25 | <Domenic_> | can we rename the concept currently named "resolved style" to "computed style" so that concept and getComputedStyle match, then rename "resolved style" to something else? |
| 17:25 | <SimonSapin> | ftr, it does |
| 17:25 | <Domenic_> | sorry, rather, rename "computed style" to something else |
| 17:25 | <TabAtkins> | Domenic_: No, we can't. "computed style" is used *everywhere* in the specs. Too much legacy compat to change it. ^_^ |
| 17:26 | <Domenic_> | TabAtkins: right, but I guess my distinction was between APIs and spec text. Spec text seems malleable, but I guess maybe not, at least in W3C world. |
| 17:27 | <TabAtkins> | It's not that it's not malleable, it's that it's just too pervasive to realistically change. We'd miss things, and there'd be persistent confusion. |
| 17:28 | <Hixie_> | yeah. that's why we changed the meaning of the term in the first place. so we'd hit all those places. |
| 17:28 | <Hixie_> | but we didn't think of the implications on getComputedStyle() |
| 17:29 | <Hixie_> | so now the API and the spec use different terms, just like for a while "URL" APIs referred to "URI" |
| 17:29 | <Hixie_> | (for that one we could rename URI back to URL in the specs because we weren't going to reuse URI for something else) |
| 17:29 | <Hixie_> | (so that one is a different case really) |
| 17:29 | <Hixie_> | (the term changed, not the meaning) |
| 17:35 | <TabAtkins> | Right. getComputedStyle is just an unfortunate casualty that will confuse people forever. |
| 17:35 | <TabAtkins> | But hopefully el.computedStyle.foo is sufficiently easier than getComputedStyle(el).foo that everyone will just switch to it. |
| 17:36 | <Hixie_> | it should confuse only us spec people |
| 17:36 | <Hixie_> | people who don't read specs need not be confusing |
| 17:36 | <Hixie_> | need not be confused, rather |
| 17:36 | <Hixie_> | we should just make sure we don't do something like have two apis that say they do the same thing but do different things |
| 17:36 | <Hixie_> | hence https://www.w3.org/Bugs/Public/show_bug.cgi?id=22528 |
| 17:38 | <TabAtkins> | We need a way to actually get the computed style for the handful of legacy properties. |
| 17:38 | <TabAtkins> | We can't call it something other than "computed style", because that's confusing to *everyone*. |
| 17:38 | <Hixie_> | call it something else :-) |
| 17:38 | <Hixie_> | cascadedValue or something |
| 17:38 | <TabAtkins> | That's a different concept. ^_^ |
| 17:38 | <Hixie_> | calculatedValue |
| 17:38 | <TabAtkins> | Also: no, that confuses *everyone*. It's the computed value. That's what it's called in every spec. The one and only place where it's called something different is the name of the getComputedStyle method. |
| 17:39 | <Hixie_> | it doesn't confuse everyone. it confuses the minority of peopel who read specs. |
| 17:39 | <Hixie_> | what will confuse everyone is having two apis with the same name that do different things. |
| 17:40 | <Hixie_> | this is exactly the kind of thing that makes people hate the web and makes other platforms make fun of us. |
| 17:40 | <TabAtkins> | What will confuse everyone is having a brand new name "calculated value" that doesn't exist in any spec. |
| 17:40 | <Hixie_> | rawComputedValue then |
| 17:40 | <Hixie_> | seriously, "everyone" is wrong there |
| 17:40 | <TabAtkins> | And if we tried to update to use it, we'd fail and miss parts, and then people would think that we actually meant to say "computed value" in some places. |
| 17:40 | <Hixie_> | it will only confuse people who read the spec |
| 17:41 | <TabAtkins> | Right. People who read tutorials will just read that getComputedStyle() is old and busted, and you should use .computedStyle instead. |
| 17:41 | <Hixie_> | that's so not how the web works |
| 17:41 | <Hixie_> | people keep using old APIs |
| 17:41 | <Hixie_> | they exist in code |
| 17:41 | <Hixie_> | we can't change that |
| 17:41 | <TabAtkins> | Sure. And? |
| 17:42 | <Hixie_> | we have to confuse someone. better it be the limited number of people who read the spec than be everyone. |
| 17:42 | <Hixie_> | everyone who uses the api |
| 17:42 | <TabAtkins> | I'd rather it be the authors here, honestly. This is the kind of detail that implementors can easily get wrong and produce confusing, long-lasting bugs. |
| 17:42 | <Hixie_> | i don't understand how you can think that having doc.getComputedStyle(element) != element.computedStyle is even something we could plausibly argue for |
| 17:42 | <Hixie_> | ...woah |
| 17:43 | <Hixie_> | wait, back up |
| 17:43 | <Hixie_> | you think it's better to confuse millions of authors than the four people who will implement this? |
| 17:44 | <TabAtkins> | It's not the four people. It's everyone who ever touches the relevant code, every time they look at a spec that mentions "computed value" or "calculated value", or meant to say one but wasn't updated so it says the other. |
| 17:44 | <TabAtkins> | We don't just have an internal list of computed values, you know. |
| 17:44 | <TabAtkins> | That stuff has to be calculated. |
| 17:44 | <Hixie_> | yes i am aware |
| 17:45 | <Hixie_> | i respectfully disagree that those people, for whom we can provide test cases, are more important than the entire javascript authoring community |
| 17:45 | <Hixie_> | users < authors < implementors < spec writers < theorists |
| 17:45 | <Hixie_> | where "<" is not "less than" :-) |
| 17:46 | <Hixie_> | but "rhs must defer to lhs" :-) |
| 17:56 | <TabAtkins> | Unless there are strong reasons not to, yes. |
| 18:02 | <Hixie_> | "we have to provide more tests and have an abundance of clarity in the specs" is not a strong reason, it's monday. |
| 18:05 | <annevk> | changing the spec concept of "computed style" to "calculated style" doesn't seem like a bad idea |
| 18:05 | <annevk> | it'll only confuse a handful of people for a while, and those are also the people that learn about the new thing soon enough |
| 18:06 | <Hixie_> | that could work, but i'm not even proposing that. i'm just proposing having the same warnings around .computedStyle as around .getComputedStyle, and having a separate .rawComputedStyle property. |
| 18:06 | <Hixie_> | i don't even think it's _that_ confusing for implementors, to be honest. |
| 18:13 | <Domenic_> | "this is exactly the kind of thing that makes people hate the web and makes other platforms make fun of us." +1 |
| 18:14 | <SimonSapin> | annevk: computed vs. calculated … that’ll be fun in non-English languages |
| 18:15 | <SimonSapin> | (both words translate to the same in French) |
| 18:15 | <Hixie_> | on a different note... can anyone see a way in which an HTML parser can see a <button> token while a button element is in scope, then, after implying the </button> end tag, end up in a place such that reprocessing the <button> start tag won't just end up back in the in body <button> handler with nothing else having changed? |
| 18:54 | <annevk> | SimonSapin: you'd just use the English word |
| 18:54 | <SimonSapin> | meh |
| 18:55 | <SimonSapin> | On parle déjà bien assez de « pusher des commits » et autres anglicismes … |
| 19:10 | <annevk> | Alles vertalen is niet echt nuttig als je ook naar internationale conferenties, artikelen erover leest in het Engels, etc. |
| 19:10 | <Ms2ger> | I think you accidentally a word there |
| 19:11 | <annevk> | Je gelijk |
| 19:48 | <esprehn> | so we're really making .computedStyle[x] != getComputedStyle(...).x ? |
| 19:48 | <Ms2ger> | getComputedStyle depends on the window |
| 19:49 | <Hixie_> | esprehn: i hope not... |
| 19:50 | <Hixie_> | Ms2ger: not any more than the .fooStyle attributes will |
| 19:50 | <Ms2ger> | otherWindow.getComputedStyle(el) applied otherWindow's styles to el, last I checked |
| 19:51 | <esprehn_> | Ms2ger: nope |
| 19:51 | <Ms2ger> | Does in Gecko |
| 19:51 | <esprehn_> | webkit has never implemented it that way |
| 19:51 | <Hixie_> | Ms2ger: woah, really? |
| 19:51 | <Ms2ger> | Sure |
| 19:52 | <Hixie_> | that's... exciting |
| 19:52 | Hixie_ | tests |
| 19:52 | <Ms2ger> | At least, as far as I can remember |
| 19:52 | <Ms2ger> | Testing is encouraged :) |
| 19:52 | <Hixie_> | Ms2ger: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2386 disagrees with you |
| 19:53 | <Ms2ger> | Quite possible |
| 19:54 | <Hixie_> | anyway, esprehn was talking about same-window stuff. As specced today, window.getComputedStyle(element).foo != element.computedStyle.foo, which is pretty crazy imho |
| 19:54 | <Ms2ger> | All of CSSOM is crazy |
| 19:54 | <Hixie_> | not that crazy... |
| 19:54 | <Ms2ger> | And the rest of the web too |
| 19:54 | <Hixie_> | not a reason to make it worse :-) |
| 19:56 | <Ms2ger> | Consistency in crappiness! :) |
| 19:56 | <esprehn_> | I'm with Hixie_ on this, people are going to want to polyfill the computedStyle thing, and using getComputedStyle will just return more wrongness |
| 19:57 | <esprehn_> | $.style(e) is going to be e.computedStyle && e.computedStyle[x] || getComputedStyle(e).x |
| 19:58 | <Hixie_> | yeah, that's a good example of the kind of thing that would trip people up |
| 19:58 | <Hixie_> | that code looks _obviously_ correct |
| 19:58 | <Hixie_> | and it is wrong in ways that are really hard to understand |
| 19:58 | <Hixie_> | as i said earlier, this is the kind of thing that authors hate us for |
| 20:01 | <fantasai> | annevk: The specs use "computed style" everywhere already. And we use "calculate" to indicate the perfomance of some computation without implying that it has anything to do with "computed style"... so it'd be kindof a pain to switch over :/ |
| 20:02 | <Hixie_> | the spec terminology is irrelevant since only a minority of authors read the spec |
| 20:02 | <fantasai> | annevk: That said, the terminology we're using in this area isn't particularly great to begin with... |
| 20:03 | <fantasai> | Hixie_: We'd definitely want to make the propdef tables match up, authors do look at that. |
| 20:03 | <fantasai> | Hixie_: That's at least easier to search & replace... |
| 20:03 | <annevk> | fantasai: I think the main concern is that most authors are familiar with "computed style" as whatever getComputedStyle does, not what specs say |
| 20:03 | <fantasai> | annevk: yeah, I totally agree |
| 20:03 | <Hixie_> | fantasai: that's already wrong today, so that's an entirely separate issue |
| 20:03 | <annevk> | and authors > specs, but transitioning is indeed a pain :/ |
| 20:04 | <annevk> | kinda like Hixie_ refusing to label something "almost standards mode" :p |
| 20:04 | <Hixie_> | "almost standards mode" is just a dumb term :-P |
| 20:04 | <Hixie_> | (when used in a standard to define behaviour) |
| 20:04 | <fantasai> | annevk: if we're going to do that massive of a transition, I think we might want to just overhaul all the terms... |
| 20:04 | <fantasai> | "used style" isn't great either |
| 20:04 | <fantasai> | :) |
| 20:04 | <annevk> | fantasai: sounds like you should wait for Last Call |
| 20:05 | <fantasai> | We're almost there... ;) |
| 20:05 | <fantasai> | Tab and I are preparing that draft this week, pretty much. |
| 20:05 | <Hixie_> | spec editors > theory, too, and changing terms like this is theoretically good but isn't good for spec editors |
| 20:07 | <annevk> | fantasai: I guess you guys can take it into account then |
| 20:07 | <annevk> | fantasai: if you don't you'll find the terms enshrined in APIs and you'll be stuck with them |
| 20:07 | <fantasai> | yeah :( |
| 20:08 | <fantasai> | maybe we can use "resolved style" for what CSS calls computed style |
| 20:08 | <annevk> | I guess you could flip them |
| 20:08 | <fantasai> | yeah |
| 20:08 | <Ms2ger> | Mm, more renamings |
| 20:08 | <Ms2ger> | Is it LC time? |
| 20:08 | <fantasai> | Naming things is hard! |
| 20:08 | Hixie_ | wonders why </caption> isn't optional |
| 20:08 | <fantasai> | Ms2ger: in fact it is, we have an open resolution to take Cascade to LC |
| 20:09 | <Ms2ger> | fantasai, I should have known :) |
| 20:13 | Hixie_ | finds another reason to drop the REC process... then css specs would never go to LC and so would never go through renaming rounds! |
| 20:50 | <esprehn_> | Hixie_: did we actually spec out "almost standards mode" ? |
| 20:50 | <esprehn_> | last I checked the documentation was a single mozilla page that hadn't been updated in 7+ years and was also wrong... |
| 20:50 | <Hixie_> | yes, it's called "limited quirks" mode |
| 20:50 | <Hixie_> | sorry, "limited-quirks" |
| 20:51 | <esprehn_> | ooh yay https://developer.mozilla.org/en-US/docs/Gecko's_Almost_Standards_Mode that page is updated |
| 20:51 | <Hixie_> | the term is defined in the DOM Core spec, and HTML triggers it and defines some things for it |
| 20:51 | <esprehn_> | awesome |
| 20:51 | <annevk> | esprehn_: http://quirks.spec.whatwg.org/ |
| 20:52 | <esprehn_> | wait, that says "almost standards" where does it say limited-quirks? |
| 20:52 | <esprehn_> | or html calls it one thing, and invokes the other thing in dom core? :P |
| 20:54 | <Hixie_> | quirks.spec.whatwg.org uses terminology different than dom core and html |
| 20:54 | <Hixie_> | html was the first to the scene on this, so in addition to the other term not actually being sane, it's also not following precedent :-P |
| 20:56 | <annevk> | Hmm, so Indie UI is happening... https://www.webkit.org/blog/2728/last-two-weeks-in-webkit-better-events-and-new-apis/ |
| 20:56 | <annevk> | I feel for the person who will eventually have to figure out UI events. And the longer that lingers, the more I fear it'll be me :/ |
| 20:57 | <annevk> | esprehn_: it calls them "almost standards mode" but it links to "limited-quirks mode" |
| 20:57 | <annevk> | esprehn_: I don't even... |
| 20:59 | <esprehn_> | annevk: just because it's in webkit doesn't mean anyone will ship it |
| 20:59 | <annevk> | @apple.com and one guy from @apple.com is an editor |
| 21:00 | <esprehn_> | ah well then... |
| 21:00 | <annevk> | but yes, Apple shipping doesn't mean it's happening necessarily |
| 21:01 | <annevk> | it just means it's quite likely and will be a pain, since nobody has actually defined user interaction events in any sufficient amount of detail yet, yet everyone is keen on adding more of them and new wild layers of abstraction without understanding what's there |
| 21:07 | <esprehn_> | this is an interesting spec |
| 21:11 | <Hixie_> | seems like exactly what we need, though i'm not sure i agree with the exact events |
| 21:12 | <Hixie_> | but that's a typical bikeshed issue |
| 21:12 | <Hixie_> | so i'll defer to the editor |
| 21:12 | <Hixie_> | i'm glad that apple is doing this, since they were the main ones to break this back with safari on ios :-) |
| 21:13 | <Hixie_> | "precise, timing of incoming events. |
| 21:13 | <Hixie_> | Santosh Mahto changed the relations between media loading and the load event of a page. Before the patch, any <video> and <audio> elements would delay the load event until the media started loading or 3 seconds without progress. For media elements with preload=”none”, the code would be hitting the 3 seconds delay before firing the page’s load event. After the change, <video> and <audio> do not delay a page’s load event." |
| 21:13 | <Hixie_> | seems a bit dubious |
| 21:13 | <Hixie_> | wonder what the spec says exactly |
| 21:13 | <annevk> | as long as they actually define the whole chain of events and not just "sorta this happens" it would indeed be pretty great |
| 21:14 | <Hixie_> | annevk: agreed |
| 21:14 | <Hixie_> | hm, spec says they should fire 'suspend' then 'load' |
| 21:14 | <Hixie_> | wonder if they're following the spec there |
| 21:15 | <annevk> | "The event loop will be specified as part of ES6." https://www.w3.org/Bugs/Public/show_bug.cgi?id=22522#c7 Consider me sceptical |
| 21:21 | <Hixie_> | i've heard people say that, but i haven't seen anyone from TC39 reach out to talk about how to do that transition. |
| 21:21 | <Hixie_> | nor do i really understand how that will work, since the event loop applies when scripting is disabled, too |
| 21:21 | <Hixie_> | and when the only scripting language is something other than JavaScript |
| 21:28 | <jsbell> | nit: TC39 is saying ES7 now. (Otherwise, no comment.) |
| 21:29 | <Hixie_> | what does TC39 mean by "the event loop"? |
| 21:30 | <Hixie_> | i really don't understand how this would work or why JS would be the right place for it |
| 21:30 | <Hixie_> | a browser with no JS support still needs an event loop... |
| 21:41 | <jsbell> | ISTR TC39 want to define a processing model that includes an event loop and concurrent entities called "vats"; they would map onto the browser's event loop and Workers, respectively. |
| 21:41 | <jsbell> | http://wiki.ecmascript.org/doku.php?id=strawman:concurrency |
| 21:43 | <jsbell> | Yeah, that gives reasonable justification for why you'd want to define the concepts in JS. It's hard to have async Promises well defined in the language without async being defined. |
| 21:43 | <Hixie_> | i don't really understand that page, but what i do understand seems fine. Seems like the way to do it is to expose hooks that the environment can hook into, though. |
| 21:43 | <Hixie_> | i mean, if JS defines its own actual loop, that ain't gonna work |
| 21:43 | <jsbell> | Also: Browsers without JS need an event loop. JS without browsers also needs an event loop. |
| 21:44 | <Hixie_> | yeah |
| 21:44 | <jsbell> | I think the intent was to formalize the hook. But I'm just a fly on the wall |
| 21:44 | <Hixie_> | well, hopefully they reach out to the people who have written the existing event loop stuff |
| 21:44 | <Hixie_> | i haven't heard anything from tc39 people |
| 21:44 | <Hixie_> | only from flies on walls :-) |
| 22:02 | <Hixie_> | man, this parser change is invasive |
| 22:02 | <Hixie_> | gsnedders is gonna hate me |
| 22:02 | <Hixie_> | hopefully the browsers are gonna like it... |
| 22:02 | <Hixie_> | (it's fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=21308) |