| 09:58 | <zcorpan> | hmm the only way i can think of for testing coords parsing is to .focus() the area and use reftests |
| 10:00 | <zcorpan> | or actually, maybe elementFromPoint |
| 10:02 | <zcorpan> | elementFromPoint always returns the <img> in gecko, known bug iirc |
| 10:05 | <gsnedders> | wait what |
| 10:05 | <gsnedders> | kinda odd bug |
| 10:49 | <zcorpan> | i wonder how Edge copes with the web with this bug https://github.com/Microsoft/ChakraCore/issues/20 |
| 10:53 | <gsnedders> | could be handling it in the HTML parser or something weird |
| 11:00 | <annevk> | zcorpan: I guess it would be good to get feedback from some browsers on the new coords algorithm |
| 11:00 | <annevk> | zcorpan: i.e., whether that's something they're willing to align on |
| 11:01 | <annevk> | zcorpan: if we have two browsers, that'd be good enough |
| 11:01 | <zcorpan> | annevk: yep, i can ping some |
| 11:07 | <annevk> | https://plus.google.com/+JirkaKosek/posts/4nh8VGRfrz1 hahaha |
| 11:08 | <annevk> | Oh my, Hixie commented too |
| 11:17 | <ondras> | heh, Jirka Kosek |
| 11:25 | <Ms2ger> | Yeah, that seems likely to be handled at a higher level |
| 11:43 | <zcorpan> | anyone know weinig⊙ac's github handle? |
| 11:55 | <annevk> | hober might know ^^ |
| 12:45 | <yoav_> | Anyone knows where window.top (DOMWindow) in general is specced? |
| 12:48 | <Ms2ger> | HTML |
| 12:48 | <Ms2ger> | Do you need a more specific link? |
| 13:04 | <yoav> | Ms2ger: Got it, thanks! :) |
| 13:04 | <Ms2ger> | Np |
| 14:38 | <annevk> | Domenic: who wrote the latest JavaScript URL parser again? Might want to look at https://github.com/whatwg/url/issues/77 |
| 14:51 | <frewsxcv> | what is the expected output of this? https://gist.github.com/frewsxcv/8f440c078b5912d8ae21 |
| 14:51 | <frewsxcv> | chrome and firefox currently differ |
| 14:53 | <Domenic> | annevk: Sebmaster, yeah. We'll track it and update wpt. |
| 14:53 | <annevk> | <3 |
| 14:55 | <annevk> | frewsxcv: per https://dom.spec.whatwg.org/#interface-htmlcollection the property names don't enumerate |
| 14:56 | <annevk> | frewsxcv: so I'm guessing Gecko is correct |
| 16:57 | <mounir> | annevk: for the inline table, should we wait to get philipj's opinion? |
| 17:08 | <annevk> | mounir: I guess that's fine, but you'll still need to address how to exactly navigate the table |
| 17:09 | <Domenic> | annevk: I don't get it, it seems clear to me? |
| 17:10 | <annevk> | Domenic: we are much more precise elsewhere, e.g., "... to the value given in the second column of the row of the following table whose first column contains the /new playback state/." |
| 17:10 | <annevk> | Domenic: and even that is not as precise as it doesn't account for cells... |
| 17:10 | <Domenic> | well ok, I guess for consistency we can just copy that wording, but it seems really overkill |
| 17:11 | <annevk> | Domenic: I think that extra context helps a lot, especially if you don't have the table in front of you visually |
| 17:12 | <annevk> | Domenic: also, for someone who always complains about vagueness of non-ES specifications, I'm disappointed |
| 17:12 | <Domenic> | annevk: I really don't feel like anyone needs instructions on how to read a clearly-labeled table. |
| 17:13 | <mounir> | as someone who never complains about vagueness, I find this overkill :) |
| 17:13 | <mounir> | but I will apply the change request :) |
| 17:14 | <annevk> | Domenic: it doesn't really follow from first principles to how it should be read |
| 17:14 | <Domenic> | I'm not really that into debating this but I don't understand what first principles are involved in reading a table |
| 17:15 | <annevk> | If you don't say what the value should be set to, it's ambiguous |
| 17:15 | <Domenic> | The current wording is "the exception matching the given <var>error</var> in the following table" the table has a clearly labeled column "exception" |
| 17:16 | <Domenic> | whatevs, don't really care |
| 17:17 | <mounir> | annevk: btw, fwiw, your example is slightly falacious |
| 17:17 | <mounir> | annevk: it's a table with three column, way less clear what the association is ;) |
| 17:19 | <annevk> | mounir: since you want to continue debating the point I recommend you search for "second column" throughout the HTML standard to find many examples of us doing exactly this for two column tables |
| 17:20 | annevk | is also somewhat dubious about the ", then" thing having editorial precedent, but okay |
| 17:21 | <mounir> | annevk: updated |
| 17:21 | <annevk> | mounir: you also want to use ":" |
| 17:22 | <annevk> | mounir: and since <var>error</var> is a variable it doesn't need "the" |
| 17:23 | <annevk> | mounir: Domenic: perhaps we should wait for foolip since he had some thoughts on the timing stuff, no? |
| 17:23 | <mounir> | annevk: that sounds reasonable to wait for him |
| 17:24 | <Domenic> | annevk: I tend to agree; although it seems likely it won't impact anything (or that any changes would be made as part of a bigger change), this feels like foolip's area of expertise and it would be good to get his sign off |
| 17:25 | <mounir> | annevk: "the" removed. I didn't use ":" because it wasn't used in the example I saw |
| 17:26 | <annevk> | I guess there is some inconsistency on that, ugh |
| 17:26 | <mounir> | annevk: apart from 4.8.13.12.3, only "." is used |
| 17:26 | <mounir> | (in embedded-content.html that is) |
| 17:27 | <annevk> | Yeah, it isn't often in the entire spec, still seems better in a way, but I guess it's fine either way |
| 17:28 | <annevk> | Perhaps one day a real grammar nitpicker will discover us and help us out |
| 17:29 | <mounir> | given the size of the document, I hope for them that they will look, shiver and go away :) |
| 17:44 | <annevk> | Domenic: who are you looking for review from before landing? |
| 17:44 | <annevk> | Domenic: for <script type=module> |
| 17:45 | <annevk> | Domenic: would it help if I went through it again tomorrow? Or might it be better if I wait for Adam to give it another look? |
| 17:47 | <Domenic> | annevk: yeah I was hoping mainly for you and Adam before merging. A review would be lovely; I will poke Adam too. |
| 19:08 | <jyasskin> | Re https://github.com/WebBluetoothCG/web-bluetooth/pull/198, are there any examples of specs that assign a platform object's global environment from its parent as bz would like? |
| 19:22 | <annevk> | jyasskin: ImageData is an example where browsers disagree |
| 19:23 | <annevk> | jyasskin: see one of my PRs against wpt |
| 19:23 | <jyasskin> | Yeah, I don't doubt that browsers have been inconsistent about this (I assume between inheriting from a parent vs the entry settings object). I'm looking for wording to copy, if possible. |
| 19:24 | <annevk> | jyasskin: doubt that exists, have been trying to get IDL to define it |
| 19:24 | <jyasskin> | Ok, if IDL is going to define it, then I should probably wait in Web Bluetooth until the needed wording is more clear. |
| 19:25 | <jyasskin> | (IDL currently says "It is the responsibility of specifications using Web IDL to state which global environment (or, by proxy, which global object) each platform object is associated with.") |
| 19:29 | <annevk> | Yeah, it's a bit of a mess 😟 |
| 19:54 | <gsnedders> | Important real world questions: how do you tell a bunch of people their code is a mess politely? |
| 20:21 | <jamesr_> | gsnedders: lemme know when you find out, please |
| 21:06 | <darobin> | gsnedders: "Ah, yes, I did that in PHP a few years ago." |
| 21:07 | <gsnedders> | darobin: don't worry, half of this /is/ PHP |
| 21:07 | <darobin> | oh well there you go |
| 21:08 | <gsnedders> | Hey at least https://lists.w3.org/Archives/Public/www-archive/2016Jan/att-0004/graph.png doesn't look too bad as a dependency graph! |
| 21:08 | <gsnedders> | It's acyclic! |
| 21:08 | <darobin> | lol |
| 21:10 | <gsnedders> | I feel like it's over modularised, really |
| 22:06 | <rbyers> | annevk: What's your approach to / thoughts on conformance tests for the DOM spec? |
| 22:07 | <rbyers> | I was able to find only https://github.com/w3c/web-platform-tests/tree/master/DOMEvents ... |
| 22:14 | <gsnedders> | rbyers: https://github.com/w3c/web-platform-tests/tree/master/dom? |
| 22:14 | <gsnedders> | rbyers: searching case-sensitively? there's a number of dom* directories at the top level |
| 22:14 | <rbyers> | gsnedders: Yeah just found that one too. But is the W3C / WhatWG distinction important? |
| 22:14 | <gsnedders> | rbyers: not really |
| 22:15 | <rbyers> | Eg. presumably new tests are added only after W3C snapshots are taken of the DOM spec? |
| 22:15 | <gsnedders> | rbyers: don't read much into it being under the W3C org on GitHub |
| 22:15 | <gsnedders> | rbyers: no, that isn't the case |
| 22:15 | <rbyers> | Ah, cool. So it's reasonable for me to submit a PR to add tests for a new feature currently only in the WhatWG version? |
| 22:15 | <gsnedders> | rbyers: yes |
| 22:16 | <rbyers> | Perfect. I'm still planning on waiting until the features ships in at least one browser (probably silly to do sooner than that). |
| 22:16 | <rbyers> | Thanks! |
| 22:16 | <gsnedders> | rbyers: probably better to do before that so the feature gets testsd! |
| 22:18 | <rbyers> | Ok, happy to prepare it sooner - just figured no-one would want to land a test that fails everywhere (although I'd at least manually test it passing with the polyfill). In this case (EventListenerOptions and passive event listeners) it probably doesn't matter much since we (blink) will be the first to ship, and the ones writing/running the tests, etc. |
| 22:18 | <rbyers> | Still, would like to do this right. |
| 22:23 | <gsnedders> | rbyers: well, the long-term aim is still something along the lines of you guys running all of w-p-t and directly adding tests to it as part of your development, so the tests would land in w-p-t at around the same time as the impl lands in Blink |
| 22:24 | <rbyers> | Yeah, that would be awesome. I understand that's what Mozilla does. |
| 22:24 | <rbyers> | I'm trying to better understand the status here and hopefully my team can help push this along. |
| 22:25 | <gsnedders> | I'm happy to do anything that will help you guys get somewhere with that, FWIW, as I've said before |
| 22:27 | <rbyers> | Excellent, thanks! I lack a bunch of the context here, who on blink have you been talking to about this? I know dpranke and jsbell were pushing on this at one time, but I don't think there's a ton of active movement right now. |
| 22:27 | <gsnedders> | uhhhhhh |
| 22:27 | <gsnedders> | this was at TPAC I last spoke to anyone about it |
| 22:28 | <gsnedders> | Jeffrey (is that jyasskin? I forget surname) and someone else. |
| 22:28 | <jyasskin> | Yep |
| 22:28 | <jyasskin> | What? |
| 22:28 | <gsnedders> | jyasskin: Blink, running w-p-t |
| 22:29 | <jsbell> | yeah, trying to staff up a team to make blink's use of w-p-t better |
| 22:29 | <gsnedders> | it was you I spoke to at TPAC about that, I think |
| 22:29 | <jyasskin> | Sam Uong was the more likely implementer. I'm not sure what his state is now. |
| 22:29 | <jsbell> | rbyers: I can give you a brain dump. Basically just lots of stuff to do, needs dedicated attention. |
| 22:29 | <rbyers> | Great, thanks guys. Given that my team works on input, we're mostly blocked on the fact that we have no standard way to automated input tests (and manual tests are almost useless IMHO). We're working on extensions to webdriver for this, but once that's unblocked I plan to try to really push our use of web-platform-tests. |
| 22:30 | <gsnedders> | how much of it actually involves Google testing infra, and how much can be done by external people? |
| 22:31 | <jsbell> | gsnedders: most of the work to run w-p-t sanely is code changes in the chromium repo, so a chromium committer (not necessarily googler), but it's not dependent on changes to wpt or anything like that |
| 22:31 | <rbyers> | jsbell: I know we talked about this awhile back. Not much sense in my team making a major effort when 95% of our tests would be manual, but hopefully we'll be done the first stage of the WebDriver effort this quarter - so I reach out then. |
| 22:31 | <jsbell> | 10-4 |
| 22:31 | <gsnedders> | jsbell: okay, that's what I thought |
| 22:33 | <rbyers> | Ok, gotta run. For now I'll make sure we're adding WPT tests for the spec changes we drive, and importing the automated ones to run in blink's repo. I definitely want to help more when the automation is ready though - maybe Q2. |
| 22:33 | <rbyers> | Thanks! |
