| 00:57 | <hgl> | MikeSmith, awesome. Dafeng said he had a great time with you too. also he said you put in a good word for me. thanks you! i just joined his company recently. :) glad to hear you are happy with Gao Bo's translation. |
| 05:44 | <annevk> | SimonSapin: search for "computed value of the 'color' property" |
| 05:45 | <annevk> | SimonSapin: https://html.spec.whatwg.org/multipage/scripting.html#2dcontext:canvasrenderingcontext2d-22 seems to be a somewhat direct reference |
| 05:46 | <annevk> | So even <canvas> flushes layout... |
| 06:31 | <annevk> | JakeA: Domenic: is it worth correcting https://twitter.com/KevinLozandier/status/630588656835760129? |
| 06:32 | <annevk> | JakeA: Domenic: I've seen him mention this several times now, neglecting to mention that e.g., Domenic is a TC39 member too... |
| 06:46 | <annevk> | richt: what's the Working Copy application? |
| 06:47 | <annevk> | I see, a git client |
| 06:53 | <JakeA> | annevk: on it |
| 08:24 | <richt> | annevk: Working Copy is an iOS Git app: http://workingcopyapp.com. I've removed it...unless it's ok to use it after all. |
| 09:08 | <annevk> | richt: seems alright |
| 09:12 | <annevk> | richt: it's also still approved for /whatwg afaict |
| 09:16 | <annevk> | Does anyone understand the GitHub Public/Private distinction and why I can change it for Owners, but not for Members? |
| 09:17 | <annevk> | Ideally everyone part of WHATWG is Public, I think... |
| 09:18 | <richt> | annevk: I revoked SSH key access from Working Copy. It should no longer be approved (or even listed) :/ |
| 09:19 | <annevk> | richt: perhaps SSH key access and being an approved application are different things |
| 09:20 | <annevk> | richt: if you want I can remove it as an approved application |
| 09:20 | <richt> | annevk: please do. |
| 09:20 | <richt> | annevk: I was just trying it out a couple of weeks ago. |
| 09:44 | <SimonSapin> | thanks annevk |
| 09:46 | <annevk> | SimonSapin: we can (and probably should) make that clearer down the road |
| 09:46 | <annevk> | I think it's somewhat important to clearly identify the places that require layout/style recalc |
| 09:57 | <SimonSapin> | annevk: perhaps https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-fillstyle , when it links to parsed as CSS <color> values, should also link to the bit you pointed out |
| 10:11 | <annevk> | SimonSapin: perhaps the <color> parser needs an explicit second argument to supply currentColor |
| 10:15 | <SimonSapin> | yes, except that CSS Color is written more in the style "this is a thing that exists, and that is what it means" rather than algorithms with arguments and results |
| 10:36 | <annevk> | At some point that requires either a wrapper of sorts or a rewrite... |
| 15:45 | <annevk> | JakeA: "is this the correct origin? Does it have a padlock?" yes this |
| 15:46 | <annevk> | Updating HTTP references was somehow super painful |
| 15:47 | <annevk> | Not sure anything really improved, other than stripping leading and trailing whitespace from header values |
| 15:47 | <JakeA> | annevk: something like [padlock][origin-minus-scheme-if-http(s)][ gap ][path in light grey] might work |
| 15:47 | <JakeA> | People get angry at removing the path |
| 15:47 | <JakeA> | unless Apple do it |
| 15:48 | <annevk> | Given that mobile rules the world these days I'd be interested in hearing what these folks suggest for displaying all that stuff there... Doesn't really seem reasonable to fit that all... |
| 15:50 | <JakeA> | https://jakearchibald.com/2014/improving-the-url-bar/#comment-1369138973 "This is a terrible idea… and, like so many others, I can't help but be suspicious that this is a tricksy way to make users stupider, less powerful" |
| 15:53 | <annevk> | I actually think it empowers more users overall |
| 15:53 | <annevk> | Since training origin + padlock is much easier than origin + padlock while ignoring "https://" (but not "https.") and everything following the initial "/" |
| 15:55 | <annevk> | And security is still what we have the address bar for, navigating based on hacking the URL space not so much |
| 15:55 | <annevk> | And I believe technically URL paths are opaque anyway, although search engines derive meaning from them |
| 16:05 | <jgraham> | Woah |
| 16:06 | <jgraham> | What happened with all the editable stuff |
| 16:06 | <Domenic> | annevk: does my point at https://github.com/whatwg/fetch/issues/103#issuecomment-129507316 make sense? the primitives there are OKness and mutexes, or at least OKness and transactions. |
| 16:07 | <annevk> | Domenic: hmm, can't follow it entirely, maybe JakeA can? |
| 16:07 | <Domenic> | annevk: well, suppose you wanted atomic transactions based on only allowing through 301s instead of only allowing through OK. |
| 16:07 | <Domenic> | you need a transaction primitive that you can combine arbitrarily with any predicate |
| 16:07 | <Domenic> | not one that's hard-coded to the OK-ness predicate |
| 16:08 | <JakeA> | You'll still end up with specs including "if response is not 'ok', treat as network error" |
| 16:09 | <annevk> | That might be okay though |
| 16:09 | <JakeA> | If we don't get a way to treat !ok requests as failures, I'll want to add it to cache.add & addAll |
| 16:09 | <annevk> | :-/ |
| 16:09 | <JakeA> | If it's considered high-level, perhaps that's the place for it |
| 16:11 | <jgraham> | Does anyone know if the intersection of focus and contenteditable is specced anywhere? |
| 16:21 | <annevk> | jgraham: there's https://w3c.github.io/editing/ but how stable any of that is, is unclear |
| 16:29 | <wanderview> | JakeA: could NEL be implemented completely in user-space on top of SW? |
| 16:29 | <wanderview> | seems like it could |
| 16:30 | <wanderview> | with foreign fetch event |
| 16:30 | <JakeA> | wanderview: it seems that if //origin includes a js file from //other-origin, and that request fails… ah yes you know |
| 16:30 | <JakeA> | but yes |
| 16:31 | <wanderview> | should we recommend that instead of adding a new thing to the platform? |
| 16:31 | <wanderview> | I guess there is download cost for the scripts/libs |
| 16:31 | <JakeA> | The thought did cross my mind, it feels premature |
| 16:31 | <wanderview> | k |
| 16:34 | <jgraham> | annevk: Yeah, I just found that apparently the work that Aryeh did has now been replaced with something that has basically no content |
| 17:59 | <annevk> | jgraham: yeah if that continues I plan to fork |
| 18:02 | <wanderview> | JakeA: have we previously considered some SW feature that tells the browser to automatically "reply to these URLs by executing .match() on this Cache object" without running js? So we can avoid spinning up a worker thread on cold-launch of a site |
| 18:04 | <JakeA> | wanderview: yeah, we drafted a "static routes" API, where you'd specify a url (with globbing) and could provide a series of sources to attempt to find a match, eg: look for match in cache, try network, match a specific request in cache |
| 18:05 | <JakeA> | We decided we shouldn't solve performance problems until we knew the size and shape of them |
| 18:05 | <JakeA> | But if we're getting to that point we can look at it again |
| 18:05 | <wanderview> | JakeA: ok... I guess it comes down to what we think is reasonable performance |
| 18:06 | <wanderview> | JakeA: firefox os is moving to service workers from out non-standard app:// scheme... but its hard to avoid a performance regression since app:// pulled straight from a zip archive on disk |
| 18:07 | <wanderview> | but a performance regression for firefox os may still be a performance improvement for the web in general |
| 18:09 | <JakeA> | wanderview: what kind of regression are we talking? I mean, if it's bad, FirefoxOS may be a decent place to trial such an API |
| 18:10 | <wanderview> | JakeA: we have two optimizations to try first... 1) grace time to keep worker thread alive longer (easy) 2) pre-compile the SW scripts and cache the bytecode |
| 18:11 | <wanderview> | JakeA: if I had to guess, I think we will still have a 20ms to 30ms regression for the machinery to start the thread... but who knows for now |
| 18:11 | <JakeA> | Makes sense. I *think* we have both of those going on now |
| 18:11 | <wanderview> | JakeA: I was asking about the other thing as kind of a backup plan |
| 18:11 | <JakeA> | wanderview: hah, that's exactly what we drafted the API for :D |
| 18:11 | <wanderview> | JakeA: yea... chrome definitely has the grace period... had not heard about caching the bytecode, but wouldn't surprise me |
| 18:12 | <wanderview> | JakeA: ok, good to know we can resurrect that if needed |
| 18:12 | <wanderview> | thanks! |
| 18:12 | <JakeA> | wanderview: http://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html |
| 18:13 | <wanderview> | I think we only cache bytecode for asmjs scripts at the moment... |
| 20:48 | <wanderview> | TabAtkins: do you know if CSSFontFaceLoadEvent is a real thing? |
| 20:49 | <TabAtkins> | Real how? |
| 20:49 | <TabAtkins> | It's, like, in the spec. |
| 20:49 | <wanderview> | I don't see it in here: https://drafts.csswg.org/css-font-loading/ |
| 20:49 | <TabAtkins> | Sorry, yeah, "load" doesn't exist. |
| 20:49 | <TabAtkins> | "loading", "loadingdone" and "loadingerror" do. |
| 20:50 | <wanderview> | TabAtkins: I see this in the spec: FontFaceSetLoadEventInit |
| 20:50 | <wanderview> | without the Init |
| 20:50 | <TabAtkins> | Yeah, that's the interface. |
| 20:51 | <TabAtkins> | https://drafts.csswg.org/css-font-loading/#fire-a-font-load-event |
| 20:51 | <wanderview> | hmm... I wonder why we have this CSSFontFaceLoadEvent interface then |
| 20:51 | <TabAtkins> | Because you need to subclass DOMException if you want to pass extra info. |
| 20:51 | <TabAtkins> | Or Event, whatever. |
| 20:51 | <TabAtkins> | I'm incapable of using words today. |
| 20:51 | <wanderview> | I mean... we seem to have named our interface incorreclty |
| 20:52 | <wanderview> | was the interface named something else before? |
| 20:52 | <TabAtkins> | No? All three events share that interface. |
| 20:52 | <TabAtkins> | It's the event interface used for all the load events coming out of a fontfaceset |
| 20:53 | <wanderview> | TabAtkins: I mean... the spec references an interface named FontFaceSetLoadEvent... but gecko has a CSSFontFaceLoadEvent which seems a different interface name |
| 20:53 | <TabAtkins> | Ohhhhh |
| 20:53 | <TabAtkins> | See my earlier "I can't words today" |
| 20:53 | <wanderview> | I think its a gecko bug... but I guess I need to track down one of our font/css people |
| 20:54 | <wanderview> | who all seem to be out today |
| 20:54 | <TabAtkins> | I was seriously just auto-translating what you actually typed into what was in the spec. ^_^ |
| 20:54 | <TabAtkins> | Anyway, it might have been named that at some point? |
| 20:54 | <TabAtkins> | I can trawl history. |
| 20:54 | <wanderview> | TabAtkins: thanks, but I don't want to take your time for something that is our problem |
| 20:54 | <wanderview> | just thought you might know off the top of your head |
| 20:56 | <TabAtkins> | wanderview: Confirmed that it was renamed at some point; I just checked the oldest version in the repo and it has the name CSSFontFaceLoadEvent |
| 20:57 | <wanderview> | TabAtkins: thanks! |
| 20:57 | <TabAtkins> | wanderview: https://github.com/w3c/csswg-drafts/commit/48353a72f7bc4bb9cd91102f3a2ce25f7e73b669 |
| 20:58 | <wanderview> | awesome... over a year ago |
| 20:58 | <wanderview> | and we're about to ship the old name *facepalm* |
| 20:58 | <TabAtkins> | This is probably why I should write tests, if only I had time... |
| 21:03 | <wanderview> | filed a bug to get it fixed in gecko |
| 21:03 | <wanderview> | TabAtkins: thanks for your help! |
| 21:03 | <TabAtkins> | np |