| 00:10 | <caitp> | MikeSmith, yeah I'm working on that |
| 00:17 | <MikeSmith> | caitp: nice |
| 01:18 | <cvrebert> | Focus-on-click isn’t quite cross-platform/browser consistent :-( https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#Clicking_and_focus https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus |
| 01:18 | <MikeSmith> | |
| 01:19 | <MikeSmith> | oofs |
| 01:22 | <cvrebert> | MikeSmith: Ah, hello! Would you happen to know if there’s a reason why the CSS validator isn’t on GitHub? |
| 01:26 | <MikeSmith> | hey cvrebert |
| 01:26 | <MikeSmith> | dunno why not |
| 01:27 | MikeSmith | looks |
| 01:27 | <MikeSmith> | cvrebert: btw the CSS validator code is ancient crufty stuff. I really needs to be rewritten |
| 01:28 | <MikeSmith> | cvrebert: https://github.com/w3c/css-validator |
| 01:29 | <cvrebert> | MikeSmith: Ah, so http://jigsaw.w3.org/css-validator/about.html#code is just way outdated then |
| 01:29 | <MikeSmith> | ah yeah |
| 01:31 | <MikeSmith> | lemm see if I can redirect that |
| 01:32 | <cvrebert> | If http://www.w3.org/Bugs/Public/buglist.cgi?product=CSSValidator wasn’t an apparent blackhole, I would gladly file a bug about it.. |
| 01:34 | <MikeSmith> | cvrebert: yeah there's nobody been working the CSS validator code for quite a while now. It needs a new owner |
| 01:46 | <MikeSmith> | cvrebert: OK fwiw I just set up a redirect to github from that old "browse the code online" link |
| 01:47 | <cvrebert> | Progress! |
| 01:47 | <MikeSmith> | heh |
| 03:32 | <JonathanNeal> | It has taken me a while to realize that Chrome doesn’t use the fulfilled keyword to describe fulfilled promises, e.g. devtools showing me Promise {[[PromiseStatus]]: "resolved", [[PromiseValue]]: "p1-resolve-value"} |
| 03:32 | <JonathanNeal> | And I suppose it doesn’t matter, since it is internal. It was just throwing me off, as everywhere else there is no “resolved” state. |
| 03:33 | <caitp> | it just means it's fulfilled with a resolved value |
| 03:33 | <caitp> | slightly more specific than "fulfilled" |
| 03:34 | <caitp> | as opposed to fulfilled with a rejected value |
| 03:41 | <JonathanNeal> | caitp: hmm, but I thought that was called “settled” http://www.html5rocks.com/en/tutorials/es6/promises/ |
| 03:44 | <caitp> | hmm, yeah my lingo is probably out of date by now |
| 03:45 | <caitp> | > A promise is resolved if it is settled or if it has been "locked in" to match the state of another promise. Attempting to resolve or reject a resolved promise has no effect. A promise is unresolved if it is not resolved. An unresolved promise is always in the pending state. A resolved promise may be pending, fulfilled or rejected. |
| 03:46 | <caitp> | so in that sense, its pretty vague :p |
| 03:48 | <JonathanNeal> | “A promise is unresolved if it is not resolved” beautiful. |
| 03:53 | <JonathanNeal> | MikeSmith: are you keen on Promise lingo? |
| 03:56 | <JonathanNeal> | > The first argument fulfills the promise, the second argument rejects it — but the first argument is called resolve and the second argument is called reject. nonsense! |
| 04:28 | <MikeSmith> | JonathanNeal: keen on it? meaning, do I like it? |
| 04:28 | <JonathanNeal> | Can you explain the difference between fulfill, resolve, and reject as it relates to the status of promises and the methods we use to trigger them? |
| 04:31 | <JonathanNeal> | *as it relates to the states of a Promise, and as it relates to the arguments commonly described as triggering these states? |
| 04:32 | <JonathanNeal> | There’s another mark against the Chrome devtool report. It calls the state the PromiseStatus. |
| 04:33 | <caitp> | based on my reading of the spec I was just wrong before, although I could have sworn `fulfilled` had been used to mean any non-pending state before |
| 04:33 | <caitp> | maybe i |
| 04:33 | <caitp> | am just crazy |
| 04:33 | <caitp> | or human and misremembering :) |
| 04:34 | <caitp> | i guess domenic is probably sleeping by now but maybe he'd have something to say about it |
| 04:36 | <MikeSmith> | JonathanNeal: yeah Domenic would be the one to ask, if you want an insightful answer |
| 04:37 | <JonathanNeal> | I’m probably extra confused because the documentation is mixed up (or seems that way). MDN docs call something an “executor” when other docs call it a “resolver”, and Chrome calls something a “PromiseStatus” when other docs call it a “state”. Add that to “wait, does fulfill means it passed succesfully or just finished? or is that what |
| 04:38 | <JonathanNeal> | resolved means?” |
| 04:39 | <caitp> | status and state don't seem too bad to me :p arent they basically synonyms? |
| 04:39 | <JonathanNeal> | Thanks caitp, MikeSmith. Sorry if I sounded like a crazy person walking the streets pulling their hair |
| 04:40 | <MikeSmith> | heh, no worries |
| 04:40 | <JonathanNeal> | caitp: it doesn’t seem to bad until Chrome’s PromiseStatus returns something that is never referred to as a state, “resolved”. The only states are “pending”, “fulfilled”, and “rejected”. |
| 04:40 | <caitp> | if you sounded like a crazy person I'd be relieved i'm not the only one :p kidding kidding |
| 04:42 | <JonathanNeal> | So I’m just pretending that “resolved” means “not pending, either fulfilled or rejected”, and we should be writing promises like so, new Promise(function (fulfill, reject) { /* magic */ }); |
| 04:43 | <caitp> | i think you can pretty much write a promise however you want, the bindings don't matter much. but "resolve" and "reject" would be the common ones |
| 04:44 | <caitp> | most people aren't going to actually read the spec so it's only really going to matter what it means to them and their own vocabulary |
| 04:49 | <JonathanNeal> | caitp: yea, as long as they’re consistent, e.g. `.then(onResolved, onRejected)` or working alone. |
| 04:52 | <caitp> | you could call them \u1d19esolve if you wanted |
| 04:53 | <caitp> | people would be mad if you did, but you could do it |
| 04:55 | <JonathanNeal> | http://unicodesnowmanforyou.com/ |
| 04:56 | <caitp> | that is my new favourite codepoint |
| 08:44 | <MikeSmith> | caitp: ☃ |
| 09:09 | <annevk> | Hixie: it's editorial |
| 09:11 | <zcorpan> | i decided to check g+. latest news is annevk "Fullscreen for the web. Thoughts?" from Oct 15, 2011 |
| 09:11 | <annevk> | zcorpan: I'm still waiting :p |
| 09:12 | <zcorpan> | or it seems it's not the latest, just at the top |
| 11:26 | <JakeA> | annevk: so on "no-cors" vs "nocors", what's the precedent for nospacesorcamelcase? |
| 11:55 | <annevk> | JakeA: arraybuffer |
| 11:55 | <annevk> | JakeA: but I guess lowercase and sometimes a hyphen is fine |
| 11:57 | <jgraham> | So when does js get an enum type? :p |
| 12:03 | <Ms2ger> | annevk, if you're okay with my replies in https://critic.hoppipolla.co.uk/r/3127 , please resolve the issues :) |
| 12:26 | <annevk> | "Sign in" ugh |
| 12:26 | <annevk> | jgraham: could we do it in a IDL-compatible way? |
| 12:27 | <jgraham> | ? |
| 12:34 | <annevk> | jgraham: introduce actual enums that are compatible with IDL enums |
| 12:37 | <jgraham> | I don't know, but I would imagine so |
| 12:55 | <Ms2ger> | zcorpan, r? https://critic.hoppipolla.co.uk/r/3126 |
| 12:56 | <zcorpan> | Ms2ger: done |
| 12:57 | <Ms2ger> | Takk |
| 13:12 | <JakeA> | annevk: bit confused about https://github.com/slightlyoff/ServiceWorker/issues/560#issuecomment-62886149 - are you fine with the current model where security is based on the response? |
| 13:13 | <annevk> | JakeA: I think it is a fundamentally better model |
| 13:13 | <JakeA> | annevk: completely agree |
| 13:14 | <annevk> | JakeA: a synthetic response is never opaque so basically can always be read from |
| 13:14 | <annevk> | JakeA: so is basically always same-origin |
| 13:14 | <JakeA> | annevk: yep. The current model works fine. If we move to a redirect model it gets really confusing & full of exception cases |
| 13:16 | <JakeA> | annevk: ta. If moz see no benefit in this then that's all the more reason push back |
| 13:16 | <JakeA> | annevk: tbh I kinda wish CSP was response based too |
| 13:21 | <annevk> | JakeA: I think Mike West and I discussed this and found we needed to adjust CSP to check on both ends |
| 13:21 | <annevk> | JakeA: hasn't happened yet though |
| 13:21 | <JakeA> | annevk: yeah, I remember that, or have had a similar conversation myself |
| 13:21 | <annevk> | JakeA: there's also still some desire for strong coupling between request context and response |
| 13:22 | <annevk> | JakeA: so you can do fetch(... {context:"image"}) and the response object is tainted in such a way it can only be used in one place |
| 13:22 | <annevk> | JakeA: similar to what event.default() allows for, but with caching capabilities |
| 13:26 | <JakeA> | annevk: good for prioritisation too |
| 13:28 | <annevk> | JakeA: for the no CORS case however it does seem like changes are required for <img>, <script>, etc. |
| 13:28 | <annevk> | JakeA: which is probably why Chrome is hesitant and Firefox might be too |
| 13:28 | <JakeA> | annevk: how so? |
| 13:29 | <annevk> | JakeA: I guess this might be true for the CORS case as well, depending on how getRequestHeader() checks are implemented |
| 13:29 | <annevk> | JakeA: <img src/test> is no CORS, if it's same origin it's not opaque and you can paint and export from <canvas> |
| 13:29 | <annevk> | JakeA: if the SW returns a cross-origin images however, you should no longer be able to export from <canvas> |
| 13:30 | <JakeA> | annevk: right, so it's based on the taint flag of the response |
| 13:30 | <annevk> | JakeA: traditionally the browser would have noticed that as a redirect, but due to SW it won't and so might think it's same origin and still pain and export from <canvas> and have a security hole |
| 13:30 | <annevk> | paint* |
| 13:30 | <annevk> | I suspect that's the case they're worried about |
| 13:31 | <jgraham> | JakeA, annevk: Any opinions on https://critic.hoppipolla.co.uk/showfile?path=apisample16.html&review=2005&sha1=9d1f8984e3b37285f5d117a785b347a28d446006 ? |
| 13:32 | <jgraham> | Example test for service workers |
| 13:32 | <JakeA> | yeah, same goes for CSS DOM access |
| 13:32 | <jgraham> | Does it seem like a sane API? |
| 13:32 | <annevk> | There's a somewhat similar case with XHR and mode CORS; if the request URL was / but the response was actually CORS, would the browser let it read headers it is not allowed to? |
| 13:33 | <annevk> | Per Fetch with its internal response model and such it wouldn't... but... |
| 13:35 | <annevk> | jgraham: I like how you recreated callback-hell with promises |
| 13:36 | <JakeA> | jgraham: can you have asserts within a promise test? |
| 13:37 | <jgraham> | annevk: *I* didn't do anything |
| 13:37 | <annevk> | jgraham: I don't see anything obviously wrong, but you really want JakeA's opinion here |
| 13:38 | <jgraham> | i.e. I didn't create this API, I'm just reviewing it |
| 13:38 | <jgraham> | Which is difficult… |
| 13:39 | <jgraham> | JakeA: Yeah, so see https://critic.hoppipolla.co.uk/showfile?path=apisample13.html&review=2005&sha1=9d1f8984e3b37285f5d117a785b347a28d446006 for examples of the promise_test function |
| 13:39 | <JakeA> | jgraham: what am I reviewing here? Am I reviewing correct use of ServiceWorker or use of promise_test? |
| 13:39 | <jgraham> | annevk: Although of course the original design of testharness.js is my fault and might not be what you would design today |
| 13:40 | <jgraham> | JakeA: Both of those sound useful. Also if this seems like it's going to be a sane foundation for writing promise/service-worker based tests in the future |
| 13:41 | <jgraham> | JakeA: The top level review is https://critic.hoppipolla.co.uk/r/2005 if you want more context |
| 13:41 | <JakeA> | Gotcha, cheers! |
| 13:43 | <annevk> | jgraham: why when under commits I click [full] do I have to confirm again I want to see everything? |
| 13:44 | <jgraham> | annevk: Ask jl :p But I think the idea is that [Full] means "fully squashed", but you still might not want to see every file |
| 13:44 | <annevk> | jgraham: is it not jw now? |
| 13:45 | <zcorpan> | nope |
| 13:47 | <jgraham> | Some things change, some stay the same |
| 13:51 | <JakeA> | jgraham: SW code looks solid. Had to double check updatefound always fires after register resolves, which is does. How does fetch_tests_from_worker work? |
| 13:57 | <zcorpan> | i haven't looked at the SW thing, but how does it relate to https://critic.hoppipolla.co.uk/r/1996 ? |
| 13:59 | <jgraham> | JakeA: I haven't reviewed all the implementation details, but the basic idea is that test objects in the worker send their results to the main window over message ports. fetch_tests_from_worker sets up that machinary. |
| 14:00 | <JakeA> | makes sense |
| 14:00 | <jgraham> | zcorpan: Interesting question. I think the answer is that it replaces it, although there are some ideas there which could perhaps be ported to this new scheme |
| 14:00 | <annevk> | jgraham: that setup might not work if the SW is just servicing a worker |
| 14:01 | <annevk> | (everyone always forgets about that case :( ) |
| 14:01 | <annevk> | (I suspect it'll be buggy as hell) |
| 14:01 | <jgraham> | annevk: Interesting. So is the setup window -> worker -> service worker? Or is there no window at all? |
| 14:02 | <annevk> | jgraham: there's likely a window |
| 14:02 | <jgraham> | "likely"? |
| 14:02 | <annevk> | jgraham: there's some not well defined exception for SharedWorker where when you navigate it may or may not be associated with something |
| 14:03 | <annevk> | jgraham: but the more important point is that a SW can service a worker without servicing that worker's window |
| 14:03 | <jgraham> | OK, it seems like a solvable problem, as long as there is actually a Window somewhere |
| 14:04 | <jgraham> | Because the worker can pass the result messages up to the Window |
| 14:04 | <annevk> | in the shared worker navigate case you could prolly test that with a nested browsing context that navigates and the top-level negotiating all the details... |
| 14:04 | <annevk> | although that way you'd never test the top-level... |
| 14:06 | <jgraham> | JakeA: Thanks for your help |
| 14:06 | <JakeA> | no worries |
| 15:27 | <wanderview> | JakeA: sorry for issue 550 :-\ |
| 15:27 | <JakeA> | wanderview: ALL YOUR FAULT :D |
| 15:28 | <JakeA> | Labouring over a reply, don't know what to think anymore |
| 15:28 | <wanderview> | JakeA: at this point I don't know if a change is possible given ship dates, etc |
| 15:28 | <wanderview> | or desirable |
| 15:28 | <JakeA> | wanderview: do you still think they're useful for responses? |
| 15:28 | <wanderview> | JakeA: are what still useful? |
| 15:29 | <JakeA> | wanderview: consuming by default |
| 15:30 | <JakeA> | wanderview: If we shipped with .clone, we could make it a no-op the next version, eventually deprecate it. I'm not too worried there |
| 15:30 | <JakeA> | I guess it's useless for requests because they're buffered by default anyway because of redirects within fetch |
| 15:30 | <wanderview> | JakeA: so to be clear... I was thinking leave .clone() in place, but say fetch() and cache.put() automatically call it for you |
| 15:31 | <wanderview> | so content can still clone() in order to call the stream helpers multiple times |
| 15:31 | <JakeA> | (although if you were streaming a video, you'd want to avoid buffering the body even for fetch, but as annevk said that would be optional) |
| 15:32 | <wanderview> | JakeA: also, fetch() and cache.put() would still reject if the body was already consumed by something else when the auto-clone() was attempted |
| 15:32 | <JakeA> | wanderview: So if I'm storing a 1gb movie into the cache, but also sending to the browser, is auto-clone a problem? |
| 15:32 | <wanderview> | JakeA: maybe we leave it with clone() for now and then deprecate as you say later if developers complain |
| 15:33 | <wanderview> | JakeA: well, content would have to call clone() anyway, right? |
| 15:33 | <wanderview> | same effect |
| 15:33 | <JakeA> | In the current model I'd clone the version going to the browser but use the main one for the cache, so there'd only be buffering if the browser/cache consumed slower than the other |
| 15:34 | <JakeA> | If I cloned both, there's now an additional response object that *could* have its body read from the start |
| 15:34 | <wanderview> | hmm |
| 15:34 | <wanderview> | everything is terrible |
| 15:34 | <wanderview> | JakeA: yea, I see your point |
| 15:34 | <JakeA> | A super-smart implementation could go "oh, I'm saving this to cache, so I guess I can get it from there if I need to read-from-start" |
| 15:35 | <wanderview> | JakeA: I think that is made more difficult by the "only goes in cache when its fully consumed" semantics |
| 15:35 | <wanderview> | or fully loaded |
| 15:35 | <JakeA> | Or alternately "this is big so I'm going to buffer on disk rather than memory". But I guess a disk buffer of 1gb + a cache of 1gb is still a problem |
| 15:35 | <JakeA> | wanderview: I'm interested in changing that |
| 15:36 | <JakeA> | Or at least having it as a .match option |
| 15:36 | <wanderview> | JakeA: I think you have convinced me that we should leave explicit clone as is for v1... and we can introduce auto-clone in the future |
| 15:36 | <wanderview> | if the API is too clunky |
| 15:36 | <JakeA> | Glad I convinced you. I haven't convinced me :D |
| 15:36 | <JakeA> | But yeah, it's bad options all around |
| 15:37 | <JakeA> | We shouldn't feel bad about it, even when we reached out to devs for opinion they were split down the middle |
| 15:37 | <wanderview> | JakeA: well, its unclear which is best... but if I understand correctly blink wants to ship soon, so favoring no changes seems better... and we have a path to switch in this direction |
| 15:37 | <JakeA> | As you say, it's easier to go from manual clone to auto clone than the other way around |
| 15:37 | <JakeA> | yep |
| 15:37 | <wanderview> | JakeA: if we go with auto-clone now, we can't switch to explicit clone later |
| 15:37 | <wanderview> | yea |
| 15:38 | <JakeA> | I'll write this up on the ticket |
| 15:38 | <wanderview> | JakeA: thank you! |
| 15:38 | <wanderview> | sorry for my confusion/waffling |
| 15:38 | <wanderview> | I didn't get much sleep last night |
| 15:38 | <JakeA> | Me neither so we're probably both talking nonsense |
| 15:39 | <wanderview> | perfect... ship it! |
| 15:39 | wanderview | goes to get more coffee... |
| 15:41 | <annevk> | JakeA: I like the auto-clone from wanderview |
| 15:41 | <annevk> | JakeA: and then have an option for these cases to not do it, just as we plan for redirects/failure |
| 15:42 | <annevk> | JakeA: having said that, cache.match() prolly doesn't need it since you never need to look at the body there |
| 15:42 | <annevk> | JakeA: so it would only be for cache.put() and we could require .clone() for that, seems somewhat reasonable? |
| 15:45 | <JakeA> | annevk: .match doesn't consume body |
| 15:45 | annevk | read up on the issue debate |
| 15:45 | <JakeA> | annevk: See the chat between wanderview & I from 15:27 ^^ |
| 15:46 | <JakeA> | Although I'm currently writing a summary |
| 15:47 | <wanderview> | annevk: JakeA talked my off the auto-clone ledge |
| 15:47 | <annevk> | JakeA: I think the pesky thing with all of this is that we already have auto-clone |
| 15:47 | <wanderview> | ^my^me |
| 15:48 | <wanderview> | annevk: we do? |
| 15:48 | <annevk> | JakeA: the 10GiB resource case requires a new feature already |
| 15:48 | <annevk> | wanderview: yes, Fetch does it |
| 15:48 | <annevk> | wanderview: so if you hit a redirect or authentication dialog, you can resubmit the body |
| 15:48 | <wanderview> | annevk: but thats not on content observable objects, right? |
| 15:48 | <wanderview> | from contents perspective it made one call |
| 15:48 | <annevk> | wanderview: yes |
| 15:49 | <annevk> | wanderview: but content might not like the memory bloat if it deals with something large |
| 15:49 | <wanderview> | to me that seems a consequence of implementing redirects... developers can choose not to host huge things behind redirects |
| 15:50 | <annevk> | wanderview: the problem is that you need to clone before you even know there is a redirect |
| 15:50 | <wanderview> | true |
| 15:50 | <annevk> | wanderview: you always need to clone, for every fetch |
| 15:50 | <annevk> | wanderview: and potentially multiple times if there's a redirect chain (pathological case) |
| 15:51 | <wanderview> | I go back to me "everything is terrible" statement |
| 15:51 | <wanderview> | ^me^my |
| 15:51 | wanderview | can't type today. |
| 15:51 | <annevk> | Is that part of a new Lego movie? |
| 15:52 | <annevk> | This is why shipping early for something so big is a mistake, I don't think we've had sufficient iteration :-( |
| 15:52 | annevk | is away for a bit |
| 15:52 | <wanderview> | annevk: given that we can introduce auto-clone for cache later, but not the other way around... I'm inclined to stick with explicit clone() for now |
| 15:56 | <JakeA> | annevk: wanderview: summary at https://github.com/slightlyoff/ServiceWorker/issues/550#issuecomment-62913664 |
| 15:57 | <JakeA> | I get the "not enough iteration" thing, but also we could sit on this for years and improve it in small ways and not actually benefit the web because it isn't in browsers. |
| 15:57 | <JakeA> | I guess the question is have we had enough iteration to be out of the danger zone |
| 15:58 | <wanderview> | thanks! |
| 15:58 | <wanderview> | JakeA: back to that original issue's question, though... I still think maybe we should not reject/mark used if there is no body... what do you think? |
| 15:59 | <wanderview> | since there may be cases where content knows a request has no body, etc... var reusableRequest = new Request('./my/url') |
| 16:21 | <JakeA> | wanderview: no strong opinion (as I'd always clone for safety). |
| 16:21 | <wanderview> | k |
| 16:24 | <JakeA> | wanderview: tempted to say consume for the consistency |
| 16:24 | <JakeA> | But can be easily swayed |
| 16:25 | <wanderview> | JakeA: the thing that made me think of this was the blink cache tests... they create an array of Request/Response pairs and then populate a cache for each test case... seemed silly to require a clone for all these requests with no body |
| 16:26 | <wanderview> | JakeA: like this: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/cache-match-worker.js |
| 16:29 | <JakeA> | Hmm true. Will ask a few people what they think, but yeah, no strong opinion |
| 16:35 | <wanderview> | thanks |
| 16:35 | wanderview | lunches |
| 16:43 | <annevk> | "Tab Many Cooks™" heh |
| 16:44 | <annevk> | I wonder what meme I missed that makes people routinely change their names on Twitter |
| 16:47 | <tantek> | annevk - it's particularly funny if you retweet a lot - because twitter doesn't show your @-name if you retweeted something, just retweeted by "long form name" |
| 16:47 | <tantek> | pretty sure that's why people do it |
| 18:01 | <TabAtkins> | tantek: Nah, I just do it because it's funny. |
| 18:02 | <JakeA> | I've almost tweeted "not cool enough to change my Twitter name daily" but worried people will think it's a dig |
| 18:02 | <JakeA> | which to be fair, it is |
| 18:02 | <TabAtkins> | annevk: The Halloween twittername meme finally got big this year. I've been doing it the last 3 years. |
| 18:02 | <TabAtkins> | Jenn Schiffer changes her display name every week or so. |
| 18:02 | <TabAtkins> | There's a Twitter bot (@js_usernames) that tweets her name changes, in case you miss it. ^_^ |
| 18:06 | <TabAtkins> | caitp: You have the terminology wrong. "resolved" vs "unresolved" are fates - a promise is "resolved" if it's fulfilled, rejected, or slaved to another promise; it means that whatever's going to happen to it is already decided, and can't be changed by more calls to the resolver functions. "fulfilled", "rejected", and "pending" are mutually-exclusive states |
| 18:06 | <TabAtkins> | that a promise can be in. |
| 18:06 | <caitp> | didn't we cover this last night? :p |
| 18:07 | <TabAtkins> | I'ts possible - I was skimming scrollback and saw you talking with JonathanNeal about it. If you were corrected, sorry, I missed it. |
| 18:08 | <JonathanNeal> | I didn’t correct anybody. I was and am still a little lost. I hope I didn’t sound like I was correcting anyone. |
| 18:09 | <JonathanNeal> | but your bit of explanation did help, TabAtkins |
| 18:09 | <TabAtkins> | Cool. |
| 18:10 | <TabAtkins> | "resolved" and "unresolved" just mean "can I still call resolve()/reject() or not". |
| 18:10 | <TabAtkins> | (I mean, you can always call them. It's just a no-op if the promise is already resolved.) |
| 18:11 | <caitp> | i corrected myself |
| 18:12 | <TabAtkins> | caitp: All right, sorry for the noise then. ^_^ |
| 19:00 | <caitp> | is there any way in IDL to specify if an attribute is supposed to be enumerable or not? are IDL properties supposed to be "own" properties, or do they live on the interface prototype? |
| 19:01 | <caitp> | *confused* |
| 19:04 | <smaug____> | caitp: attributes are getters/setters in the prototype |
| 19:05 | <smaug____> | (by default) |
| 19:07 | <smaug____> | caitp: http://heycam.github.io/webidl/#es-attributes |
| 19:08 | <caitp> | seems like blink is doing something wrong here then |
| 19:08 | <caitp> | i don't think that's really surprising though |
| 19:08 | <caitp> | i recall this was a known bug |
| 19:08 | <smaug____> | yes, blink is doing all wrong with attributes |
| 19:08 | <caitp> | blink doing wrong thing -> bug gets filed on us because safari (and firefox) do it differently and correctly ;) |
| 19:09 | <smaug____> | hmm, I thought webkit had the same behavior as blink still |
| 19:09 | <caitp> | can't make everyone happy I guess |
| 19:09 | <TabAtkins> | Blink has been trying for a while to get things fixed, but micro-benchmarks that regress when we do keep stopping us. We keep trying, though! |
| 19:11 | <caitp> | but these properties should be enumerable though right? |
| 19:11 | <caitp> | or is that not the case |
| 19:11 | <TabAtkins> | I don't think they're enumerable normally? |
| 19:11 | <caitp> | hm |
| 19:15 | <caitp> | *WONTFIX-es bug :3* |
| 19:15 | <caitp> | that is so satisfying |
| 19:15 | <smaug____> | " The property has attributes { [[Get]]: G, [[Set]]: S, [[Enumerable]]: true, [[Configurable]]: configurable }, where" ... |
| 21:27 | <afa> | crazy thought. so far as i know, there's no way to transition position, but it's something i find myself wanting to do all the time (e.g. let the browser calculate the position of an item in a list, but let me tell that item to move to a fixed position when the user interacts with it) |
| 21:28 | <afa> | it's something that you could carefully fake with JavaScript (though I'm always skeptical of the performance implications of scripting animation in JS) |
| 21:28 | <TabAtkins> | afa: This was the idea of "layout transitions" that I've been noodling on for a year or two. |
| 21:28 | <afa> | but given that the charter of the standards bodies seems to be "pave the cowpaths", how crazy would it be to come up with a spec for transitioning on position |
| 21:29 | <afa> | TabAtkins: good. i can't imagine this is a novel idea |
| 21:29 | <TabAtkins> | Turns out to be too hard to do in purely-declarative syntax to be worth it, but we've come up with some tools that make the JS side way easier to work with. |
| 21:29 | <afa> | i'm often surprised at how many things that you intuitively want to do take a shitton of work to implement in browser |
| 21:29 | <afa> | TabAtkins: anythign i should be looking at? |
| 21:29 | <TabAtkins> | Yup, there's often a huge cliff you have to fall off before you reach something you can actually tweak. The EWM is about reducing that. |
| 21:30 | <afa> | EWM? |
| 21:30 | <TabAtkins> | afa: Nah, dont' have anything written up publicly. Just ideas thrown around with my fellow implementors. |
| 21:30 | <TabAtkins> | Extensible Web Manifesto. |
| 21:31 | <afa> | thanks |
| 21:31 | <afa> | TabAtkins: nothing you've written up publicly, but any "tools that make the JS side easier to work with"? |
| 21:32 | <TabAtkins> | I'm referring to APIs we'd build into the browser for it, such as giving the ability to stop an element from painting, and take "snapshots" of an element for doing animations with. |
| 21:32 | <afa> | whenever i have to calculate the fixed position of an asset my rolling up all its relative positions inside scroll panes, that feels super brittle |
| 21:33 | <afa> | i'd love to be able to say "you know where you are, now just transition over to here (in fixed/viewport space)" |
| 21:34 | <roc> | getBoundingClientRect should give you that |
| 21:35 | <TabAtkins> | roc: That doesn't give you useful coordinates to use to tell it to transition to. |
| 21:35 | <TabAtkins> | But your geometry extensions would. |
| 21:35 | <TabAtkins> | Since you can translate a screen-space point into an element-space point. |
| 21:35 | <TabAtkins> | (I can't find those, btw - did they ever make it into a spec?) |
| 21:35 | <roc> | ah |
| 21:36 | <roc> | yes and no. The IDL is in CSSOM-views: http://dev.w3.org/csswg/cssom-view/#the-geometryutils-interface |
| 21:36 | <roc> | unfortunately Simon hasn't gotten around to writing the actual text |
| 21:37 | <roc> | in the meantime we have shipped it :-/ |
| 21:37 | <TabAtkins> | Yay! |
| 21:37 | <roc> | I don't feel too bad about it since we actually agreed on the list how they should work |
| 21:37 | <roc> | but we do need the text |
| 21:39 | roc | emails Simon |
| 21:44 | <afa> | https://hacks.mozilla.org/2014/03/introducing-the-getboxquads-api/ |
| 21:45 | <afa> | thanks roc and TabAtkins |