| 09:18 | <zcorpan> | can someone check http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4196 in Edge? |
| 09:21 | <annevk> | https://irccloud.mozilla.com/file/43yfepoT/edge13.png |
| 09:21 | <annevk> | zcorpan: ^^ |
| 09:21 | <zcorpan> | ty |
| 10:07 | <robertkowalski> | Domenic: i was three weeks on cuba, catching up this week |
| 11:42 | <zcorpan> | AAA ;_; |
| 11:43 | <zcorpan> | https://github.com/html5lib/html5lib-tests/issues/78 |
| 11:49 | <gsnedders> | I /think/ the test is right. FF nightlies agree with the test, at least. |
| 11:49 | <gsnedders> | I could of course be wrong. |
| 11:51 | <nox> | gsnedders: I may be dumb, |
| 11:51 | <nox> | gsnedders: I don't see anything that contradicts your comment https://github.com/html5lib/html5lib-tests/issues/78#issuecomment-219328831. |
| 11:51 | <nox> | gsnedders: Oh btw, my Safari gives <aside><em><b></b><em></aside> for the aside part, hah. |
| 12:06 | <gsnedders> | nox: I said the em gets removed from the list of active fomratting elements |
| 12:06 | <gsnedders> | nox: which means you don't end up with a em in the new aside |
| 12:06 | <nox> | gsnedders: Oooooh, right. |
| 12:07 | <nox> | gsnedders: But isn't iabudiab wrong about <em> not being removed as per the spec? |
| 12:07 | <gsnedders> | nox: I believe he is |
| 12:07 | <gsnedders> | wait |
| 12:07 | <gsnedders> | there's too many negatives there |
| 12:07 | <nox> | :D |
| 12:08 | <nox> | gsnedders: "So in this case the <em> wouldn't be removed via the following step If inner loop counter is greater than three and node is in the list of active formatting elements, then remove node from the list of active formatting elements" |
| 12:08 | <nox> | This sounds wrong to me. |
| 12:08 | <gsnedders> | That's what I think is wrong. |
| 12:08 | <gsnedders> | With his understanding. |
| 12:10 | <nox> | And as per the spec in step 13.6, <em> should be removed from the stack of open elements too. |
| 12:12 | <nox> | IMO WebKit/Chromium/IE11 don't follow the spec, and the test is consistent with the spec. |
| 12:12 | <nox> | But WebKit/Chromium/IE11 not following the spec means the spec needs to change, right? |
| 12:12 | <Ms2ger> | Usually |
| 12:13 | <nox> | Though <em><b> looks quite insane in that case. :/ |
| 12:14 | <gsnedders> | I /think/ they don't have the inner loop limit? |
| 12:15 | <gsnedders> | Which means you can still end up with O(n^2) behaviour, no? |
| 12:15 | <nox> | gsnedders: They being the three UAs I mentioned? |
| 12:15 | <nox> | OP seemed to imply that WebKit do limit the inner loop. |
| 12:16 | <nox> | Cf. code in https://github.com/html5lib/html5lib-tests/issues/78#issuecomment-219421046 |
| 12:30 | <gsnedders> | nox: right, I believe WebKit, Blink, and html5lib-python are all wrong here |
| 12:33 | <nox> | gsnedders: They should all follow what Servo does obviously!!1! |
| 12:34 | <gsnedders> | nox: and gecko |
| 12:40 | gsnedders | is trying to find where this changed |
| 12:40 | <gsnedders> | because the spec definitely used to agree with WebKit |
| 13:37 | <MikeSmith> | Domenic: about the MS notifications implementation, how can you tell it ' |
| 13:37 | <MikeSmith> | Domenic: about the MS notifications implementation, how can you tell it’s a different spec? Their blog post has no code |
| 13:38 | <MikeSmith> | I was surprised to see them announce they were adding any notifications support at all, so not surprised to find out that they didn’t implement it to spec |
| 13:43 | <MikeSmith> | hahah |
| 13:44 | <annevk> | MikeSmith: "Microsoft Edge also supports the event model as defined by the W3C spec, including all the show, click, close, and error events." |
| 13:45 | <annevk> | MikeSmith: though if they're also going to support them for service workers they'll have some rather inconsistent model |
| 13:46 | <MikeSmith> | annevk: yeah I realized that after I typed the above |
| 13:46 | <MikeSmith> | this is rich in irony |
| 13:47 | <MikeSmith> | for anybody who says what is important to them is interoperability |
| 13:48 | <MikeSmith> | and also for the fact that the whole reason we had to create a separate WG for Notifications is because one vendor forced us into it |
| 13:49 | <MikeSmith> | anyway, I guess if they don’t yet have service workers implemented then they can’t support the current spec |
| 13:50 | <annevk> | MikeSmith: also means a certain vendor never waived their patents |
| 13:51 | <MikeSmith> | yup |
| 13:51 | <MikeSmith> | free ride |
| 13:53 | <MikeSmith> | I wonder if they actually know that “The implementation in Microsoft Edge is based on the W3C Web Notifications specification, now supported broadly across modern desktop browsers.” is not true |
| 13:53 | <MikeSmith> | well I mean the part after the commaa |
| 13:53 | <MikeSmith> | ah, desktop |
| 13:54 | <annevk> | I wonder if Chrome and Firefox have actually unshipped those events |
| 13:54 | <MikeSmith> | I guess that’s why they qualified it with the word “desktop” |
| 13:54 | <annevk> | Perhaps they implemented those events because implementers never removed support for them |
| 13:54 | <MikeSmith> | I don’t know about the events, for the old API does not work on mobile |
| 13:55 | <MikeSmith> | yeah maybe so |
| 13:55 | <annevk> | It's kind of a shame they have the feeling they can't even say those kind of things in public |
| 13:56 | <annevk> | It's not like these blog posts are helping convergence |
| 13:56 | <MikeSmith> | yeah |
| 14:16 | <annevk> | I think zcorpan might have missed that https://github.com/whatwg/html/pull/1267 is a pull request? |
| 14:27 | <Domenic> | The fetch issue on header lowercasing is pretty cool. Good compromise and people working together for a solution that seems to get better each time someone revises it. WHATWG in action. |
| 14:34 | <daleharvey> | So got a fun problem with anyone familiar with indexeddb (also know anywhere better to ask about this?) |
| 14:35 | <daleharvey> | I have a library (pouchdb), I want to expose the ability for users to define their own indexes at runtime (ie after schema creation) |
| 14:39 | <daleharvey> | even without them being defined at runtime and being done at schema creation it is still fairly complex, the user will certainly require the ability to change indexes outwith the versioning of the schema, and pouchdb will still need to track the schema version number for actual data migrations |
| 14:39 | <annevk> | daleharvey: when jsbell is around it'd be a good time to ask |
| 14:40 | <daleharvey> | ah cool, yeh I have been in touch with him before about chrome idb bugs, will look out for, cheers |
| 14:44 | <annevk> | daleharvey: have you looked at persistent storage btw? https://storage.spec.whatwg.org/ |
| 14:45 | <annevk> | daleharvey: would appreciate feedback in the GitHub repo if you have any, no implementations yet though, still being worked on |
| 14:45 | <daleharvey> | oh I havent yet, will definitely take a look, thanks |
| 14:47 | <daleharvey> | still reading, but did you manage to get in implicit persistence? ie if a PWA is saved / installed then storage is persistent by default? |
| 14:49 | <annevk> | daleharvey: needs some rewording here and there, but the idea is that the permission can be granted in such a way, yes |
| 14:50 | <annevk> | daleharvey: probably still best if the developer invokes the method at that point to persist, in case they have a different storage strategy in mind |
| 15:07 | <annevk> | Domenic: for browser testing, get Google to buy you a BrowserStack account |
| 15:07 | <Domenic> | that's probably a good idea. |
| 15:08 | <annevk> | Domenic: it's quite nice, I use that now for Edge since I got tired of running a VM |
| 16:55 | <wanderview> | Domenic: do you know the answer to this streams spec notation question? https://bugzilla.mozilla.org/show_bug.cgi?id=1272697#c4 |
| 16:57 | <Domenic> | wanderview: answered |
| 16:57 | <wanderview> | thanks! |
| 16:57 | <annevk> | Domenic: why can't we use "." for both? |
| 16:58 | <Domenic> | annevk: not really sure... |
| 16:58 | <Domenic> | Maybe another ECMA262 issue... |
| 16:58 | <annevk> | Domenic: sure |
| 17:02 | <annevk> | https://github.com/tc39/ecma262/issues/574 |
| 17:54 | <Domenic> | TabAtkins: can I have Bikeshed specify a default for when I don't use for=""? |
| 17:55 | <TabAtkins> | Domenic: Yeah, link-defaults |
| 17:55 | <TabAtkins> | (And remember, if you ever need to *explicitly* refer to a dfn *without* a for='', use for="/".) |
| 17:55 | <jyasskin> | TabAtkins: It'd be really nice for terms with both a <dfn>term</dfn> and a <dfn for="parent">term</dfn>, if <a>term</a> would automatically assume for="". |
| 17:56 | <TabAtkins> | jyasskin: That's precisely the sort of thing that is *very* commonly an error and I *can't* assume, unfortunately. |
| 17:56 | <jyasskin> | :( |
| 17:57 | <Domenic> | TabAtkins: oh, the thing jyasskin is asking for is what I was asking for :( |
| 17:58 | <TabAtkins> | I was just having this discussion with fantasai - there's a border area where the likelihood of magic hiding errors outweighs the annoyance of having to manually specify things. |
| 17:58 | <TabAtkins> | Domenic: Yeah, you can *force* Bikeshed to assume that. I just can't do it automatically. |
| 17:58 | <TabAtkins> | Like I said, do a link-defaults line for it. |
| 17:58 | <Domenic> | Oh hmm |
| 17:58 | <TabAtkins> | with "for: /;" in it |
| 17:58 | <jyasskin> | Does a link-defaults of just "for: /; term: the term" do this, or do we also have to say the spec? |
| 17:58 | <Domenic> | doesn't seem to be working... spec: FETCH; type: dfn; text: referrer policy; for: /; |
| 17:59 | <Domenic> | [1;33mLINK ERROR:[0m Multiple possible 'dfn' local refs for 'referrer policy'. |
| 17:59 | <Domenic> | Arbitrarily chose the one with type 'dfn' and for ''. |
| 17:59 | <TabAtkins> | Hmmmm, that should work. I'll debug and fix today. |
| 18:01 | <TabAtkins> | jyasskin: I think you need the spec. |
| 18:11 | <Domenic> | Hmm [WHATWG-DOM] again... |
| 18:28 | <jgraham> | zcorpan: Is window.resizeTo expected to be sync? |
| 18:33 | <TabAtkins> | Domenic: If you ever refer to [DOM] in the spec, it'll use that in the biblio. It's just [WHATWG-DOM] in the db, so it'll use that if there's nothing else telling it which tag to use (such as if you only picked up that biblio entry indirectly, from an autolink pointing to a term in that spec) |
| 18:33 | <Domenic> | TabAtkins: I see. Yeah, all I did was add <a>node document</a>; it doesn't really make sense to put [DOM] there |
| 18:34 | <TabAtkins> | K. Fixing that more thoroughly is more effort than I'm willing to put in for something that's still *supposed* to be temporary. ^_^ |
| 18:34 | <Domenic> | ya tobie, that's supposed to be temporary ;) |
| 18:35 | <jgraham> | zcorpan: BTW Iam very much hoping the anser is "no" |
| 18:35 | <jgraham> | Because I don't think that's possible to implement in many WMs (and I doubt browsers do it) |
| 18:37 | jgraham | guesses that zcorpan is not really around |
| 18:40 | <tobie> | Domenic: heh |
| 18:46 | <TabAtkins> | Domenic: "referrer policy" is in HTML. Is that the definition you want to refer to? |
| 18:46 | <Domenic> | TabAtkins: nope, I want to refer to the one in Fetch |
| 18:47 | <Domenic> | TabAtkins: except for when I do for="Document" |
| 18:47 | <TabAtkins> | Oh, that's not in Shepherd. |
| 18:47 | <Domenic> | https://github.com/w3c/webappsec-referrer-policy/pull/49 has the problematic code |
| 18:47 | <Domenic> | Sure but I put it in the links section |
| 18:48 | <TabAtkins> | Domenic: It looks like you just added a link-defaults for it. Did you add it somewhere else that I'm not seeing? |
| 18:49 | <TabAtkins> | Because link defaults just sets up the defaults for links. If the spec in question isn't in the db, it doesn't matter *what* the links specify, obviously. ^_^ |
| 18:49 | <Domenic> | TabAtkins: line 24 |
| 18:49 | <TabAtkins> | Ah, kk. (That wasn't changed in the commit, so I didn't see it.) |
| 18:51 | <Domenic> | ah right |
| 18:57 | <TabAtkins> | Okay, I've reproduced the issue. It's because <pre class=anchors> things are treated as local (so they'll get picked over other collisions, since you presumably *meant* to use them), and locals don't look at as many of the defaulting things. I'll see what I can do to fix this. |
| 18:59 | <TabAtkins> | Funky collision of heuristics here, ugh. |
| 19:14 | <Domenic> | \o/ |
| 19:15 | <annevk> | Domenic: https://twitter.com/mpotra/status/732628389065035776 |
| 19:17 | <gsnedders> | Someone mentioned that the TAG had concluded everyone should just use URL. Any citation? |
| 19:32 | <TabAtkins> | plinss mentioned that |
| 19:39 | <gsnedders> | TabAtkins: that's not a citation :P |
| 19:39 | <TabAtkins> | I know, I was just filling in the hole in your statement. |
| 19:41 | <TabAtkins> | Domenic: Your issue will require more work than I can do right now (I'm trying to get Echidna publishing working), so I've filed it as https://github.com/tabatkins/bikeshed/issues/710 |
| 19:41 | <Domenic> | TabAtkins: OK cool, thanks |
| 19:41 | <Domenic> | at least it's "arbitrarily" picking the right version for now |
| 19:43 | <TabAtkins> | It really is arbitrary, since it depends on the ordering of Python dicts. |
| 21:00 | <jyasskin> | Domenic: Dumb question: why do you need to distinguish internal slots from record fields named like [[something]]? |
| 21:01 | <Domenic> | jyasskin: yeah, we're not really clear, upon reflection. I guess it'd be similar to keeping -> and . as separate in C++, even if pointers could never have normal properties; they have different semantics, sure, but maybe we should just consolidate (like, say, C# does, despite having both value and reference objets). |
| 21:02 | <Domenic> | jyasskin: annevk opened https://github.com/tc39/ecma262/issues/574 to discuss further |
| 21:02 | jyasskin | subscribes. |
| 21:05 | <jyasskin> | IIUC, the difference between an attribute on an interface vs a field on a record is that the attribute is a getter/setter on the prototype of the JS object, but a field is just a field directly on the JS object. But an internal slot acts like a field on the object, so it actually should be accessed like a record field. |
| 21:05 | <jyasskin> | s/record/dictionary |
| 21:06 | <Domenic> | agreed. The [[s are enough to make it clear it's internal, now that I think about it |
| 21:06 | <jyasskin> | \o/ |
| 22:09 | <wanderview> | Domenic: how significant is it that the streams spec defines IsReadableStream() as an internal slot check vs essentially an instanceof ReadableStream check? |
| 22:09 | <Domenic> | wanderview: pretty significant. Otherwise you could fool it by doing `var o = {}; o.__proto__ = ReadableStream.prototype` |
| 22:09 | <Domenic> | Then you'd start asking `o` for a bunch of interesting internal state, and bad things would happen |
| 22:09 | <wanderview> | Domenic: so its intended to be more strict, then... |
| 22:10 | <Domenic> | yes indeed |
| 22:10 | <Domenic> | it's a brand check |
| 22:10 | <wanderview> | Domenic: ok, so if we have a way of doing the brand check via an intrinsic, that should be fine to use vs the spec version |
| 22:10 | <Domenic> | wanderview: yeah as long as it can't be fooled, it should be fine |
| 22:13 | <wanderview> | Domenic: hmm, I guess our intrinsic could be fooled by Reflect.setPrototypeOf() |
| 22:14 | <Domenic> | wanderview: right, that was my __proto__ example... seems bad? |
| 22:14 | <wanderview> | Domenic: the problem with the slot check for me is that we don't have names for slots... really just indexes that a constant maps to |
| 22:16 | <Domenic> | wanderview: I see. I guess you probably need to reserve the 0th-index slot to have a guid or something you can check... I wonder if that's how SpiderMonkey does it for Promise and Map and friends? |
| 22:16 | <wanderview> | Domenic: I'll look and see what they do... thanks |
