| 06:34 | <annevk> | domfarolino: that's cool, enjoy whatever else meanwhile |
| 06:34 | <annevk> | TabAtkins: Unicode and fragments is a bit of a hassle still |
| 06:35 | <annevk> | TabAtkins: probably best avoided, though it'll probably work |
| 07:32 | <Domenic> | TabAtkins: so FYI Watti seems to have a global table of IDs that it uses for deduping; then it can just use numeric suffixes. That seems less error-prone than your strategy? |
| 07:32 | <Domenic> | wanderview: JakeA: it sounds like you did figure out the idea. Which is that byte streams allow more transferring optimizations. (Even with non-BYOB readers.) |
| 07:33 | <Domenic> | annevk: that guidance seems good, although an example (perhaps the RIC one genericized) would help drive it home. People do seem to really like stack inspection sometimes, instead of explicit parameter passing. |
| 07:34 | <JakeA> | Domenic: together we got there! |
| 07:35 | <Domenic> | I should spend more time on streams stuff..... |
| 13:26 | <wanderview> | Domenic: no, no... let us catch up first |
| 13:52 | <tobie> | What are examples of interfaces that declare a named property getter but not an indexed property getter? |
| 13:54 | <annevk> | tobie: Storage |
| 13:54 | <annevk> | tobie: DOMStringMap |
| 13:54 | <tobie> | annevk: ta |
| 14:29 | <JakeA> | wanderview: I wasn't aware Firefox had double keying |
| 14:29 | <JakeA> | Similar to the Safari thing? |
| 14:29 | <wanderview> | JakeA: its behind a pref and called something else I think... I believe we imported it from tor project |
| 14:29 | <JakeA> | exciting though! |
| 14:30 | <wanderview> | JakeA: but our containers work in a similar way... add some private data to the origin and its extra unique, etc |
| 14:31 | <wanderview> | JakeA: looks like privacy.firstparty.isolate |
| 14:32 | <wanderview> | JakeA: we may not have things like "visiting a site as first party exempts it from double-keying" like safari, though |
| 14:33 | <wanderview> | I haven't tried it |
| 14:37 | <Domenic> | We are looking into something similar to that ("origin attributes" is what it's called I believe) especially to underlie things like suborigins |
| 14:38 | <annevk> | Domenic: that's what Firefox has and some folks at Chrome want to copy |
| 14:38 | <wanderview> | Domenic: we also call it OriginAttributes :-) |
| 14:38 | <Domenic> | Yeah it's based on a paper some FF folks wrote I believe |
| 14:39 | <wanderview> | ah, cool |
| 14:39 | <wanderview> | is a "paper" like a blog? |
| 14:39 | <tobie> | annevk: in https://github.com/heycam/webidl/pull/402#discussion_r131709808 you mention enum order is defined by underlying infra list. Are all APIs with named props specified with an underlying infra list? |
| 14:40 | <annevk> | tobie: pretty sure that's a no |
| 14:41 | <annevk> | tobie: I do think order is defined though typically |
| 14:41 | <annevk> | tobie: and when it's not that's a bug |
| 14:41 | <annevk> | tobie: and not using Infra list a minor bug that'd be nice to fix |
| 14:42 | <tobie> | annevk: shouldn't WebIDL call that out somehow, though? Or maybe infra's for each should? |
| 14:43 | <annevk> | tobie: it's called out by requiring it to be a list, which are ordered by definition |
| 14:47 | <tobie> | annevk: Oh! It had somehow never really clicked that while "while" was defined in 3.3 Iteration "for each" was just a reference to list/for each. |
| 14:49 | <tobie> | annevk: I guess that makes sense and will even more obvious as infra becomes ubiquitous. |
| 14:54 | <Domenic> | Anyone else have opinions on https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Aug/0001.html ? |
| 17:15 | <TabAtkins> | @annevk What's troublesome about unicode in fragments? They seem to work just fine. (I had to implement my own fragment-escaper, as Python2's urllib escaper doesn't understand unicode, but I did so by consulting HTML, so it should be correct.) |
| 17:15 | <refack> | Hello all, has there been any work (or interest) in standardizing `'assert'`? It's been bugging me, and I see it is used in the platform tests |
| 17:16 | <TabAtkins> | @Domenic Yeah, I have the same, it isn't a matter of a *practical* trouble in deduping, just that it can make the refs a little ambiguous to read when you have terms with a numeric suffix. Purely aesthetic. |
| 17:21 | <annevk> | TabAtkins: URL parser may or may not escape it if you put it in raw |
| 17:21 | <annevk> | refack: in JavaScript you mean? |
| 17:21 | <TabAtkins> | I'm exactly following what HTML says is the valid charset for fragments, and %-escaping the rest. |
| 17:22 | <TabAtkins> | If URL and HTML differ, obviously one of them should be fixed. ^_^ |
| 17:22 | <annevk> | I've no idea what HTML says :-) |
| 17:22 | <refack> | annevk: yes, specifically node's (or CommonJS) |
| 17:22 | <tobie> | refack: I don't think that's the same assert. ;) |
| 17:23 | <TabAtkins> | annevk: Ah, I didn't even realize the HTML links sent me over to URL anyway ^_^ https://url.spec.whatwg.org/#url-fragment-string |
| 17:23 | <refack> | Not the "Assert" in the docs, the `require('assert') in the tests |
| 17:23 | <annevk> | refack: anyway, I know of no such efforts |
| 17:23 | <TabAtkins> | (I *was* wondering when HTML got syntax highlighting...) |
| 17:23 | <annevk> | heh |
| 17:24 | <tobie> | this throws in FF: (function() { "use strict"; document.createElement("div").attributes["3"] = 123 })(); |
| 17:24 | <annevk> | TabAtkins: anyway, if it works it's fine, since we can't break that, I just know there's a couple of minor issues and browser differences left, but they might not get exposed when simply navigating |
| 17:24 | <tobie> | But not this: document.createElement("div").attributes["3"] = 123; |
| 17:24 | <TabAtkins> | kk |
| 17:25 | <tobie> | Is this a known issue? |
| 17:26 | <annevk> | tobie: haven't seen that discussed before |
| 17:26 | <annevk> | tobie: typically IDL doesn't care about strict mode |
| 17:26 | <refack> | If I volunteer, is there interest? I know only `node` has an implementation, but it is used by the test e.g. https://github.com/whatwg/console/blob/master/test/tests/timing.js#L3 |
| 17:27 | <refack> | It is sort of arbitrary, and definatly not rigorous |
| 17:27 | <tobie> | annevk: what do you mean by "typically IDL doesn't care about strict mode" |
| 17:27 | <annevk> | tobie: no different code path gets taken |
| 17:28 | <annevk> | refack: since it's a JavaScript extension I suspect #tc39 or es-discuss is a better place to ask |
| 17:28 | <tobie> | annevk: right, so these two things code snippets should not behave differently. |
| 17:29 | <tobie> | s/things // |
| 17:29 | <annevk> | refack: if there's some interest and someone is willing to present your proposal to the committee thingie they got going on you can write a proposal along the lines of the others: https://github.com/tc39/proposals |
| 17:29 | <refack> | hmmm |
| 17:29 | <annevk> | tobie: yeah, but maybe this is a weird case where the two worlds intersect? bit out of my depth |
| 17:30 | <annevk> | tobie: hmm, there is some stuff that behaves differently based on strict mode: https://heycam.github.io/webidl/#LenientSetter |
| 17:30 | <annevk> | tobie: this might just be one of those |
| 17:30 | <refack> | thanks, my intuition was that WHATWG would be easier, but I get what you are saying |
| 17:31 | <annevk> | refack: if you want it as an extension of the Console API you could do it through WHATWG |
| 17:31 | <annevk> | refack: not really sure we have a home for a generic assert library |
| 17:32 | <annevk> | refack: (and I'm also not entirely sure we need one, but that's a different discussion) |
| 17:32 | <tobie> | annevk: right, it didn't seem like NamedNodeMap was one of those, though. |
| 17:32 | <refack> | That was my lead, but I see how tc39 should be my first attempt. I agree it not an eco-system interop issue (yet) |
| 17:35 | <annevk> | tobie: I suspect it is looking at the algorithms |
| 17:37 | <annevk> | tobie: if there's no setter for a property you end up throwing in strict mode |
| 17:38 | <annevk> | tobie: that's what I think is happening |
| 17:38 | <annevk> | tobie: and there's no setter since NamedNodeMap only defines a getter |
| 17:42 | <tobie> | annevk: where is that defined, though? I thought this was only for readonly attributes not all properties? |
| 17:46 | <annevk> | tobie: it's no different from a readonly attribute afaict |
| 17:46 | <annevk> | tobie: a readonly attribute is a property with a getter and an undefined setter |
| 17:46 | <annevk> | tobie: this is no different |
| 17:46 | <annevk> | tobie: back tomorrow |
| 17:46 | <tobie> | annevk: night |
| 18:09 | <tobie> | annevk: OK, I got it now. You're right. And this has been fixed in chrome canary too. |
| 18:49 | <Domenic> | tobie: annevk: in general returning "false "from various meta-object protocol operations will throw in strict and no-op in sloppy. So this is pretty widespread even if it's not obviously so. |
| 18:49 | <Domenic> | refack: those console tests are kind of old and maybe should be removed; the canonical ones are at https://github.com/w3c/web-platform-tests/tree/master/console |
| 18:50 | <Domenic> | Note how they are nicely written in .any.js format so you can run them easily in Node :) |
| 18:52 | <refack> | Domenic: where's the harness? I'd like to take inspiration from it. |
| 18:52 | <Domenic> | refack: well Node has an implementation at https://github.com/nodejs/node/blob/master/test/common/wpt.js |
| 18:54 | <refack> | boo 😜 that uses require('assert')... I want to make 'assert' better |
| 18:55 | <Domenic> | Oh well I kind of doubt Node will want to change its assert module much |
| 18:55 | <Domenic> | But there's https://github.com/w3c/web-platform-tests/blob/master/resources/testharness.js |
| 18:56 | <Domenic> | I'm not sure it's super-great code tbh |
| 18:56 | <tobie> | Domenic: right. |
| 18:56 | <tobie> | Domenic: looking at https://github.com/TimothyGu/webidl-keys-test/blob/master/test-named-node-map.js#L23 |
| 18:57 | <tobie> | Domenic: shouldn't that be a no-op by virtue of NamedNodeMap not having a named prop setter? |
| 18:58 | <Domenic> | tobie: doesn't it fall through to https://heycam.github.io/webidl/#legacy-platform-object-set step 3? |
| 18:59 | <Domenic> | then it goes to https://heycam.github.io/webidl/#legacy-platform-object-defineownproperty step 2... |
| 19:00 | <tobie> | It falls through to step 2, first |
| 19:00 | <tobie> | no> |
| 19:00 | <tobie> | no? |
| 19:00 | <Domenic> | step 2 is just LegacyPlatformObjectGetOwnProperty right? |
| 19:00 | <Domenic> | I think it is a no-op because we end up in https://heycam.github.io/webidl/#legacy-platform-object-defineownproperty step 2.2 |
| 19:01 | <Domenic> | wait no |
| 19:01 | <tobie> | Right, so it comes back with a desc object that has writable as false, no? |
| 19:01 | <Domenic> | it is not a no-op because we reach 2.2, but the condition is not met, so we go on to stop 3 + 4 |
| 19:02 | <Domenic> | correct, writable = false |
| 19:02 | <Domenic> | ok |
| 19:02 | <Domenic> | so it will *throw* |
| 19:02 | <tobie> | in strict |
| 19:02 | <Domenic> | yep |
| 19:02 | <tobie> | and no-op elsewhere |
| 19:02 | <Domenic> | which is what this test is |
| 19:02 | <Domenic> | yep |
| 19:02 | <tobie> | So going back to the test |
| 19:03 | <tobie> | ownProp should not show up in Reflect.ownKeys |
| 19:03 | <Domenic> | I agree |
| 19:03 | <Domenic> | Although the fact I stumbled through several different outcomes implies my judgment might be suspect |
| 19:04 | <tobie> | heh |
| 19:04 | <tobie> | well, fwiw, both FF and Chrome Canary throw in that case for indexed prop in strict mode. |
| 19:05 | <Domenic> | That's good at least :) |
| 19:05 | <tobie> | haven't tested beyond, yet. |
| 19:05 | <Domenic> | This is good stuff in general |
| 19:05 | <Domenic> | TimothyGu remains amazing |
| 19:05 | <Domenic> | And thanks for backing him up with more testing work |
| 19:05 | <Domenic> | slash fact-checking |
| 19:06 | <tobie> | yes, it's really great to see people coming in with super solid PRs like this. |
| 19:06 | <Domenic> | I think the Bikeshed conversion can take some credit |
| 19:07 | <refack> | Domenic: thanks |
| 19:07 | <tobie> | I was about to say so |
| 19:07 | <TabAtkins> | Yeah, the old webidl was *so damn hard* to edit. |
| 19:07 | <TabAtkins> | Moving to any modern processor would have improved that. |
| 19:39 | <tobie> | Domenic: so I think I made an error earlier |
| 19:39 | <tobie> | Domenic: in https://heycam.github.io/webidl/#legacy-platform-object-set |
| 19:40 | <tobie> | Step 2 has last argument of LegacyPlatformObjectGetOwnProperty see to true |
| 19:41 | <tobie> | Domenic: which means that we fall through to 3 in LegacyPlatformObjectGetOwnProperty |
| 19:41 | <tobie> | Domenic: (As ignoreNamedProps is true) |
| 19:43 | tobie | grumbles something about using ignoreNamedProps as a name for a boolean |
| 19:57 | <tobie> | Domenic: documented those here: https://github.com/w3c/web-platform-tests/commit/0d8209f |
| 20:02 | <tobie> | Domenic: and here: https://github.com/w3c/web-platform-tests/pull/6786 |
| 21:12 | <edsu> | hi all, i'd be curious about anyone's feedback on this proposal to allow rel=bookmark to be used with <link> https://github.com/whatwg/html/issues/2899 |
| 23:10 | <MikeSmith> | https://stackoverflow.com/questions/45578828/dataset-vs-setattribute-performance |