| 00:04 | <Domenic> | Hmm yeah |
| 00:05 | <Domenic> | Not sure how this fits into the Web IDL type system |
| 00:05 | <Domenic> | Since it doesn't make much sense as a return type |
| 00:26 | <TabAtkins> | Well, it can output as a Map as a return value. |
| 00:27 | <TabAtkins> | Same as sequence<> outputs as an Array (but can be lots of things as an argument value) |
| 00:27 | <Domenic> | Hmm not bad |
| 01:01 | <Domenic> | Wow 88.6% of pages use UTF-8?? https://w3techs.com/technologies/overview/character_encoding/all |
| 01:01 | <Domenic> | I didn't know the world was such a happy place |
| 01:09 | <Domenic> | https://en.wikipedia.org/wiki/UTF-8#/media/File:Utf8webgrowth.svg |
| 01:16 | <Domenic> | I wonder why https://en.wikipedia.org/wiki/UTF-8#WTF-8 doesn't mention https://simonsapin.github.io/wtf-8/ |
| 01:19 | <Domenic> | http://people.ds.cam.ac.uk/fanf2/hermes/doc/qsmtp/draft-fanf-wtf8.html is funny |
| 03:19 | <Krinkle> | Curious if there's any recommended way of dealing with localStorage key eviction, in a way that scales reasonably and performs well on mobile. https://github.com/whatwg/storage/issues/11#issuecomment-283233411 / https://phabricator.wikimedia.org/T121646#3063515 |
| 06:42 | <yoav> | annevk: Finally getting back to https://github.com/whatwg/fetch/pull/442/files#r96880945 |
| 06:46 | <yoav> | If I properly understand your suggestion there, you'd prefer to get rid of all changes in current PR, create the concept of "potential destination", have preload use that, and just translate is to destination before preload triggers a fetch |
| 06:46 | <yoav> | is that correct? |
| 08:05 | <JakeA> | MikeSmith: the outline stuff in the html5 checker… does it miss section roots because the generated outline doesn't provide a link from the parent to child roots? |
| 08:09 | <MikeSmith> | JakeA: no it doesn’t show the headings for the sectioning roots because that is the required result of following the outline algorithm as specified |
| 08:10 | <MikeSmith> | the spec says nothing about generating separate outlines for the sectioning roots and then linking them together |
| 08:11 | <MikeSmith> | the algorithm if applied to a document builds only a single outline for the document, which drops any headings for the sectioning roots |
| 08:12 | <MikeSmith> | all the existing implementations of the outline algorithm have followed the spec on this |
| 08:12 | <MikeSmith> | e.g., h5o and gsnedders outliner |
| 08:14 | <MikeSmith> | I guess it could be argued that the it’s assumed we’re supposed to re-run the algorithm on each sectioning root we run into and .. somehow store a separate object for each and then somehow link them together |
| 08:14 | <MikeSmith> | but that’s not what the actual normative spec text says to do |
| 08:16 | <JakeA> | MikeSmith: this sounds like *looks into camera* the root of the issue |
| 08:16 | <JakeA> | Trying to get confirmation from Hixie |
| 08:26 | <MikeSmith> | it’s cool when you look into the camera like that |
| 15:04 | <tobie> | JakeA: I'm working on motion sensors right now. Some of the use cases sound like great candidates for background events. |
| 15:05 | <tobie> | JakeA: was curious if you had data on how often SW are woken-up in practice |
| 15:05 | <tobie> | JakeA: + battery cost of doing so |
| 15:05 | <tobie> | JakeA: use cases are e.g. indoor navigation using sensor data |
| 15:06 | <JakeA> | tobie: I think the battery cost is generally pretty high, because it involves booting the browser up. I don't have data though, because no two cases are alike |
| 15:06 | <JakeA> | tobie: But I know that the Physical Web folks couldn't wake the SW up per beacon |
| 15:07 | <annevk> | So I was thinking that if we added integrity to service workers we could maybe allow them cross-origin, but that still wouldn't protect against an XSS-installed service worker |
| 15:07 | <JakeA> | That's the main reason we haven't allowed them |
| 15:08 | <annevk> | So what you really need is some kind of nonce+integrity or integrity declared through HTTP headers |
| 15:08 | <annevk> | If integrity is declared through HTTP, you should be safe from XSS |
| 15:08 | <annevk> | I'm not sure what the latest on that is exactly though |
| 15:09 | <annevk> | (Also, I'm just brainstorming a bit here, I haven't seen many requests or indication this is a priority.) |
| 15:09 | <tobie> | JakeA: so even 1/minute would be too much |
| 15:10 | <JakeA> | tobie: oh wow yes |
| 15:11 | <tobie> | JakeA: need to balance size of data collected too. |
| 15:11 | <JakeA> | tobie: I think the main cost is booting up the browser and potentially the radio too |
| 15:21 | <tobie> | JakeA: sounds like I need to revise my plans, than. :( |
| 15:22 | <tobie> | s/than/then/ |
| 15:22 | <tobie> | JakeA: thanks! |
| 15:37 | <annevk> | jgraham: Ms2ger: here's an alternative WPT review plan: I land my own PRs and file browser bugs on the failures which will lead to review |
| 15:38 | <annevk> | jgraham: Ms2ger: I also think we should maybe prune OWNER files where folks haven't been reviewing changes in a while as the current system is more like a PING file since nobody can be hold accountable |
| 15:40 | <annevk> | tobie: I think for mobile sensors you really want something like Apple's M chip series |
| 15:40 | <annevk> | tobie: that just store a bunch of the data and then expose it to the app at the point the user might do something with it |
| 15:41 | <annevk> | tobie: depends a bit on the sensor too of course |
| 15:41 | <tobie> | annevk: the owner files were bootstrapped from the list of committers to that directory. |
| 15:41 | <tobie> | annevk: they were *mean't* to be edited and pruned. |
| 15:41 | <tobie> | meant |
| 15:41 | tobie | can't spell todya |
| 15:42 | <tobie> | annevk: yes, I guess. I was mostly wondering if there was a way to bridge different use cases through SW |
| 15:44 | <gsnedders> | annevk: there are definitely people who want to be in a PING file though |
| 15:45 | <gsnedders> | annevk: one option is we simply introduce two separate files and update wpt-pr-bot |
| 15:45 | <tobie> | annevk: e.g. storing motion data for mapping out the number of steps on a run once you're back from it, vs near real-time indoor positioning on map using sensors. |
| 15:45 | <annevk> | gsnedders: I think a reasonable solution would be to move all OWNERS to PING and only once we have an actual OWNER add them there |
| 15:46 | <tobie> | gsnedders: add categories to owners. |
| 15:47 | <tobie> | gsnedders: rename all the files if you want to. |
| 15:47 | <tobie> | gsnedders: but dealing with more than one file seems tedious |
| 15:48 | <gsnedders> | tobie: yeah, on the whole I agree |
| 15:52 | <Ms2ger> | OWNERS was intended to mean PING, really |
| 15:53 | <Ms2ger> | I don't think allowing particular people to land without any review is a good idea |
| 15:53 | <gsnedders> | landing without review also ties into the discussions about how to deal with specs that are still incubating and moving fast |
| 15:57 | <annevk> | Ms2ger: I didn't say it's without review, it's just that the review is delayed |
| 15:57 | <annevk> | Ms2ger: because currently there's no review and that means everything is stalled |
| 15:58 | <annevk> | And the OWNERS/PING thing was unrelated to this review thing, that was more about making sure we actually know who are responsible (or whether we lack someone responsible) |
| 15:59 | <annevk> | You need some accountability |
| 16:00 | <annevk> | We could also do OWNERS / PEERS |
| 16:02 | <Ms2ger> | The situation we have right now is that nobody is responsible |
| 16:03 | <Ms2ger> | That's a problem of resource allocation, not files |
| 16:03 | <annevk> | Well, making that transparent seems like a good first step |
| 16:04 | <annevk> | And I actually want to be responsible for URL/CORS/XHR/Fetch/Encoding |
| 16:05 | <annevk> | And have made lots of changes over the past couple weeks to get those more into shape as you may or may not have noticed |
| 16:05 | <annevk> | It's based on that experience that I'm here suggesting changes |
| 16:05 | <annevk> | Being dismissive of them without really suggesting something else is not helping |
| 16:07 | <jgraham> | annevk: But I think the problem is that no one believes that review-later will cause review to happen |
| 16:07 | <annevk> | I do? |
| 16:07 | <annevk> | Implementations will have to fix their bugs after all |
| 16:07 | <annevk> | Or do you think they won't ever fix their bugs? |
| 16:08 | <annevk> | At that point you've lost |
| 16:08 | <gsnedders> | annevk: what vendor makes a general effort to fix new failing tests in wpt? AFAIK, none seriously do. |
| 16:08 | <annevk> | Lots do when bugs are filed |
| 16:08 | <annevk> | Firefox has, WebKit has, Edge has, Chrome has |
| 16:09 | <annevk> | I know because I've been doing this for a while |
| 16:09 | <gsnedders> | so we need a system that when a new failing test is added automatically file bugs? |
| 16:09 | <annevk> | No, I just file the bugs |
| 16:09 | <annevk> | As I said earlier... |
| 16:09 | <gsnedders> | no, I mean in general case of how we get people to care about failing tests |
| 16:10 | <annevk> | They already do |
| 16:10 | <gsnedders> | do they? when Gecko, Blink sync up to the latest web-platform-tests, they add expectations files to ignore any failures but don't analyse or file bugs for them. |
| 16:11 | <annevk> | That's their current system, but if you talk to the engineers they do want to fix those failures |
| 16:11 | <annevk> | And if you file bugs they do fix them |
| 16:12 | <annevk> | Again, I have some experience with this |
| 16:12 | <gsnedders> | the problem is I don't think it's practical to get every contributor to wpt to be running tests in all browsers and filing bugs |
| 16:13 | <annevk> | Geez |
| 16:13 | <annevk> | So require review for those contributors |
| 16:14 | <annevk> | Can we talk a bit more constructively about this perhaps? |
| 16:16 | <gsnedders> | The problem is we need a way that doesn't rely on individual contributors because otherwise we'll have failures slip through. That's my point. |
| 16:17 | <gsnedders> | And the problem is a hard one unless there's someone who's job it is is to analyse all incoming failures. |
| 16:17 | <jgraham> | annevk: So I'm feeling too ill to have an argument :) But I think my issue is different from gsnedders. I don't doubt that often you can find someone to at least look at failing tests (and you, specifically, have the social capital to make that process work resaonably often). But no one is going to look at passing tests (especially if you check in a file of tests that only pass). And it seems weird that you are happy to require review for spec chang |
| 16:17 | <jgraham> | (OK, where did that get cut off?) |
| 16:17 | <gsnedders> | "review for spec change" |
| 16:17 | <jgraham> | And it seems weird that you are happy to require review for spec changes but requiring equivalent review for tests is too hard. Can't you require the same reviewer to look at both? |
| 16:18 | <annevk> | jgraham: this is cleanup of existing tests |
| 16:18 | <annevk> | jgraham: or adding coverage |
| 16:19 | <annevk> | jgraham: and I do actually review passing tests every now and then too |
| 16:19 | <annevk> | jgraham: in particular when they need to be revised or we add new features or some such |
| 16:19 | <jgraham> | annevk: That you in particular are an angel (per diveintomark) is not in question |
| 16:19 | <annevk> | gsnedders: sure, the system is not perfect, but the current system basically makes me stop contributing |
| 16:20 | <annevk> | gsnedders: which seems worse |
| 16:20 | <jgraham> | annevk: So the hacky solution is to commit to m-c and ask for review from people at Mozilla because they clearly have a job description that involves doing those reviews |
| 16:21 | <jgraham> | (and when I say "hacky" it's an explicit design goal to leverage that fact) |
| 16:22 | <jgraham> | The less hacky solution seems to be to get some individuals to agree that reviewing your cleanup tests is also part of their job. It still seems strange that you can find that group for spec changes but not for test changes |
| 16:24 | <annevk> | Sure, I can probably get them rubberstamped |
| 16:24 | <annevk> | The system not pretending OWNERS will review the test as they actually don't might help with that |
| 16:25 | <annevk> | So I don't wait several days for them and then wait several days for whatever victim I can find |
| 16:26 | <jgraham> | Sure, if you want some technical fix to not imply that OWNERS actually feel a sense of responsibility then I'm happy with that |
| 16:52 | <tobie> | annevk: fwiw: the current review process (which is to allow one r+ either in wpt or in another public system) is something I fought for when I was at FB/W3C as a way to simplify the previous process which required someone *from a different company* to approve a contribution. |
| 16:53 | <tobie> | annevk: there is nothing that prevents us from modifying that process if it turns out it's not optimum |
| 16:53 | <tobie> | annevk: I don't think there's a formal process for gathering consensus around that. |
| 16:54 | <tobie> | annevk: I'd argue filing a bug/pr on the docs where the process is specified + mailing the testing-infra@ should be enough |
| 16:55 | <tobie> | annevk: possible work arounds could include: allow people with owner status to r+ their own changes, |
| 16:56 | <tobie> | have a lits of special contributors which can r+ their own changes |
| 16:56 | <tobie> | maybe have a (light) process to get someone on that list. |
| 16:57 | <tobie> | annevk: this is not rocket science, and whatever process is in place should be there to serve the goals of the project |
| 16:57 | <tobie> | annevk: not hinder them |
| 17:36 | <annevk> | tobie: thanks for the suggestions, I guess I need to think a bit more about what exactly needs to change beyond changing OWNERS |
| 17:58 | <tobie> | annevk: thanks for the reference to Apple M-series, btw. I knew these things existed, but didn't know what they were called. |
| 17:59 | <tobie> | annevk: now I have a nice Wikipedia article to point people to. |
