| 05:58 | <mathiasbynens> | quick WebIDL question: is there an easy way to mark an attribute as non-configurable (other than [LegacyUnforgeable], which does that + more)? |
| 07:43 | <zcorpan_> | annevk: are we doing only TPAC breakout sessions, or a "WG" meeting this week? |
| 07:46 | <zcorpan_> | mathiasbynens: per https://heycam.github.io/webidl/#define-the-attributes attributes are only non-configurable if they're LegacyUnforgeable |
| 07:47 | <zcorpan_> | mathiasbynens: but constants are also non-configurable |
| 07:47 | <mathiasbynens> | zcorpan_: I was afraid of that. thanks for confirming |
| 07:48 | <zcorpan_> | mathiasbynens: whare are you trying to do? |
| 07:51 | <mathiasbynens> | zcorpan_: `navigator.webdriver` is currently configurable, and so spammers using WebDriver/Puppeteer like to `delete` it to try and bypass protections |
| 07:52 | <mathiasbynens> | zcorpan_: all it takes to fix this is to mark it non-configurable, and I was wondering if there was a way to do that directly, since LegacyUnforgeable does more (in particular, it moves it from the prototype to an own property) |
| 07:55 | <zcorpan_> | mathiasbynens: hmmm. navigator itself isn't LegacyUnforgeable |
| 08:17 | <tobie> | annevk: Just checking to see if pr-preview is stable for you since the changes I made last week (I have no signs that it isn’t; just wanted to make sure you’re all good). |
| 09:45 | <annevk> | tobie: I think so, yes, but I'll ping you if not 🙂 |
| 09:45 | <annevk> | tobie: thanks for looking into it |
| 12:45 | <mathiasbynens> | does AVIF need an entry on https://mimesniff.spec.whatwg.org/#matching-an-image-type-pattern or not? |
| 12:49 | <annevk> | mathiasbynens: afaik it's mp4 |
| 12:49 | <annevk> | mathiasbynens: or at least an existing container thingy |
| 12:50 | <annevk> | mathiasbynens: hmm, but maybe that does mean that should be updated as that only covers images |
| 12:50 | <annevk> | mathiasbynens: I had only considered it from the perspective of https://github.com/annevk/orb |
| 12:51 | annevk | wonders if that's enough reason to still try to require a MIME type |
| 13:51 | <croraf> | Anyone knows if ES is parsable by LR(1) parser? |
| 13:56 | <annevk> | jorendorff: ^ |
| 13:58 | <jorendorff> | croraf: You have to use lots of force to jam ES into an LR(1) form |
| 13:58 | <jorendorff> | please see https://github.com/mozilla-spidermonkey/jsparagus/blob/master/js-quirks.md |
| 13:58 | <jorendorff> | if you don't want to read all that, then the answer is no for you :) |
| 13:59 | <croraf> | thanks jorendorff , i also put the same quesiton on jsparagus discord :) |
| 13:59 | <jorendorff> | haha |
| 14:00 | <croraf> | So in short, does JSparagus use LR(1) or some other type? And which one would you recommend now to use? |
| 14:03 | <croraf> | jorendorff, I remember these quirks being a lot shorter last time i checked half a year ago :| |
| 14:05 | <jorendorff> | croraf: it depends on the goal. if you want a complete JS parser e.g. for writing a standard-compliant JS engine, then |
| 14:05 | <jorendorff> | by far the easiest thing that will work is recursive descent |
| 14:06 | <croraf> | this will have bad performance? jorendorff |
| 14:07 | <jorendorff> | Recursive descent can have good performance because it's extremely hackable |
| 14:07 | <jorendorff> | If you write the dumbest thing that can possibly work, then the performance is so-so |
| 14:08 | <jorendorff> | but it's easy to hack in some optimizations to make it a bit faster, and then a bit faster again... |
| 14:10 | <croraf> | jorendorff, thanks a lot. I think in Boa we actually use recursive descent. |
| 14:10 | <jorendorff> | Yes, I think so |
| 14:11 | <jorendorff> | I think all the major JS implementations do. jsparagus was trying something outside the mainstream :) |
| 14:12 | <croraf> | cool, jorendorff you are the best ;) |
| 14:12 | jorendorff | blushes. |
| 14:18 | <croraf> | jorendorff, Was this the case of putting something in the editorial version of the spec that was not LR(1) compliant that was then immediately removed from the spec? https://github.com/tc39/ecma262/issues/776 |
| 14:19 | <jorendorff> | The `async of` conflict is separate. As far as I know it was never discussed in the standard committee and hasn't been removed. |
| 14:22 | <croraf> | jorendorff, yes, I'm not talking about "async of" example but mentioning this as another similar example that was revoked? |
| 14:23 | <jorendorff> | Yes, that's right |