| 00:13 | <MikeSmith> | rektide: no idea what you mean by https://twitter.com/rektide/status/785210610829168644 “specs assume a 1-of-each principle. Yes, most people only want 1 gyro, 1 compass, 1 ALS, 1 sound card” |
| 00:16 | <MikeSmith> | because, e.g., device orientation API and geolocation API assume nothing at all about what kind of sensors on the device expose the orientation information, or how many of them are usedーwhether there’s even a gyro at all vs some other way(s) to determine the orientation, or whether the location info is from a GPS sensor or cell triangulation or some combination of sensors |
| 00:17 | <MikeSmith> | also, what is ALS? |
| 00:27 | <astearns> | ambient light sensor? |
| 00:27 | <astearns> | (unless they're referring to the American Lumber Standard) |
| 00:58 | <MikeSmith> | astearns: ah OK |
| 07:04 | <Ms2ger> | @media (400px <= min-width <= 700px) { � } |
| 07:04 | Ms2ger | wonders if that's right |
| 08:44 | <tobie> | rektide: trying to address all of these issues in the Generic Sensor API (https://w3c.github.io/sensors/) |
| 08:47 | <tobie> | rektide: comments welcome. |
| 09:32 | <annevk> | MikeSmit1: should maybe give youenn WPT rights? See https://github.com/w3c/web-platform-tests/pull/3592 |
| 09:32 | <annevk> | I'll merge that for now |
| 09:46 | <annevk> | I looked through the worker tests and I cannot really find any that use data URLs, other than some importScripts tests |
| 09:46 | <annevk> | Where importScripts gets passed a data URL |
| 09:59 | <MikeSmit1> | annevk: Yeah I will add yoenn once I get back to my pc |
| 12:57 | <annevk> | Hmm |
| 12:57 | <annevk> | Chrome dispatches a string to window.onerror?! |
| 12:58 | <annevk> | Oh I don't understand how this works |
| 13:23 | <mkwst> | Doesn't window.onerror get something like 5 arguments? |
| 13:23 | <mkwst> | It's super-strange. |
| 13:38 | <annevk> | It does |
| 13:38 | <annevk> | And is |
| 13:40 | <jgraham_> | Isn't there some reason the strangeness is good |
| 13:40 | <jgraham_> | Like it prevents cross origin leaks |
| 13:44 | <annevk> | jgraham_: that is fine, but it not behaving like a normal event handler is not |
| 13:44 | <annevk> | jgraham: btw, would appreciate help with https://github.com/w3c/web-platform-tests/pull/3945 if you got some time |
| 13:46 | <jgraham> | annevk: What doesn't work? |
| 13:47 | <annevk> | jgraham: it seems the harness still trips over the exceptions somehow |
| 13:48 | <annevk> | jgraham: in particular, I get "uncaught exception: 2" |
| 13:48 | <jgraham> | annevk: Oh, allow_uncaught_exception doesn't play well with file-per-test |
| 13:49 | <jgraham> | Because file_is_test is using the exception to track whether the test passed |
| 13:49 | <annevk> | That is single page test? |
| 13:49 | <jgraham> | Yeah |
| 13:51 | <jgraham> | You could just create a single async_test and mark it done. You also wouldn't need explict_done: true that way |
| 13:55 | <annevk> | jgraham: ta |
| 13:55 | <annevk> | jgraham: pushed updates |
| 14:25 | <Ms2ger> | jgraham, can we improve the error message when using file-is-test + allow-uncaught? |
| 14:29 | <jgraham> | Ms2ger: We can |
| 14:30 | <jgraham> | It could possibly even be made to work if you inspected the exception in that case |
| 15:11 | <frewsxcv_> | Given this line "If the element is the HTML body element or does not have any associated CSS layout box return zero and terminate this algorithm." https://drafts.csswg.org/cssom-view/#dom-htmlelement-offsettop what should this code return? https://gist.github.com/frewsxcv/91f13d34665a977164e0971e1c44a251 |
| 15:11 | <frewsxcv_> | I would have thought 8 and 8, but all browsers I try seem to return 0 and 0 |
| 15:12 | <frewsxcv_> | Should the spec be updated to match most browsers? |
| 15:18 | <annevk> | frewsxcv_: that should return the same as when innerBody is a <div> |
| 15:19 | <annevk> | frewsxcv_: "the HTML body element" is a specific body element instance for which innerBody is not a match |
| 15:20 | <frewsxcv_> | Right, that was my understand too |
| 15:20 | <frewsxcv_> | Though should the spec be changed if no browsers honor such a rule? |
| 15:21 | <annevk> | frewsxcv_: if the spec doesn't match browsers it should change, yes |
| 15:22 | <annevk> | frewsxcv_: unless all browsers are willing to change within some reasonable timeframe |
| 15:22 | <frewsxcv_> | Where's the issue tracker for cssom-view? |
| 15:23 | <frewsxcv_> | https://github.com/w3c/csswg-drafts ? |
| 15:24 | <annevk> | Think so |
| 15:26 | <frewsxcv_> | https://github.com/w3c/csswg-drafts/issues/584 |
| 15:44 | <Ms2ger> | \o frewsxcv_ |
| 15:45 | <frewsxcv_> | o/ |
| 17:59 | <Iarfen> | Hi! |
| 18:22 | <TabAtkins> | Ms2ger: Yeah, that's right (per spec; nobody's implemented that syntax yet). |
| 18:48 | <Iarfen> | How I have to do the commits in order to collaborate? |
| 20:21 | <smaug> | aha, ExtendableMessageEvent is buggy |
| 20:21 | <smaug> | the usual, default values for dictionary properties missing |
| 20:21 | <smaug> | (or required) |
| 20:32 | <jyasskin> | tobie: Nice analysis in https://github.com/heycam/webidl/pull/180#issuecomment-252736486! |
| 20:32 | <jyasskin> | tobie: Your examples make me personally lean toward traversing the prototype in record<>s, but I defer to Domenic and the other real experts here. |
| 20:33 | <TabAtkins> | Same. |
| 20:34 | <jyasskin> | tobie: I am relieved that I said "this only matters in obfuscated-javascript competitions" about the order we call Get(), and not about whether we traverse the prototype. ;) |
| 20:49 | <tobie> | Would love a bunch of eyeballs especially from folks with a WebDev background on https://github.com/heycam/webidl/pull/180#issuecomment-252736486 (off the top of my head: JakeA, slightlyoff, marcosc_) |
| 20:56 | <smaug> | uh, lots of discussion in github prs |
| 20:56 | <smaug> | it all really should go to issues |
| 20:58 | <Domenic> | Why? Discussion in PRs makes sense; it's discussion about something concrete. |
| 21:01 | <smaug> | github hides some comments in prs |
| 21:01 | <smaug> | prs should be about discussion about the pr itself |
| 21:01 | <smaug> | like review |
| 21:02 | <Domenic> | I disagree. |
| 21:02 | <smaug> | it is mostly github's buggy handling of comments in prs which is really bad |
| 21:02 | <Domenic> | I haven't seen that issue recently. |
| 21:02 | <smaug> | I don't recall in which cases it hides some comments |
| 21:03 | <AutomatedTester> | it hides then if someone pushes with -f |
| 21:03 | <AutomatedTester> | its got better at showing there were comments on a previous version of the PR |
| 21:03 | <AutomatedTester> | but before you used to lose ALL context. |
| 21:04 | <smaug> | it has happened that feedback was asked for a spec change, but pretty much all the interesting discussion was hidden |
| 21:09 | <tobie> | smaug: afaik, but I could be wrong, this is an issue when discussions happen on comments regarding a specific line of code, not on general comments. |
| 21:10 | <tobie> | smaug: best way to check this would be to look at the GH API's output. |
| 21:24 | <tobie> | smaug: curl https://api.github.com/repos/heycam/webidl/issues/180/comments and https://api.github.com/repos/heycam/webidl/issues/180/comments?page=2, you'll see the whole top-level comments there. |
| 21:24 | <tobie> | smaug: note this is the GH API URL to the issue #180 and not it's related PR. |
| 21:25 | <tobie> | smaug: implementation wise, GH treats PR as a special case of issue |
| 21:27 | <smaug> | and it is just buggy with prs :) |
| 21:27 | <smaug> | no reason to not use issues |
| 21:28 | <tobie> | smaug: talking about real code beats talking about abstract things in my book |
| 21:30 | <tobie> | smaug: I agree we could do a PR and then open another issue to discuss said PR in that case, |
| 21:30 | <smaug> | https://github.com/heycam/webidl/pull/180 as an example is a mix of reviews and proposals and stuff. It would be way easier to follow the discussion if the proposals and such were in an issue and one people agree what should be done, there would be a pr for the spec change |
| 21:31 | <tobie> | smaug: well, except sometimes people only really start to understand what's at stake when there's code to review. |
| 21:31 | <tobie> | smaug: (code or spec changes) |
| 21:31 | <smaug> | That rarely happens with spec stuff |
| 21:32 | <smaug> | (partly because it is somewhat harder to review spec changes) |
| 21:32 | <tobie> | smaug: well it's a non-issue, then, no? ;) |
| 21:33 | <smaug> | reviewing itself is an issue |
| 21:33 | <smaug> | but nothing to do with github issues/pr stuff |
| 21:34 | <tobie> | smaug: I agree both GH issues and PRs tend to drift and quickly go all over the place. |
| 21:36 | <tobie> | smaug: that's why, as editor, I tend to update the main issue with the current state of the conversation, write summaries, or split up an issue into more precise ones, potentially sometimes closing the main issue. |
| 21:36 | <tobie> | smaug: Not sure how to best fix that, but I digress. |
| 21:40 | <smaug> | I see that spec writing should be similar to writing code |
| 21:41 | <smaug> | when you upload a patch (pr) you already should know what kind of change should be done |
| 21:41 | <jyasskin> | smaug: The open-dictionary issue (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20158) sat for years until the PR focused people's minds. Folks got stuck discussing iteration order in the issue, but only noticed the prototype question once the spec text was there. |
| 21:41 | <smaug> | so, github pr is similar to bugzilla bug in my mind |
| 21:41 | <smaug> | and issues for discussion |
| 21:42 | <smaug> | (well, W3C bugzilla is used like github issues, I was referring to mozilla's bugzilla ) |
| 21:43 | <smaug> | I guess I could be happy with PRs only, if it wasn't buggy |
| 21:49 | <Iarfen> | How I do to make suggestions? I'm not allowed to do a pull request, what can I do? |
| 21:52 | <Domenic> | larfen: have you read https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F ? |