| 03:12 | <annevk> | Domenic: was also thinking of allowing Error to be cloned per JakeA's request since aklein doesn't think that is problematic |
| 03:12 | <annevk> | Domenic: if you remove the slot it would be though, but I suppose that is unlikely now |
| 03:16 | <Domenic> | Seems reasonable. I should probably just close that PR. |
| 03:27 | <MikeSmith> | rniwa: it’s really nice to see the implementation coming together and the wrinkles getting ironed out |
| 03:28 | <MikeSmith> | and the iteration back into spec discussion that falls out from the implementation work |
| 03:34 | <rniwa> | MikeSmith: indeed. |
| 05:48 | <annevk> | Hmm cloning Error and friends is a little trickier than I thought |
| 05:51 | <annevk> | I suspect browsers actually have more branding on them than just [[ErrorData]] |
| 10:17 | <annevk> | nox: what setup does Servo have for https://github.com/whatwg/dom/issues/34? |
| 10:21 | <zcorpan> | https://html.spec.whatwg.org/#attr-translate - does this mean Text node children or Text node descendants? |
| 10:23 | <annevk> | zcorpan: children |
| 10:23 | <annevk> | zcorpan: it inherits |
| 10:23 | <zcorpan> | ah |
| 10:55 | <MikeSmith> | I had meant to make time to look at the “allow <link> in body for external resource links” change before it landed, as far as the document-conformance part at least |
| 10:56 | <MikeSmith> | need to figure out how to make more time for stuff going forward |
| 10:56 | <MikeSmith> | anyway it seems like zcorpan looked at that part in detail and if so then I’m confident |
| 10:57 | <MikeSmith> | now I need to update the checker |
| 11:02 | <MikeSmith> | well |
| 11:04 | <MikeSmith> | one thing I notice is that we ended up with no (informative) list in one place in the spec that says, The attributes that are body-ok are pingback, prefetch, and stylesheet. |
| 11:05 | <MikeSmith> | the lack of that seems suboptimal for author/developer readers |
| 11:05 | <MikeSmith> | because we are forcing them to look at the spec text of every single rel value themselves to figure out which ones are body-ok |
| 11:06 | <MikeSmith> | it at least could be flagged in the table just after https://html.spec.whatwg.org/multipage/semantics.html#body-ok |
| 11:07 | <MikeSmith> | zcorpan: |
| 11:07 | <MikeSmith> | zcorpan: ⬆ |
| 11:07 | <MikeSmith> | if you agree, I’ll raise a follow-up PR that adds it |
| 11:08 | <zcorpan> | MikeSmith: good idea |
| 11:08 | <zcorpan> | new column i guess |
| 11:08 | <MikeSmith> | hai |
| 11:08 | <MikeSmith> | yeah |
| 11:25 | <MikeSmith> | hmm that change also |
| 11:26 | <MikeSmith> | * that change also muddied up the relationship of the 「Thus, rel="next" is the same as rel="NEXT".」example to the spec text that previously had immediately preceded it |
| 11:26 | <MikeSmith> | will correct that too |
| 11:46 | <zcorpan> | MikeSmith: oops. i should be checking the output more carefully |
| 11:48 | <MikeSmith> | no biggy |
| 11:50 | <MikeSmith> | I’m not too keen on the vagueness of “Certain keywords are said to be”, so will futz that part too |
| 11:52 | <MikeSmith> | which is going to end up maybe with a bit belt-and-suspenders redudancy but I think it will still be better for readers |
| 11:52 | <MikeSmith> | more clear |
| 12:02 | <zcorpan> | MikeSmith: note that other specs can define keywords too, and say that those are body-ok (e.g. preload) |
| 12:03 | <MikeSmith> | zcorpan: well, so we should say that too then |
| 12:04 | <MikeSmith> | instead of leaving it unstated |
| 12:04 | <MikeSmith> | because the current spec text says nothing about that as far as I can see |
| 12:04 | MikeSmith | re-reads to see if he missed something |
| 12:06 | <zcorpan> | 4.6.6.17 Other link types needs to mention body-ok |
| 12:07 | MikeSmith | looks there |
| 12:08 | <MikeSmith> | hmm yeah |
| 12:08 | <MikeSmith> | this is becoming a bit of a thread-pulling thing |
| 12:09 | <MikeSmith> | because that means the microformats wiki also needs to be updated |
| 12:11 | <MikeSmith> | zcorpan: right? I mean a column needs to be added to the tables there |
| 12:13 | <zcorpan> | MikeSmith: it depends. could say that it's the responsibility of the Specification to talk about body-ok if it wants it allowed in the body, it doesn't need to be in the wiki |
| 12:13 | <MikeSmith> | yeah |
| 12:13 | <MikeSmith> | you’re right |
| 12:14 | <MikeSmith> | that’s better |
| 12:23 | <nox> | annevk: I implemented an UnbindingContext. |
| 12:23 | <nox> | For the removing steps that are called recursively. |
| 12:25 | <nox> | annevk: You don't explain why you want to call them on ancestors though. |
| 12:36 | <annevk> | nox: I don't |
| 12:36 | <annevk> | nox: but insertion steps isn't yet called on descendants |
| 12:36 | <nox> | annevk: Ok, misunderstood what it was about. |
| 12:36 | nox | annevk: Sounds like a bug indeed. |
| 12:37 | <nox> | annevk: Wait, you sure? |
| 12:37 | <nox> | annevk: https://dom.spec.whatwg.org/#concept-node-insert-ext Step 6? |
| 12:37 | <annevk> | nox: how does that include descendants? |
| 12:37 | <nox> | Oh right, never mind. |
| 12:37 | <nox> | Just woke up. :P |
| 12:38 | <annevk> | Also, that the removing steps are passed oldPreviousSibling doesn't match any browser and that we pass oldParent is weird, because for most descendants it'll be an ancestor, not a parent |
| 12:38 | <annevk> | I guess I'll just go with oldAncestor |
| 12:38 | <nox> | annevk: We discussed that. |
| 12:39 | <nox> | We discussed that last year, when I implemented that crap in Servo. |
| 12:39 | <annevk> | I know we did, this issue is old |
| 12:39 | <nox> | annevk: I wanted two kind of hooks, and someone here convinced me that we could just distinguish parent from ancestor by checking whether the child's parent is oldParent. |
| 12:39 | <nox> | annevk: Want me to link Servo's code? |
| 12:40 | <annevk> | nox: sure, doesn't hurt |
| 12:40 | <annevk> | nox: I believe Chrome has distinct calls for parent change and ancestor change, but I'm not sure we need that in the spec |
| 12:41 | <nox> | annevk: Mmmh, we don't, but it might make some prose a bit weirder. |
| 12:41 | <nox> | "If child's parent isn't oldParent, abort these steps" or things like that. |
| 12:41 | <nox> | annevk: Every time I look at our implementation of DOM, some step numbers changed. :( |
| 12:42 | <annevk> | Yeah, maybe, but we could abstract things too with prose if it get unwieldy |
| 12:42 | <annevk> | nox: what can I say, the web evolves |
| 12:42 | <nox> | :D |
| 12:42 | <annevk> | nox: also, I think you might be responsible for most recent changes there |
| 12:43 | <annevk> | Oooh, maybe zcorpan is |
| 12:43 | <zcorpan> | did i break something? |
| 12:44 | <nox> | annevk: We recursively call insertion and removing steps on all descendants, |
| 12:44 | <nox> | annevk: and for removing, here is the data passed around: https://github.com/servo/servo/blob/master/components/script/dom/node.rs#L2471-L2482 |
| 12:44 | <annevk> | zcorpan: you might have broken where comments in Servo point to |
| 12:44 | <annevk> | zcorpan: sorry for pinging |
| 12:44 | <nox> | annevk: We cache the index of the removed node and whatnot because we piggy-back this loop to update DOM ranges. |
| 12:44 | <zcorpan> | ah |
| 12:44 | <nox> | annevk, zcorpan: Oh well, that's an E-Easy issue for newcomers, maybe I should thank zcorpan. ;) |
| 12:45 | <annevk> | nox: curious that you pass the oldPreviousSibling |
| 12:45 | <annevk> | nox: browsers don't |
| 12:45 | <nox> | annevk: We do use it for some reason, let me find where again. |
| 12:45 | <nox> | annevk: The stec want it, no? |
| 12:45 | <nox> | spec* wtf |
| 12:45 | <annevk> | I don't want it if browsers don't have it |
| 12:45 | <nox> | annevk: Oh yeah, |
| 12:46 | <nox> | annevk: UnbindContext::index needs it. |
| 12:46 | <nox> | annevk: https://github.com/servo/servo/blob/master/components/script/dom/node.rs#L2503 |
| 12:46 | <nox> | annevk: I didn't want to compute the index if nothing needed it. |
| 12:49 | <nox> | annevk: That there is the old previous sibling is not public in the API of UnbindContext btw, |
| 12:49 | <nox> | annevk: so feel free to nuke it away, even Servo doesn't care. |
| 12:50 | <annevk> | Good times |
| 12:50 | <annevk> | The reason this comes up now by the way is that this will get more complicated with shadow DOM |
| 12:51 | <annevk> | Because then we don't just include descendants, but also any shadow trees hosted by any descendants, etc. |
| 12:54 | <nox> | annevk: I see. |
| 12:56 | <nox> | annevk: Just realised Document.all is still going on. |
| 12:56 | <annevk> | 24/7 entertainment |
| 12:58 | <nox> | annevk: Especially given we are all over the world. :D |
| 12:58 | <nox> | It really gets 24/7 comments. |
| 13:09 | <annevk> | Sigh, bikeshed again changes random shit in the output |
| 13:09 | <annevk> | It's getting to the point where I just avoid editing bikeshed specs |
| 13:13 | <JakeA> | Would love bikeshed to switch to node, I think it'd be easier to contribute then. Never been able to get bikeshed running locally, kept rabbit-holeing on dependencies that wouldn't install |
| 13:19 | <annevk> | It's such a non-deterministic piece of crap ugh |
| 13:20 | <annevk> | I was hoping to make some progress on DOM but it's no fun if the tools fall apart |
| 13:22 | <annevk> | I think I actually might be better off with Anolis |
| 13:22 | <annevk> | bikeshed has been nothing but pain and all the promised features of auto-linking are in a constant state of broken |
| 13:33 | <nox> | JakeA: I don't see what switching to Node brings. |
| 13:33 | <nox> | JakeA: That still means dependencies to install. |
| 13:34 | <nox> | annevk: What was used before bikeshed? |
| 13:34 | <annevk> | Anolis |
| 13:34 | <nox> | annevk: And why does it break stuff all the time? |
| 13:34 | <JakeA> | nox: in my experience it's way simpler. Node & npm install easily, then it's just npm install |
| 13:35 | <JakeA> | nox: compare that to https://github.com/tabatkins/bikeshed/blob/master/docs/install.md |
| 13:35 | <annevk> | nox: I have no idea, presumably because Tab keeps landing changes without verifying that they don't change existing outputs |
| 13:35 | <nox> | JakeA: Didn't encounter any problem with building Bikeshed, and given what I hear about npm… |
| 13:35 | <JakeA> | I don't know what you hear |
| 13:35 | <annevk> | nox: you can review https://github.com/whatwg/dom/pull/184 though |
| 13:36 | <nox> | JakeA: Same experience as you with bikeshed-as-Python-tool, mostly. |
| 13:36 | <nox> | annevk: Filed a ticket on bikeshed btw? |
| 13:36 | <annevk> | yeah, see PR |
| 13:37 | <nox> | annevk: Can we really say the descendant of an inserted node is an inserted node? |
| 13:37 | <JakeA> | nox: where are you hearing that from? |
| 13:37 | <annevk> | yes |
| 13:37 | <nox> | JakeA: Frustrated people on the IRC. |
| 13:38 | <nox> | annevk: Not renaming the newNode in the loop? |
| 13:38 | <JakeA> | The complaints I hear about NPM are speed rather than complexities around having to install a load of global dependencies with sudo |
| 13:38 | <JakeA> | I can't remember the last time I had to do that with npm |
| 13:38 | <annevk> | nox: I guess we could rename that node |
| 13:39 | <jgraham> | JakeA: TabAtkins' instructions are crazy. Install python stuff into virtualenvs not globally |
| 13:40 | <jgraham> | But my experience is that everyone likes the package manager they are used to |
| 13:40 | <annevk> | JakeA: would happily switch to something node-based |
| 13:40 | <jgraham> | To me "we should rewrite X because it's not in javascript" is terrible reasoning |
| 13:40 | <JakeA> | jgraham: ahh, maybe it is just an instructions thing. If memory serves I was getting tripped up on the macports stuff. |
| 13:41 | <jgraham> | Yeah, I wouldn't write the instructions like that |
| 13:41 | <nox> | jgraham: Same. |
| 13:41 | <annevk> | jgraham: the reasoning is more that it'd be maintained by JakeA and not TabAtkins |
| 13:42 | JakeA | runs away |
| 13:42 | <annevk> | ECMAScript has something node-based too |
| 13:42 | <JakeA> | But if the tool is for a web developer audience, writing it in web technologies seems better for a comunity |
| 13:42 | <annevk> | https://github.com/bterlson/ecmarkup |
| 13:43 | <JakeA> | for the community* |
| 13:43 | <jgraham> | If your answer was "we should Go from N tools to N-1 tools", that seems reasonable. If it's |
| 13:43 | <jgraham> | "we should go from N tools to N+1 tools" that's less reasonable |
| 13:43 | <Ms2ger> | Rust :) |
| 13:43 | <nox> | Says the guy who doesn't want to see codegen in Rust. :P |
| 13:44 | <jgraham> | I was going to say, write it in Rust, ship a binary that doesn't require any installation, and encourage web developers to broaden their skillset to contribute :) |
| 13:44 | <nox> | That being said, |
| 13:44 | <jgraham> | I guess Hixie would say the same but s/Rust/FreePascal/ |
| 13:44 | <jgraham> | ;) |
| 13:44 | <nox> | we do have a working HTML parser and that would be a good test. |
| 13:45 | <nox> | (Test as in "is that useful outside of Servo and its author's own projects".) |
| 13:47 | <jgraham> | nox: It also requires some rather large amount of free time to get it working :) |
| 13:47 | <jgraham> | (a useful spec generator, I mean) |
| 13:47 | <nox> | True. :) |
| 13:48 | <annevk> | Maybe gsnedders wants to do it again |
| 13:49 | <Ms2ger> | I know I don't |
| 13:51 | <annevk> | ecmarkup is prolly the best bet |
| 13:52 | <annevk> | although I haven't really tested its speed |
| 13:56 | <nox> | If I had that free time, I would rather rewrite our WebIDL parser in Rust. |
| 13:56 | <nox> | I don't have that free time. |
| 15:23 | <dbkaplun> | Is there some relation between whatwg and ecma262? |
| 15:23 | <Ms2ger> | Yes, Domenic :) |
| 15:25 | <dbkaplun> | Does WhatWG as a group have any influence over the JS spec or is it just Domenic? |
| 15:27 | <Ms2ger> | Not more than the sum of the people that make it up |
| 15:28 | <TabAtkins> | annevk: Woah, what in the actual fuck is going on with the <p> stuff. I haven't touched that area in ages. |
| 15:29 | <annevk> | Hope you can excuse the vented frustration earlier |
| 15:30 | <Ms2ger> | (Please don't move back to anolis) |
| 15:30 | <TabAtkins> | Totally. (Tho it's interesting that you're the only person I've heard such complaints from.) |
| 15:32 | <annevk> | Maybe nobody else actually looks at what's being generated? |
| 15:32 | <TabAtkins> | That's mostly true, yeah. |
| 15:32 | <annevk> | That's how the CSS WG operates, no? |
| 15:34 | <astearns> | fantasai complains about the output, but then just fixes things manually |
| 15:35 | <annevk> | Oh my |
| 15:38 | <nox> | Occasionally-venting-to-people-who-know-you-are-just-frustrated FTW. |
| 15:42 | <TabAtkins> | Luckily, most of her complaints are with the data source - a bunch of specs haven't been published in a while, and so she can't get good linking into the TR versions. |
| 15:43 | <TabAtkins> | (I just went thru a bug of hers with about a dozen complaints - one I'd already fixed, one I filed a new bug for, and the rest were just specs with bad or old markup.) |
| 15:43 | <TabAtkins> | annevk: Yo, I can't reproduce your <p> bug. Those two paragraphs seem to gen just fine to me. |
| 15:44 | <annevk> | TabAtkins: you don't get a gigantic diff? |
| 15:45 | annevk | wonders what is going on then |
| 15:45 | <TabAtkins> | No, if I freshly gen the master branch, there's just a few points. The biblio index part has a decent diff because I stopped generating useless self-links there. |
| 15:45 | <TabAtkins> | But otherwise it's just two constructors that the new widlparser code recognizes have optional args. |
| 15:49 | <TabAtkins> | annevk: Oh, *now* I see a problem. I had to apply one of the changes in your branch. |
| 15:49 | <TabAtkins> | There must be something fucked up with comment handling. |
| 15:50 | <annevk> | I see, I think there's other comments |
| 15:50 | <TabAtkins> | Yeah, I'm confused. Let me fiddle with this. |
| 15:50 | <TabAtkins> | (This is almost certainly not a recent problem, fwiw - I haven't touched the relevant parts of the code in a while. This is something old you're the first to hit.) |
| 15:51 | <annevk> | TabAtkins: oh wow, <script> element to script element does wonders |
| 15:51 | <Ms2ger> | Ha |
| 15:51 | <annevk> | TabAtkins: what is going on there? |
| 15:51 | <annevk> | I'll do script element for now then |
| 15:52 | <TabAtkins> | Ah, yeah, that's the problem. Just figured it out myself. |
| 15:52 | <TabAtkins> | That's... interesting. |
| 15:54 | <annevk> | Are you parsing HTML with a regexp? |
| 15:55 | <TabAtkins> | Oh god no. |
| 15:55 | <TabAtkins> | I *am* parsing *Markdown* with a regex, which happens before the HTML parser has a chance to run. |
| 15:56 | <jgraham> | Now you have two problems? |
| 15:56 | <TabAtkins> | And my check for "am I entering a block that shouldn't have any processing done to it" is naive and just checks for the existence of <script>/<pre>/<style> start tags on the line. |
| 15:56 | <TabAtkins> | So it misfires on that comment line, and then the rest of your document stops being markdown-processed because you don't have a stray </script> anywhere. ^_^ |
| 15:57 | <TabAtkins> | So you don't get paragraphs anymore. |
| 15:57 | <annevk> | I have no response |
| 15:58 | <TabAtkins> | Hey, Markdown is crazy pants and there's no official parser. |
| 15:58 | <TabAtkins> | (And I couldn't use one anyway, because the interaction of indented code blocks and html nesting is crazypants and would fuck everything up. Indented code blocks are a misfeature.) |
| 15:59 | <TabAtkins> | So anyway, I'll file a bug on myself and figure out how to deal with comments. |
| 15:59 | <TabAtkins> | For now, yeah, just don't put a literal "<script>" (or <pre> or <style> or <xmp>) inside of a comment. |
| 16:00 | <jgraham> | It does feel like the solution to "format X can't be parsed" might be "don't use format X" |
| 16:00 | <TabAtkins> | Tell that to everyone who loves Markdown (including me). |
| 16:02 | <annevk> | ecmarkup handles Markdown inclusion better I think |
| 16:02 | <annevk> | And has linking extensions on top that make it quite neat |
| 16:03 | <TabAtkins> | Ooh, hadn't heard of the linking extensions. |
| 16:04 | <annevk> | Stuff like "1. Let _x_ be ? SomeAbstractOperation(_y_)." links the operation |
| 16:04 | <annevk> | It's quite nice and makes ECMAScript one of the better formatted specifications out there |
| 16:04 | <annevk> | Platform is kind of a jungle compared to that |
| 16:05 | <nox> | Markdown has a specification now, no? |
| 16:06 | <annevk> | Not according to its inventor |
| 16:06 | <TabAtkins> | nox: Yeah, commonmark, but it still contains indented code blocks, which interact *terribly* with "let's mix lots of raw HTML into it too". |
| 16:06 | <nox> | Disregard inventor. :P |
| 16:06 | <TabAtkins> | Nobody cares what gruber thinks about it, since he refuses to "spec" anything further than "whatever bullshit perl I vomited into this file, bugs and all". |
| 16:07 | <nox> | I don't get his train of thought. |
| 16:07 | <annevk> | Given that every application of it requires slightly different extensions, he doesn't seem so wrong really |
| 16:08 | <annevk> | It's highly contextual |
| 16:08 | <nox> | Talking about contextual things, |
| 16:08 | <nox> | if someone is sad to have done too much bikeshed today, |
| 16:08 | <nox> | here is a photo of my cats thinking they are Legos. https://usercontent.irccloud-cdn.com/file/xRr4n7J1/1457096736.JPG |
| 16:09 | <nox> | It's important to have cats when doing spec editing. |
| 16:10 | <jgraham> | So there's something to eat your body if it all becomes too much and you lose the will to live? |
| 16:10 | <nox> | jgraham: So that if all is Hell, at least you have cats to pet. |
| 16:11 | <TabAtkins> | Hm, I was thinking I could do a preprocessing step to remove comments first (and restore them afterwards), but that won't help if you do <div title="hahaha here's a <script> tag fukker">. |
| 16:11 | <TabAtkins> | So maybe I'll just make the "I'm starting a block" check more restrictive, and require those tags to be the first non-WS content on their line. This has a chance of breaking things, tho. |
| 16:20 | <TabAtkins> | Okay, added a comment to the Breaking Changes Notification Thread, we'll see if anything shakes out. |
| 16:20 | <TabAtkins> | Thanks for finding the bug, annevk. ^_^ |
| 16:21 | <annevk> | I hope you checked that fix on a couple of specs |
| 16:42 | <TabAtkins> | I haven't made the fix yet. |
| 16:42 | <TabAtkins> | Wont' for a couple days at least. |
| 16:52 | <Ms2ger> | TabAtkins, is http://www.adambarth.com/papers/2009/barth-caballero-song.pdf in the references database bikeshed uses, and how can I get it made so? |
| 16:52 | <TabAtkins> | specref.org is the place you want to check |
| 16:53 | <TabAtkins> | And it looks like no. |
| 16:53 | <Ms2ger> | Can I add it in a spec-local way? |
| 16:54 | <Ms2ger> | TabAtkins, ^ |
| 16:55 | <TabAtkins> | Yeah, with a <pre class=biblio> block. https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md#bibliography, look at the first code-block in that section for an example. |
| 16:55 | <TabAtkins> | And I can get it into SpecRef no problem, I have commit rights now. |
| 16:56 | <TabAtkins> | Oh gosh I need to update some of the text in that documentation section. |
| 16:59 | <Ms2ger> | https://github.com/whatwg/mimesniff/pull/6 |
| 16:59 | Ms2ger | poofs |
| 17:04 | <TabAtkins> | That... is a remarkably small diff for a Bikeshed move. |
| 17:14 | <annevk> | It's not done it seems |
| 17:14 | annevk | hopes Ms2ger coordinates with padenot |
| 19:37 | <gsnedders> | annevk: I have no interest in writing a spec generator, really. Maybe a touch of interest in trying to see if I can get it elegantly done with loop fusion. Maybe once the next PyPy and lxml releases come out see how much work is involved in getting bikeshed running there |
| 19:38 | <TabAtkins> | Iirc, I'm only stuck on Python 2 to make plinss's life easier, because Shepherd has some py2-only dependencies (involving Mercurial, I think). |
| 19:39 | <gsnedders> | TabAtkins: pypy is pretty much py2-only |
| 19:39 | <gsnedders> | but so much quicker |
| 19:39 | <TabAtkins> | Oh, cool. |
| 19:39 | <TabAtkins> | I'd love quicker! Free perf gains are always nice. |
| 19:39 | <gsnedders> | There *is* PyPy3k, but it's several releases behind CPython |
| 19:40 | <gsnedders> | Also it's slower than PyPy, because all the work on it has been about getting it complete rather than fast |
| 19:43 | <TabAtkins> | (Some clever applications of loop fusion would probably be good - a significant part of Bikeshed's runtime is running selectors, and a single double-size selector run once is much less expensive than two selectors run separately.) |
| 19:53 | <gsnedders> | TabAtkins: right, this was true in Anolis too, essentially. It's also why we really want to move to PyPy, a lot of the overhead of running selectors is interpreter overhead rather than anything inherently CPU expensive |
| 19:54 | <gsnedders> | TabAtkins: but it's why I'm really curious about Haskell for this, given loop fusion is pretty easy to achieve where needed, in part because of the purity |
| 21:12 | <aklein> | Domenic, annevk: so remember how I said it was fine to check enumerability as you go in structured clone? |
| 21:12 | <aklein> | I now think that's wrong |
| 21:12 | <Domenic> | aklein: you mean how I thought it was fine to trigger multiple proxy traps since proxies are disallowed? Or something else? |
| 21:12 | <aklein> | Domenic: not because of proxies |
| 21:13 | <aklein> | the issue is, which set of properties should we loop over? |
| 21:13 | <aklein> | the way the spec does it, we loop over all the own keys |
| 21:13 | <aklein> | and then interleave checks for enumerability with calls to [[Get]] |
| 21:13 | <Domenic> | ah, i see! |
| 21:14 | <aklein> | neither WebKit or Blink |
| 21:14 | <aklein> | do that |
| 21:14 | <aklein> | (they both check for enumerability up front) |
| 21:14 | <Domenic> | aklein: want to file it, or shall i? |
| 21:15 | <aklein> | Domenic: if you wouldn't mind.... |
| 21:15 | <aklein> | I assume you're fine with checking enumerability before triggering any possible side effects? |
| 21:15 | <aklein> | (especially given it matches implementations :) |
| 21:17 | <Domenic> | aklein: yeah that sounds totally fine, I think the current spec is just doing that because it was easy to spec/matched some existing ES prose. |
| 21:17 | <Domenic> | The old spec said something like "for each own enumerable property" so this is kind of a regression |
| 21:20 | <Domenic> | aklein: wait, how is this observable again? concrete example? |
| 21:20 | <Domenic> | a throwing non-enumerable getter won't be triggered. a throwing enumerable getter will be. seems the same as before, assuming no proxies. |
| 21:35 | <nox> | annevk: Are pseudo-elements supposed to be handled in DOM's Element.matches? |
| 21:35 | <nox> | As per the spec currently, they are. |
| 21:36 | <nox> | Cc SimonSapin. |
| 21:36 | <nox> | http://logs.glob.uno/?c=mozilla%23servo#c379296 |
| 21:37 | <SimonSapin> | specifically https://drafts.csswg.org/selectors-4/#evaluate-a-selector "APIs using this algorithm […] may optionally provide […] which pseudo-elements are allowed to show up in the match list, if any. If not specified, this defaults to allowing all pseudo-elements." |
| 21:50 | <SimonSapin> | nox: https://github.com/whatwg/dom/issues/185 |
| 21:50 | <nox> | Cool. |
| 21:56 | <aklein> | Domenic: a getter that deletes another propety |
| 21:56 | <aklein> | property |
| 21:57 | <aklein> | Domenic: see, e.g., https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/fast/dom/Window/script-tests/postmessage-clone.js&l=142 |
| 21:57 | <aklein> | er |
| 21:58 | <aklein> | in this case it'd be a getter that changes the enumerable-ness of another property |
| 21:58 | <aklein> | but you get the idea |
| 22:01 | <Domenic> | aklein: perfect, thanks |
| 22:03 | <aklein> | Domenic: existing implementations do seem to check for the existence of a property during the loop anyway, though it'd be awesome if we didn't have to do that |
| 22:03 | <Domenic> | aklein: oh i see, wow so many proxy traps being triggered |
| 22:04 | <aklein> | not really proxy related, just the existence of getters |
| 22:05 | <Domenic> | i guess i meant if we did allow proxies this isn't anywhere near how you would write the algorithm in order to minimize trap-triggering |
| 22:18 | <aklein> | Domenic: indeed :) |
| 23:24 | <nox> | Can anyone tell me if selectors4 still forbid nested :matches()? I remember it used to in the past but can't find it again in https://drafts.csswg.org/selectors/#matches. Did that change recently? |
| 23:25 | <nox> | TabAtkins: ^ |
| 23:30 | <TabAtkins> | nox: Doesn't look like the requirements there anymore, so consider it gone. |
| 23:30 | <TabAtkins> | Certainly isn't a *recent* change, tho. |
| 23:31 | <nox> | Ah. :( |
| 23:32 | <TabAtkins> | Why :( ? |
| 23:33 | <nox> | Because I'm trying to support :matches and :not in a way that lets me compute the specificity in a clever way and it made things more difficult. |
