| 03:17 | <Domenic> | annevk: yeah, my thinking is I tried for something host-agnostic in TC39, it failed, so now streams suffers the consequences. Oh well, nothing we can do. |
| 05:37 | <foolip> | smaug is gone, but I asked about that in https://groups.google.com/a/chromium.org/d/msg/blink-dev/Mx9q5WXunSE/2lCq30dtBwAJ and will poke the thread again |
| 08:59 | <hsivonen> | annevk: the first two sentences of the "When UNESCO suggests" paragraph of https://www.w3.org/blog/news/archives/6225 do have a good point. |
| 09:01 | <annevk> | hsivonen: yeah |
| 09:04 | <annevk> | I wonder how the W3C decides what to use <abbr> for |
| 09:04 | <annevk> | Only three-letter-abbreviations-minus-W3C-itself? |
| 09:07 | <nox> | In https://drafts.csswg.org/css-transforms-2/#funcdef-perspective it says that value must be greater than 0, is that > or ≥? |
| 09:07 | <nox> | https://drafts.csswg.org/css-transforms-2/#PerspectiveDefined does -1/d, which should mean >, |
| 09:08 | <nox> | but https://drafts.csswg.org/css-transforms-2/#PerspectiveDefined says perspective(0) is just a neutral thing. |
| 09:08 | <nox> | Err, https://drafts.csswg.org/css-transforms-2/#neutral-element for last link. |
| 09:10 | <annevk> | nox: they haven't really defined depth so I'd just file a bug to say it's vague |
| 09:10 | <annevk> | nox: I'm guessing they mean the parameter, but... |
| 09:11 | <nox> | annevk: On https://github.com/w3c/csswg-drafts? |
| 09:11 | <annevk> | nox: I guess so |
| 09:11 | <annevk> | nox: hmm, the document itself points to https://github.com/w3c/fxtf-drafts/labels/css-transforms-1 |
| 09:12 | <nox> | Oh. |
| 09:12 | <annevk> | nox: so maybe there? CSS is |
| 09:12 | <annevk> | not the clearest at all this I find |
| 09:19 | <nox> | annevk: https://github.com/w3c/fxtf-drafts/issues/126 |
| 11:12 | <annevk> | JakeA: btw, I'm counting on you to review https://github.com/whatwg/dom/pull/434 as well; do you have that planned? |
| 11:15 | <annevk> | tobie: could it be that the PR diff tooling interferes with https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/? |
| 11:15 | <annevk> | tobie: e.g., the above referenced whatwg/dom PR from mkwst has a branch I can't push to, even though that should be on by default these days |
| 11:16 | <annevk> | tobie: I've noticed this happening more as of late, so I'm wondering if the tooling we have messes this functionality up somehow |
| 11:16 | <mkwst> | annevk: I just ticked the box manually, so, tooling aside, you should be able to fix all my mistakes now.. |
| 11:18 | <annevk> | mkwst: heh, thanks, wasn't actually planning on doing it just yet, but I found some minor nits and was gonna ask you if it were okay to push at some point, and then noticed it was broken again |
| 11:18 | <mkwst> | annevk: No worries. I'm happy to fix nits: you're busy. |
| 11:19 | <mkwst> | annevk: As long as you're telling me what nits to fix, that is. :) |
| 11:19 | <annevk> | mkwst: main bigger things I have: 1) what about this exception? 2) we should probably update the abstract now we do more than events and trees |
| 11:20 | <annevk> | mkwst: 3) tests and 4) can/will this be implemented without feature and how do we manage that if not? |
| 11:21 | <annevk> | mkwst: I'll wait with the nits until JakeA has reviewed as well, doesn't seem like much else is blocking this |
| 11:21 | <annevk> | mkwst: nobody in TC39 is screaming thus far |
| 11:21 | <annevk> | (low bar?) |
| 11:22 | <tobie> | annevk: it shouldn't. The only thing the tooling does is listen to events and update the content of the original post. |
| 11:22 | <mkwst> | 1. You tell me. I'm happy to make it a DOMException if you don't care. 2. Sure (though I'm still not sure this is really right for DOM, I don't have a better suggestion). |
| 11:22 | <mkwst> | 3. It'll be tough to actually the cancellation callback bits without an API that uses the thing. Everything else should be simple. 4. See #3. I don't think it makes much sense in isolation. |
| 11:23 | <mkwst> | 5. If TC39 gets involved, I'm going to delegate everything to Jake, because I don't have time to argue about this. :) |
| 11:26 | <annevk> | I'm okay with a DOMException as long as it has a unique name. "CancelationError" or some such would be fine. Though I wish ljharb would have answered the justification question other than "it needs to be like arrays" |
| 11:27 | <annevk> | I guess even if he proves the need for branding we could still tack that on DOMException... |
| 11:30 | <mkwst> | I don't understand what he'd like to protect against. |
| 11:30 | <mkwst> | *shrug* |
| 11:31 | <annevk> | Maybe the problem is that a problem in the program shouldn't be able to exit through the cancelation path? |
| 11:32 | <annevk> | So an attacker can halt something and go undetected? |
| 11:33 | <mkwst> | Assuming the attacker is already running script in your origin? |
| 11:34 | <mkwst> | Idunno. I'd like to understand the threat it's meant to address. If it's relevant, then I'd prefer to make it a DOMException thing if possible,. |
| 11:35 | <mkwst> | If we make it a DOMException, shall I send tobie a patch to add the name to https://heycam.github.io/webidl/#dfn-error-names-table? |
| 11:36 | <mkwst> | Or do you want the whole thing defined in DOM? |
| 11:36 | <tobie> | mkwst: yes please. |
| 11:39 | <annevk> | mkwst: we should add the name there and then reference it |
| 11:39 | <annevk> | mkwst: thanks for knowing how all the things work |
| 11:39 | <annevk> | mkwst: I guess we might also need to update testharness so it knows about that exception name |
| 11:40 | mkwst | does not know how all the things work :) |
| 11:41 | <mkwst> | Ok. If that sounds like a reasonable thing to do, I'll send out patches. |
| 11:42 | <annevk> | http://web.mit.edu/jwalden/www/isArray.html is a pretty good read, but all those problems also apply to platform objects! |
| 11:56 | <annevk> | Searching for "hasinstance inurl:public-script-coord" and Google gives me "Are you a robot?" while I'm logged in |
| 11:57 | <annevk> | And then they dare talk about AI on stage, come on |
| 11:59 | <mkwst> | To be fair, you might be a robot. |
| 12:01 | <annevk> | Bias! |
| 12:02 | annevk | finds https://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/thread.html#msg1 |
| 12:02 | <annevk> | (through W3C's search) |
| 12:09 | <JakeA> | annevk: yep. Going to fix useCache in the service worker spec. Then review the cancellation thing. |
| 12:11 | <annevk> | JakeA: cancelation |
| 12:11 | <annevk> | I guess we should add that to the style guide |
| 12:12 | <JakeA> | annevk: canceation. The Ls are just causing trouble, let's get rid of all of them. |
| 12:13 | <annevk> | JakeA: archibad |
| 12:13 | <JakeA> | Hahaha I'll take that |
| 12:40 | <MikeSmith> | https://wiki.whatwg.org/index.php?title=Style&diff=next&oldid=10160 😆 |
| 12:42 | <annevk> | So many variations to get wrong! |
| 12:44 | mkwst | is glad most of his specs are in W3C, where "cancelled" is spelled in a sane way. |
| 12:44 | <MikeSmith> | heh |
| 12:46 | <annevk> | mkwst: as long as the APIs get it right... |
| 12:46 | <mkwst> | s/right/wrong/ |
| 12:46 | <mkwst> | I'll just make sure not to use controversial words in APIs. :) |
| 12:46 | <MikeSmith> | canceỻation |
| 12:46 | <annevk> | You're in #whatwg now, but clearly you also left your sense of logic at the door so... |
| 12:47 | <mkwst> | `thing.stopIt()` |
| 12:51 | <nox> | mkwst: You mean cance//ed? |
| 13:25 | <MikeSmith> | Domenic is traveling at the moment I guess? |
| 13:25 | <MikeSmith> | wanted to ask him about https://github.com/w3c/ServiceWorker/issues/1073#issue-207922166 |
| 13:27 | <MikeSmith> | annevk: maybe you can help clue me in. I’m trying to figure out what change to make for the “Either step 8 should be removed (normative change!), or we should update HTML to have an invalid value default state (say "invalid"), which you can then throw an error on.” part of Domenic’s comment |
| 13:27 | <MikeSmith> | that step 8 is this: |
| 13:27 | <MikeSmith> | > If workerType is not a valid WorkerType value, queue a task to fire an event named error at the link element, and abort these steps. |
| 13:28 | <annevk> | MikeSmith: I'll take a look |
| 13:28 | <MikeSmith> | thanks |
| 13:28 | <MikeSmith> | I talked with Domenic about this earlier this week but am wondering if there’s an existing similar case in the HTML spec I can use as model |
| 13:29 | <MikeSmith> | nobody has implemented WorkerType yet I think, so we can spec it out the way we want |
| 13:31 | <MikeSmith> | to be clear the specific part I wonder how to spec is “a state which you can then throw an error on” |
| 13:31 | <annevk> | MikeSmith: if nobody has implemented this feature I like the idea of the normative change |
| 13:31 | <MikeSmith> | oh |
| 13:31 | <annevk> | MikeSmith: and just defaulting to "classic" |
| 13:31 | <MikeSmith> | OK |
| 13:32 | <annevk> | MikeSmith: I think most HTML attributes have a fallback that makes the thing function, a fallback that makes the thing broken would be a little strange |
| 13:32 | <MikeSmith> | hmm yeah when you put it that way, true |
| 13:33 | <MikeSmith> | OK well I will write up PR for the Service Worker spec with that change |
| 13:34 | <MikeSmith> | easy change |
| 13:34 | <MikeSmith> | annevk: thanks 🌸 |
| 13:58 | <wanderview> | JakeA: is there actually a requirement on mime type for importScripts()? |
| 13:58 | <wanderview> | I guess there is now |
| 13:59 | <JakeA> | wanderview: the spec had that for a while. Although neither Chrome or Firefox do |
| 14:00 | <JakeA> | wanderview: I changed it to point to HTML's mime type list, but it was there before |
| 14:00 | <wanderview> | JakeA: seems reasonable... thanks for testing it! |
| 14:00 | <wanderview> | JakeA: I'm glad I decided to start persisting headers on importScripts() even though there was no reason in our tree before |
| 14:01 | <wanderview> | now I can check the mime type a lot easier |
| 14:01 | <JakeA> | \o/ |
| 15:23 | <zcorpan> | mkwst: controversial words like "nonce"? :-P |
| 15:40 | <mkwst> | zcorpan: If the UK would just speak proper English, "nonce" wouldn't be a problem. :) |
| 15:52 | <gsnedders> | http://stackoverflow.com/questions/280049/javascript-callback-for-knowing-when-an-image-is-loaded#comment70314622_24201249 |
| 15:52 | <gsnedders> | the answer is no, right, because the event queue doesn't spin? |
| 15:57 | <zcorpan> | gsnedders: right. per the current spec you could have the opposite problem that 'loaded' is run twice. but the spec for .complete needs some fixing to not change value while script is executing (probably instead it should change value in the same task that fires the 'load' event) |
| 15:58 | <gsnedders> | zcorpan: how is it run twice? |
| 16:00 | <zcorpan> | gsnedders: no sorry, missed that the script had an "else" |
| 16:00 | <zcorpan> | gsnedders: had the script unconditionally added the listener it could run twice |
| 16:00 | <gsnedders> | even without the else how could it run twice without it going from complete to incompletE? |
| 16:01 | <zcorpan> | gsnedders: if the script runs after complete is flipped to true but before the load event has been fired |
| 16:08 | <gsnedders> | zcorpan: can you reload and check my comment is accurate? |
| 16:09 | <zcorpan> | gsnedders: 👍 |
| 16:10 | <gsnedders> | zcorpan: do we have a bug for the .complete spec? |
| 16:10 | <zcorpan> | yeah |
| 19:17 | <jsbell> | wanderview: Do you know if the Cache API impl in FF maintains insertion order? My attempted upstreaming of a test is blocked by flakiness: https://travis-ci.org/w3c/web-platform-tests/jobs/219426158 - I didn't spot a bugzilla issue... |
| 19:25 | <wanderview> | jsbell: can you define insertion order? |
| 19:25 | <wanderview> | jsbell: looks like for cache keys? |
| 19:25 | <jsbell> | correct (sorry for being imprecise) |
| 19:26 | <wanderview> | jsbell: we do maintain insertion order, but we define that as the time the body completes vs the order cache.put() calls were made |
| 19:27 | <wanderview> | so depending on how the keys were inserted, we may get a slightly different order from chrome |
| 19:27 | <wanderview> | I think we have agreement in an issue somewhere to use a more transactional approach where cache.put() blocks later cache.put() calls so that you get strict ordering based on the calls |
| 19:27 | <wanderview> | not sure if that is spec'd yet and we definitely haven't implemented it yet |
| 19:28 | <jsbell> | okay. Wonder what I should do for that test... |
| 19:29 | <wanderview> | jsbell: does it put a bunch of stuff in the cache and then check the ordering? |
| 19:29 | <jsbell> | wanderview: Yeah. https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/wpt/service-workers/cache-storage/script-tests/cache-keys.js?l=50 |
| 19:30 | <jsbell> | I can make the test ignore the order if we believe it's not required by the spec at the moment |
| 19:30 | <wanderview> | jsbell: can we make prepopulated_cache_test() serialize its put() calls? |
| 19:32 | <wanderview> | jsbell: I mean, order is defined in the spec for .keys()... but I'm not sure it defines a strict order for overlapping put() calls at the moment: https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/service-workers/cache-storage/resources/test-helpers.js#148 |
| 19:32 | <jsbell> | wanderview: Yeah, that should work. |
| 19:32 | <jsbell> | wanderview: my dev box is offline at the moment but once it's back I'll give that a whirl in FF and see |
| 19:34 | <wanderview> | jsbell: thanks! I think transaction discussion might be in this issue: https://github.com/w3c/ServiceWorker/issues/823 |
| 19:35 | <wanderview> | yea, loose agreement to "work towards under-the-hood transactions to prevent races on writes", but doesn't seem to have been spec'd yet: work towards under-the-hood transactions to prevent races on write |
| 19:35 | <wanderview> | https://github.com/w3c/ServiceWorker/issues/823#issuecomment-175320500 |
| 21:37 | <felixjet> | can i represent elapsed number of days with <time> tag? |
| 21:38 | <felixjet> | <time>6</time>, or even <time>Day 6</time> |