| 00:51 | <TabAtkins> | tobie: No way to ignore vars at the algo level right now. I can definitely add it, but most of the time a big "stop freaking out about this" switch is all that's needed. |
| 00:51 | <TabAtkins> | Gimme an issue if you want something for it. |
| 01:15 | <Domenic> | It seems like most of the problems I see with ignored vars are if they appear once in the algorithm and once in the heading |
| 01:15 | <Domenic> | I guess maybe you are supposed to wrap the algorithm div around both the heading and the ol. Not sure how that ends up looking after CSS happens. |
| 04:25 | <Netmo> | morning folks. quick question: the HTMLDocument interface is gone, right? there is only the partial interface Document specified in the html spec |
| 04:48 | <MikeSmith> | Netmo: yeah |
| 04:48 | <MikeSmith> | but the spec still defines HTMLDocument somewhere right? |
| 04:48 | MikeSmith | looks |
| 04:50 | <MikeSmith> | https://html.spec.whatwg.org/multipage/browsers.html#htmldocument |
| 04:50 | <MikeSmith> | > For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object. |
| 05:01 | <Netmo> | thank you! i suppose that's to avoid HTMLDocument extending from both Document (if text/html) and XMLDocument (if served as xml) |
| 05:03 | <Netmo> | which is actually a rather strange thing if it's that the actual reason now that i think of it. wouldn't it make more sense to get rid of xmldocument instead? |
| 05:03 | <Netmo> | *XMLDocument interface |
| 05:05 | <Netmo> | (sorry for the broken english - not my primary language) |
| 06:04 | <MikeSmith> | Netmo: I don’t really know the history |
| 06:05 | <MikeSmith> | I think it was originally defined as inheriting from Document |
| 06:06 | <MikeSmith> | but then the spec changed at some point to saying that it didn’t inherit from anything |
| 06:06 | <MikeSmith> | and the members moved to Document anway |
| 06:06 | <MikeSmith> | *anyway |
| 06:07 | <MikeSmith> | so it became pointless except for backward compatibility |
| 06:07 | <MikeSmith> | something like that |
| 06:25 | <annevk> | jyasskin: congrats, enjoy! |
| 08:28 | <Netmo> | MikeSmith: would be useful to have a log of all the decision taken and their reason :P thanks, though! |
| 08:29 | <MikeSmith> | Netmo: yeah that would be useful but we don’t have a good record for the reason in a lot of cases |
| 08:29 | <MikeSmith> | and in some of those cases people actually can no longer remember the reason |
| 08:30 | <MikeSmith> | dunno about this specific case though |
| 08:36 | <Netmo> | MikeSmith: i know right. even people actually taking the decision could forget about it. it happens to me for way simpler things. i often had to completely re-work out things i did in the past because i didn't write down what led me there. it's really bad :P |
| 08:40 | <MikeSmith> | Netmo: yup :) |
| 08:40 | <MikeSmith> | anyway as far as spec decisions (for DOM, HTML, etc.) getting made these days, GitHub has helped with that |
| 08:41 | <MikeSmith> | I mean as far as helping to have a record for the discussion and reasoning behind the spec changes that get made |
| 08:42 | <MikeSmith> | and for having the record in one place at GitHub rather than spread out across mailing lists and bugzilla |
| 08:44 | <Netmo> | indeed that's something. in fact i'm going through commits history and closed issues hoping to find something in regard. search didn't help, though |
| 08:46 | <Netmo> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=22960 and linked pages |
| 08:47 | MikeSmith | looks at https://www.w3.org/Bugs/Public/show_bug.cgi?id=22960 |
| 08:51 | <MikeSmith> | so yeah https://github.com/whatwg/dom/issues/221 seems to maybe be what you were originally looking for |
| 08:51 | <MikeSmith> | as far as your question “the HTMLDocument interface is gone” |
| 08:52 | <Netmo> | i don't even know anymore what the question was :P |
| 08:53 | <MikeSmith> | heh |
| 09:03 | <tobie> | jyasskin: congrats!! |
| 09:04 | <Ms2ger> | What he said |
| 09:06 | <tobie> | TabAtkins: yeah--I guess I have weird requirements because I'm working on a very large spec *and* it was converted from something else. Seems like an edge use case. |
| 09:07 | <tobie> | TabAtkins: also seems like whatever you're cooking for input/outputs will be much more useful. |
| 09:08 | <tobie> | TabAtkins: (i.e. in my cases it feels like these vars are hidden inputs) |
| 09:46 | <tobie> | annevk: what do you mean by: https://github.com/heycam/webidl/issues/202#issuecomment-255937886 |
| 09:47 | <annevk> | tobie: whenever you modify internal methods, you're requiring a JavaScript proxy to implement them in JavaScript |
| 09:48 | <annevk> | tobie: e.g., WindowProxy / Location require a proxy |
| 09:49 | <tobie> | annevk: how were these implemented before proxies? Only in C++, not in JS? |
| 09:51 | <annevk> | tobie: they're not implemented through proxies today I think |
| 09:51 | <tobie> | annevk: ok |
| 09:52 | <annevk> | tobie: sorry, it's a bit convoluted, I'll try to figure out how to explain it |
| 09:52 | <annevk> | tobie: browsers-implemented "platform objects" did various things you could not emulate in JavaScript |
| 09:52 | <tobie> | annevk: I think I'm getting used to convoluted explanations now that I've started digging into WebIDL. :) |
| 09:53 | <annevk> | tobie: such as indexed getters, named getters, etc. |
| 09:53 | <tobie> | annevk: yes |
| 09:53 | <annevk> | tobie: TC39 did not like that so they added proxies as a way of explaining those objects (and various more esoteric use cases; membranes) |
| 09:54 | <tobie> | annevk: yes, membranes, I remember those from the Caja days |
| 09:54 | <annevk> | tobie: however, proxies are not great and what browsers did with indexed getters and named getters and so on is still not seen as good practice |
| 09:54 | <Ms2ger> | Gecko uses C++-implemented proxies for all that |
| 09:55 | <annevk> | tobie: therefore, ideally any new platform objects we define through IDL do not result in something that ends up requiring a proxy (be it in JavaScript or some C++ thingie) |
| 09:55 | <tobie> | annevk: ok |
| 09:55 | <tobie> | annevk: that makes sense |
| 10:41 | <zcorpan> | annevk: do you have browser bugs filed for /dom/events/Event-dispatch-click.html ? wondering if i should file new bugs for "disconnected form should not submit" |
| 10:42 | <annevk> | zcorpan: no bugs |
| 10:42 | <annevk> | zcorpan: hoping foolip will automate that |
| 11:41 | <foolip> | annevk, zcorpan, yeah, without some tooling I think requiring bugs is excessive |
| 11:43 | <annevk> | foolip: still wonder if it might be more beneficial than tests in certain cases |
| 12:39 | <zcorpan> | MikeSmith: it appears <dl><script></script></dl> fails validation currently |
| 13:12 | <foolip> | annevk: In cases where getting a single vendor to change is the whole point, I believe so, yes. |
| 13:23 | <zcorpan> | MikeSmith: https://github.com/validator/validator/pull/390 |
| 14:06 | <MikeSmith> | zcorpan: I’m confused… https://github.com/validator/validator/pull/390 says “Note that <dl><script></script></dl> previously resulted in anerror; now has no errors.” on IRC earlier you said “it appears <dl><script></script></dl> fails validation currently” |
| 14:07 | <zcorpan> | MikeSmith: yes, i think those statements are saying the same thing. read again? |
| 14:08 | <zcorpan> | "now" is with the patch applied |
| 14:08 | <MikeSmith> | ah |
| 14:09 | <MikeSmith> | yeah I see |
| 14:09 | <MikeSmith> | OK |
| 14:36 | <rodneyre_> | https://github.com/medialize/ally.js/blob/docs/mutate-active-element/docs/tutorials/mutating-active-element.md#specifications <- is that simplification correct, or am I off by one or two universes? |
| 14:39 | <zcorpan> | rodneyre_: not sure but my knee-jerk reaction is s/HTML5/HTML/ ;-) |
| 14:39 | <rodneyre_> | hehe, fair point - no idea why I still add that 5… |
| 14:54 | <zcorpan> | rodneyre_: i think the simplification is correct if you don't have <dialog>s or inert focusable areas. based on your test results, maybe the spec should change when the control group is not a <dialog>? |
| 14:55 | <zcorpan> | rodneyre_: (i didn't follow how to run the test or where the test is) |
| 14:55 | <rodneyre_> | yeah, in this case I'm ignoring dialogs (which are covered by rules 2 and 3, no?) |
| 14:56 | <rodneyre_> | you're looking at the raw markdown, the HTML generated from that will have https://jsbin.com/fesexin/ embedded |
| 14:57 | <rodneyre_> | (not exactly made for testharness or something like that, sorry) |
| 14:57 | <zcorpan> | rodneyre_: https://html.spec.whatwg.org/multipage/interaction.html#focus-processing-model:focus-fixup-rule-one "...or when it was a dialog in a dialog group and stops being part of that dialog group, or when it starts being inert, ..."; step 3 invokes focus fixup rule one |
| 14:57 | <zcorpan> | thx |
| 15:01 | <zcorpan> | as an end user, i'd be pretty annoyed if focus was moved to the first focus area in the document |
| 15:01 | <rodneyre_> | zcorpan: should I open an issue for this? |
| 15:01 | <zcorpan> | rodneyre_: yes please |
| 15:02 | <rodneyre_> | if you're a keyboard dependent end user, you gave up being annoyed by shitty web apps a loooooooooong time ago |
| 15:02 | <rodneyre_> | we really suck at this… |
| 15:04 | <zcorpan> | yeah :-| |
| 15:04 | <zcorpan> | gotta go |
| 15:21 | <annevk> | :matches and :has are still not implemented? |
| 15:32 | <annevk> | Ms2ger: seems you were right all along (re TC39) |
| 15:32 | Ms2ger | whistles |
| 15:33 | <annevk> | Ms2ger: guess I should not have confused your issue by suggesting that IDL's upcoming ES6 rewrite might resolve it |
| 15:35 | <Ms2ger> | \o/ https://bugzilla.mozilla.org/show_bug.cgi?id=909656 |
| 15:37 | <annevk> | That is exciting |
| 16:41 | <nox> | annevk: I keep procrastinating the implementation of :matches in Servo hah. |
| 16:47 | <tobie> | Would really appreciate if someone (heycam|away, annevk, bz, Domenic) could have a look at: https://github.com/heycam/webidl/pull/198#issuecomment-256089978 and vet those 4 commits. |
| 16:52 | <annevk> | tobie: look fine modulo verbose List-allocation |
| 16:54 | <tobie> | annevk: ta. fixing the list stuff. I didn't know that <<args>> construct existed. |
| 16:54 | <annevk> | tobie: note that it's not << but rather some Unicode thingie (in case you didn't notice) |
| 16:54 | <tobie> | annevk: I've notice, haven't figured out the key strokes yet |
| 16:55 | <tobie> | *noticed |
| 16:55 | <annevk> | tobie: cmd+c, cmd+v |
| 16:55 | <tobie> | annevk: heh |
| 16:57 | <rodneyre_> | « is option+q, » is option+shift+q on a german mac keyboard (which won't help you at all, but … ;) |
| 16:58 | <Ms2ger> | I'll try to have a look after my meeting |
| 17:15 | <annevk> | tobie: I think the other change that might be needed is that Call needs to be preceded by ? when not preceded by ! |
| 17:15 | <tobie> | annevk: oh. |
| 17:16 | <tobie> | annevk: fwiw, we don't do that in the spec as of now |
| 17:16 | <annevk> | tobie: follow-up issue maybe? |
| 17:16 | tobie | cries |
| 17:16 | <annevk> | tobie: ECMAScript has that all over |
| 17:17 | <annevk> | tobie: and unless we use ReturnIfAbrubt we'll need something like that |
| 17:17 | <annevk> | tobie: this is all part of the ES6-ification of IDL |
| 17:17 | <annevk> | Or ES2016 or whatever |
| 17:17 | <tobie> | annevk: was using Call() part of the ES5-ification? |
| 17:18 | <annevk> | tobie: not sure when ECMAScript got Call() |
| 17:18 | <annevk> | tobie: but ? was ES6 |
| 17:18 | <tobie> | ok |
| 17:18 | <annevk> | tobie: or even post-ES6 |
| 17:18 | <annevk> | tobie: before that it was all ReturnIfAbrubt making algorithms twice as long |
| 17:21 | <annevk> | tobie: anyway, does seem like a follow-up issue since the current prose doesn't deal with it either |
| 17:21 | <tobie> | So I added ! instead of "Assert: |result| is not an abrupt completion." is that correct? |
| 17:21 | <annevk> | tobie: yes |
| 17:22 | <tobie> | annevk: I'm cargo-culting this right now, which I absolutely hate doing. |
| 17:24 | <tobie> | annevk: what it describes doesn't seem _that_ complicated, but the description itself is hard to grasp. |
| 17:25 | <tobie> | annevk: so your advice is to leave as is for now and file an issue to do error handling for all Call() calls? |
| 17:25 | <tobie> | annevk: or would you prefer I handle those fist? |
| 17:26 | <tobie> | *first (i.e. as part of this PR) |
| 17:26 | <annevk> | tobie: leave as-is, file an issue to figure out which invocations need to be preceded by ? (can throw) and which by ! (can never throw) |
| 17:26 | <annevk> | tobie: the ! you added instead of the assert can stay of course |
| 17:27 | <tobie> | annevk: of course re the existing ! |
| 17:27 | <tobie> | annevk: thanks again |
| 17:27 | <annevk> | no worries, this is all super exciting refactoring |
| 17:27 | <annevk> | even if cargo culted |
| 17:28 | <Domenic> | annevk: is https://github.com/whatwg/html/pull/1935 ready to go in your opinion? leaving aside reset for #1912 |
| 17:29 | <annevk> | Domenic: I'd kinda prefer it if you don't touch the reset() thing at all, but yeah |
| 17:29 | <Domenic> | annevk: sure can do |
| 17:29 | <annevk> | Domenic: (note that I already tested reset() and it does indeed fire an isTrusted=true event) |
| 17:29 | <Domenic> | Ah excellent |
| 17:30 | <Domenic> | Sigh I found another one |
| 17:30 | <Domenic> | BeforeUnloadEvent |
| 17:30 | <annevk> | Domenic: I suspect everywhere where we have it set to false it's basically wrong |
| 17:30 | <annevk> | Domenic: minus click() |
| 17:31 | <Domenic> | seems likely |
| 17:31 | <annevk> | Domenic: for creating an event? I was thinking of going through the concept-event-dispatch results and seeing which don't use that yet |
| 17:31 | <Domenic> | yeah probably wise |
| 17:31 | <Domenic> | BeforeUnloadEvent should just be fired |
| 17:32 | <annevk> | Domenic: is that not the one that later on checks for any event listeners being triggered? |
| 17:32 | <Domenic> | Oh, yep, lol |
| 17:46 | <Ms2ger> | Domenic, since you're my go-to EcmaScript guy... The [[x]] notation for record fields is explained really late and is pretty damn hard to find |
| 17:47 | <Ms2ger> | Domenic, I think half of my team members who looked at prose using that convention got utterly lost :) |
| 17:48 | <Domenic> | Ms2ger: hmm not really sure what to say. Any concrete improvement suggestions I'm sure would be appreciated, but to me it's just a matter of knowing the conventions of specs you're reading... "readonly attribute" meaning getter got me totally lost for a long time and is explained pretty far down in Web IDL. |
| 17:49 | <Ms2ger> | Yeah, I'm not really sure |
| 17:50 | <Ms2ger> | Somewhat relatedly, I think it's weird that "notational conventions" starts out with a long-winded discussion of syntax ebnf stuff |
| 17:51 | <Ms2ger> | I would have expected it to cover the [[]] syntax, at least before using it in the definition of the `!` operator |
| 17:51 | <Domenic> | That's fair; maybe notational conventions needs some reorg to be readable top to bottom |
| 17:52 | <Ms2ger> | If I had a clear solution in mind, I'd already have filed it :) |
| 17:52 | <Ms2ger> | But it feels like there should be some opportunities to make it clearer for first-time readers here |
| 17:53 | <Ms2ger> | Anyway |
| 17:53 | Ms2ger | poofs |
| 18:30 | <annevk> | Domenic: you should prolly write a post on pollyfills |
| 18:31 | <Domenic> | Yeah :-S |
| 18:31 | <annevk> | Domenic: I suspect many do not realize badness |
| 18:45 | <younder> | are not polfyills described in 'the art of SVG' book? |
| 18:59 | <IZh> | Hi! There are number of non-existing anchors in the spec referenced by links: #refsSECURE-CONTEXTS, #dom-domstringmap-namedItem, #dom-domstringmap-namedItem, #dom-domstringmap-namedItem, #relevant-everything, #entry-everything. Shouldn't internal validator check for these? |
| 19:07 | <IZh> | The other question is can lists be nested in this way? <ol> <li>foo</li> <ol> <li>bar</li> </ol> </ol> |
| 19:08 | <IZh> | Shouldn't the second <ol> be moved inside first <li>? |
| 19:11 | <IZh> | This pattern is used in the spec few lines higher than "the new resource is to be handled by displaying some sort of inline content" on the 12 step of the algoruthm description. |
| 19:11 | <IZh> | Hixie: ^ |
| 19:49 | <jsbell> | Chrome is reporting a cert issue with https://dom.spec.whatwg.org - other specs seem fine. Just me? |
| 19:51 | <jsbell> | NET::ERR_CERT_AUTHORITY_INVALID specifically, |
| 19:51 | <IZh> | jsbell: Old version of the browser? |
| 19:52 | <IZh> | MITM? :-) |
| 19:52 | <IZh> | But it seems that there is certificate name mismatch. |
| 19:55 | <IZh> | https://www.ssllabs.com/ssltest/analyze.html?d=dom.spec.whatwg.org |
| 20:03 | <rbyers> | Yeah it looks like the certificate is wrong for me - sni.dreamhost.com ? |
| 20:04 | <IZh> | rbyers: Probably because of lot of virtual hosts on the same IP? |
| 20:04 | <rbyers> | Dunno. Firefox is also failing. |
| 20:13 | <SimonSapin> | Is the data of https://html.spec.whatwg.org/multipage/indices.html available in a more easily machine-parsable form? |
| 20:13 | <SimonSapin> | specifically the names of elements and attributes |
| 20:20 | <Domenic> | SimonSapin: no; people have asked for that several times but so far nobody has yet worked on a tool to generate or extract it |
| 20:22 | <KiChjang> | would a web scraper do for now? |
| 20:24 | <Domenic> | https://www.ssllabs.com/ssltest/analyze.html?d=dom.spec.whatwg.org says A+ for me |
| 20:24 | <Domenic> | Hixie says it works for him |
| 20:24 | <Domenic> | But it doesn't work for me |
| 20:26 | <IZh> | Domenic: nslookup? |
| 20:26 | <IZh> | dom.spec.whatwg.org (173.236.182.141) |
| 20:27 | <Domenic> | Same here |
| 20:27 | <Domenic> | The current hypothesis is that LetsEncrypt is taking a while to propagate? |
| 20:27 | <IZh> | Hmm... Says T for me. |
| 20:27 | <IZh> | "If trust issues are ignored: A" |
| 20:28 | <IZh> | CDN in the middle? |
| 20:28 | <Domenic> | I don't know how this could be possible that some people see one cert and others see the right one |
| 20:29 | <IZh> | Domenic: More interesting thing is why we see different test results? :-) |
| 20:29 | <IZh> | It should be the same. |
| 20:29 | <Domenic> | Yeah also bizarre |
| 20:29 | <Domenic> | reload? |
| 20:29 | <IZh> | Asked the site to retest. |
| 20:30 | <Domenic> | Yeah I did that too, still got A+ |
| 20:31 | <IZh> | Domenic: https://s9.postimg.org/4c5a21w8t/whatwg_cert.png |
| 20:33 | <Domenic> | And for me an A+... https://usercontent.irccloud-cdn.com/file/c8Gtnekq/whatwg_cert.png |
| 20:33 | <IZh> | Domenic: Note different IP ;-) |
| 20:33 | <IZh> | CDN? |
| 20:34 | <Domenic> | I don't understand what a CDN would have to do with things |
| 20:34 | <IZh> | Domenic: They should fix some configuration. :-) |
| 20:34 | <Domenic> | What CDN though |
| 20:34 | <IZh> | Domenic: Dreamhost? |
| 20:35 | <Domenic> | IZh: that's just a hosting provider, not a CDN |
| 20:36 | <IZh> | Then why 2 IPs? :-) |
| 20:37 | <Domenic> | Well we did move hosts recently |
| 20:37 | <IZh> | Domenic: Some old cached record in DNS? |
| 20:39 | <IZh> | Anyway, I can't resolve hostname to old IP -- it's always resolved to new. |
| 20:39 | <Domenic> | Yep. Fixed by flushing my local computer's DNS resolver cache |
| 20:39 | <Domenic> | ipconfig /flushdns on windows, from an admin command prompt |
| 20:40 | <IZh> | Domenic: After another restest, SSL Labs displays correct IP. |
| 20:40 | <IZh> | retest |
| 20:41 | <IZh> | Now A+. |
| 20:41 | <SimonSapin> | Looks like https://api.csswg.org/shepherd/ serves data scrapped from many specs, including "anchors", some of which have "type": "element" |
