| 06:13 | <Domenic> | philipj: are you hoping to finish up HTMLMediaElement.prototype.play() soon? |
| 06:19 | <philipj> | Domenic: yep, was planning to keep hammering at it today. the error handling situation is a bit of a mess, though |
| 06:20 | <philipj> | as in, a decode error is the reason that currentTime won't be progressing, but paused is still false, and if you seek to elsewhere, we'll start playing |
| 06:21 | <Domenic> | I tend to think getting something in sooner would be nice, and straighten out the problems later, but happy to leave that up to you |
| 06:30 | <philipj> | Domenic: I'll comment on the issue before OED |
| 06:30 | <philipj> | EOD |
| 08:09 | <botie> | Ms2ger, at 2016-01-29 22:58 UTC, miketaylr said: we have some reftests in moz-central, but no wpt yet for webkitcssmatrix -- i have plans to work on that (it's unclear if we can just port Apple's, IANAL). also on PTO until tuesday, but probably will end up on irc at some point between now and then and at |
| 08:09 | <botie> | 2016-01-29 23:01 UTC, miketaylr said: s/reftests/mochitests/ |
| 10:56 | <philipj> | Domenic: if you want to review https://github.com/foolip/html/commits/play-promise-tinkering that'd be nice |
| 12:29 | <annevk> | FWIW: https://blog.whatwg.org/github |
| 12:30 | <annevk> | wanderview: JakeA: any ETA on that review? |
| 12:34 | <JakeA> | annevk: aiming for today. First day back, got some meetings, then I can do real stuff |
| 12:34 | <JakeA> | Sorry it's taken so long :( |
| 12:35 | <annevk> | It's cool, just trying to figure out what I should work on |
| 14:18 | <MikeSmith> | wanderview: http://stackoverflow.com/questions/35125710/gcm-equivalent-for-firefox "Can Firefox Browser Extensions interact with service workers?" |
| 14:19 | <wanderview> | MikeSmith: currently, extensions cannot us service workers directly |
| 14:19 | <MikeSmith> | wanderview: OK, I think the same is also true of Chrome extensions |
| 14:20 | <wanderview> | MikeSmith: I thought they did allow them to interact in some way |
| 14:20 | <wanderview> | but JakeA would know better |
| 14:20 | <MikeSmith> | ah OK |
| 14:21 | <smaug____> | I'm all for https://github.com/whatwg/dom/pull/120 (note, github UI really sucks. random discussions in pull requests or in issues or elsewhere), but does anyone recall why we originally added DOMTokenList and DOMSettableTokenList |
| 14:22 | <nox> | smaug____: Would using Reviewable help? |
| 14:22 | <Ms2ger> | smaug____, I guess because className already existed? |
| 14:22 | <nox> | className? |
| 14:22 | <smaug____> | Ms2ger: but why those two interfaces ? |
| 14:23 | <Ms2ger> | Not sure |
| 14:23 | <Ms2ger> | I think Hixie was rather more fond of PutForwards than everyone else |
| 14:24 | <smaug____> | oh, sure, I have PutForwards. horrible horrible thing. But that doesn't still explain why we needed two interfaces |
| 14:24 | <smaug____> | s/have/hate/ |
| 14:37 | <wanderview> | roc: I was just expressing a personal opinion... I don't think anyone has said sql is actually happening |
| 14:42 | <nox> | What's horrible about PutForwards? |
| 15:00 | <annevk> | nox: I think some people don't like that you can set a property to more values than it returns |
| 15:00 | <nox> | More values than it returns? |
| 15:00 | <annevk> | More value types, or really a different type I suppose in most cases |
| 15:01 | <nox> | Oh I see. |
| 15:11 | <smaug____> | no foolip |
| 15:12 | <smaug____> | philipj perhaps? |
| 15:12 | <philipj> | smaug____: yes, I'm philipj here because I'm also on #blink |
| 15:12 | <smaug____> | oh, nm, this is old test. I thought you had written, but no |
| 15:13 | <smaug____> | https://github.com/w3c/web-platform-tests/blob/master/html/semantics/embedded-content/the-canvas-element/2d.getcontext.extraargs.html#L22 |
| 15:13 | <smaug____> | which is very much against the current spec |
| 15:13 | <Ms2ger> | Yeah, that'd be Philip` |
| 15:13 | <philipj> | smaug____: nope, I haven't written any canvas tests :) |
| 15:13 | <smaug____> | browser handle the params to getContext in various different ways |
| 15:14 | <philipj> | smaug____: yes, did you see https://github.com/whatwg/html/issues/595 ? |
| 15:15 | <smaug____> | I did |
| 15:15 | <smaug____> | oh, not the latest comments there |
| 15:17 | <JakeA> | MikeSmith: our plan is to move away from background pages and instead to service workers |
| 15:18 | <MikeSmith> | JakeA: oh, didn't actually know that background pages were still a thing. (I've never actually written a Chrome extension.) |
| 15:18 | <smaug____> | how do I quote someone in github comments? |
| 15:19 | <MikeSmith> | smaug____: select that you want to quote and type "r" |
| 15:20 | <MikeSmith> | or just manually copy-paste it and prefix it with ">" (as in e-mail or whatever) |
| 15:21 | <annevk> | play() \o/ |
| 15:21 | <smaug____> | r |
| 15:21 | <smaug____> | what does that r mean |
| 15:21 | <ondras> | "r"eply |
| 15:21 | <smaug____> | ahaa |
| 15:21 | ondras | guesses |
| 15:31 | <JakeA> | annevk: While I remember, here's me explaining why scoped stylesheets aren't often useful for progressive rendering as CSS loads https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303#c36 |
| 15:33 | <annevk> | JakeA: ta, https://github.com/whatwg/html/issues/552#issuecomment-178022424 |
| 15:33 | <JakeA> | annevk: and our intent to implement parser blocking on <link> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZAPP8aTnyn0 |
| 15:34 | <JakeA> | um, link[rel=stylesheet] specifically |
| 16:06 | <annevk> | Domenic: so reviewing the internal method stuff a bit closer, I think the recursive property lookup fault is in quite a few places |
| 16:07 | <annevk> | Domenic: so I guess the GetOwnProperty stuff needs to be more complicated |
| 16:08 | <annevk> | Although I guess browsers do expose them as own properties so something needs changing there somehow |
| 16:10 | <annevk> | *sigh* |
| 16:21 | <Domenic> | annevk: "recursive property lookup fault"? |
| 16:21 | <Domenic> | Note that GOP is *own* only so it shouldn't go up the prototype chain |
| 16:21 | <annevk> | Domenic: right, that's the problem |
| 16:21 | <annevk> | Domenic: most of the properties will be defined on the prototype |
| 16:22 | <annevk> | Domenic: although I think in the cross-origin case we pretend they're on the object |
| 16:22 | <annevk> | Domenic: but we still need to get the actual function (that we then wrap) from the prototype |
| 16:22 | <Domenic> | hmm i see |
| 16:22 | <annevk> | Domenic: that we also overwrite [[GetPRototypeOf]] and need to undo that temporarily makes this even trickier |
| 16:23 | <Domenic> | What is a concrete example of where this is a problem? |
| 16:24 | <annevk> | Domenic: crossOriginLocation.href = "x" |
| 16:24 | <annevk> | Domenic: I don't think we'll ever find "href" with the current set of definitions |
| 16:24 | <Domenic> | hmm |
| 16:24 | <Domenic> | tracing |
| 16:25 | <Domenic> | "Return CrossOriginSet(this, W, P, V, Receiver)" what is W? |
| 16:25 | <annevk> | And similar for window. console.log(crossOriginWindow.closed) |
| 16:25 | <annevk> | Domenic: the Window object |
| 16:25 | <Domenic> | I see, defined non-locally |
| 16:25 | <annevk> | I copied that from your window-proxy thing, happy to change |
| 16:26 | <Domenic> | Huh yeah I wonder why I did that |
| 16:26 | <Domenic> | Probably best to inline the step let W be ... in each |
| 16:26 | <annevk> | I'll file an issue, feel too tired to work on this |
| 16:27 | annevk | tries to write a summary of the custom elements and service workers stuff |
| 16:27 | annevk | ends up writing about rniwa's ability to estimate how much gas there is beyond 0 |
| 16:27 | <Domenic> | I'm confused why CrossOriginSet step 2 looks at O |
| 16:27 | <Domenic> | isn't O the proxy itself? |
| 16:28 | <Domenic> | So that will just recurse infinitely |
| 16:28 | <annevk> | Domenic: it does that to take into account the limitations set by the proxy |
| 16:28 | <Domenic> | but it's still an infinite loop |
| 16:29 | <annevk> | GetOwnProperty at some point invokes the W variant, no? |
| 16:29 | <Domenic> | Only if IsSameOrigin |
| 16:30 | <Domenic> | Oh wait |
| 16:30 | <annevk> | Yeah, the O there is W |
| 16:30 | <Domenic> | I see, nevermind |
| 16:30 | <annevk> | little confusing I guess |
| 16:42 | <Krinkle> | Hm.. how is showNotification() a storage API? |
| 16:42 | <Krinkle> | https://storage.spec.whatwg.org/#introduction |
| 16:42 | Krinkle | is ready for a horrible hack |
| 16:43 | <Domenic> | Krinkle: notification tags can store like 640k of data I believe |
| 16:43 | <Krinkle> | And they can be retrieved? |
| 16:43 | <Domenic> | not sure... they can certainly be stored |
| 16:44 | <Domenic> | getNotifications |
| 16:44 | <Krinkle> | So one would presumably store an unshown notif with data |
| 16:44 | <Domenic> | maybe it's a tag => title map |
| 16:44 | <Krinkle> | omg |
| 16:44 | <Krinkle> | Neat |
| 16:47 | <annevk> | They have a data member that basically takes a structured cloneable |
| 16:47 | <annevk> | clonable? |
| 17:03 | <JakeA> | annevk: irccloud isn't giving me enough context, can you throw me that review link again? |
| 17:03 | <annevk> | Apparently https://github.com/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+bug%22+user%3Awhatwg is a 404 if you're not logged into GitHub? |
| 17:03 | <annevk> | JakeA: https://github.com/whatwg/fetch/pull/194 |
| 17:03 | <JakeA> | ta |
| 17:04 | <Domenic> | annevk: it might be a 404 for anyone not in the org.... |
| 17:06 | <Domenic> | i made all the labels light green |
| 17:07 | <annevk> | Domenic: oooh that would suck |
| 17:08 | <annevk> | Domenic: would https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22good+first+bug%22+whatwg work better? |
| 17:09 | <annevk> | Someone here not in the WHATWG org that could check these links? |
| 17:09 | <Domenic> | annevk: that loses a few bugs, i wonder why |
| 17:10 | <annevk> | org:whatwg seems to put them back |
| 17:10 | <annevk> | Anyway, we need an outsider to help |
| 17:14 | <nox> | annevk: Checking in another channel. |
| 17:15 | <nox> | annevk: Not 404. |
| 17:15 | <nox> | GH bug it seems. |
| 17:17 | <annevk> | ok |
| 18:59 | <JakeA> | annevk: request's redirect mode is not "manual" and response's type is "opaqueredirect" …network error - out of curiosity, why is this? |
| 19:02 | <wanderview> | JakeA: it used to say if request is not a navigation and response type i opaqueredirect... he changed it to reference manual so it worked for fetch() with manual mode |
| 19:03 | <JakeA> | wanderview: but returning a Response.redirect(…) is fine, so I'm trying to figure out why allowing an opaque response isn't |
| 19:04 | <wanderview> | I don't know |
| 19:18 | <annevk> | JakeA: unclear how that should work without revealing stuff to the SW |
| 19:18 | <annevk> | Very different from synthetic case |
| 19:21 | <JakeA> | annevk: I suppose the skip-service-worker flag could be set, but it's not clear what the benefit would be. |
| 19:21 | <JakeA> | Ta! |
| 20:02 | <Philip`_> | smaug____: If I wrote incorrect canvas tests nine years ago, please feel free to fix them :-) |
| 20:05 | <smaug____> | Philip`_: (hmm, I use ` super rarely on Finnish keyboard ;)) this is about https://github.com/whatwg/html/issues/595 and https://bugzilla.mozilla.org/show_bug.cgi?id=1244480 and https://codereview.chromium.org/795833004 |
| 20:06 | <smaug____> | trying to figure out why such test was ever added |
| 20:14 | <Philip`_> | smaug____: Between February 2010 and September 2010, the spec changed to say about getContext('2d'): "Any additional arguments are ignored" |
| 20:14 | <Philip`_> | smaug____: so I added the test for that |
| 20:16 | <smaug____> | Philip`_: do you happen to know why the "any additional arguments are ignored" was added? |
| 20:16 | <smaug____> | then then I now wonder why it was removed |
| 20:17 | <smaug____> | since the current spec requires different behavior |
| 20:21 | <Philip`_> | smaug____: I can probably find some clues in a git blame on the spec, but it's taking a while to run... |
| 20:21 | <Philip`_> | smaug____: That old text is still in https://www.w3.org/TR/2dcontext/ , by the way |
| 20:32 | <Domenic> | Is anyone else seeing wattsi-server slowdowns? Especially for the second request? |
| 20:32 | <Philip`_> | smaug____: https://github.com/whatwg/html/commit/5c67e57237723708e5a70e06dbf6da0d4f659600/source - hmm, not actually that helpful |
| 20:32 | <smaug____> | Philip`_: do you happen to recall why "Any additional arguments are ignored." was added? |
| 20:33 | <smaug____> | ah, that |
| 20:33 | <Philip`_> | smaug____: If I remember correctly, WebIDL said that extra arguments to a function without "any..." would get ignored, so that phrase was just clarifying that the behaviour would stay the same after that commit added the "any..." |
| 20:34 | <Philip`_> | smaug____: Maybe WebGL wanted support for extra getContext arguments, which is why the "any..." was added? (but 2d didn't need to use them) |
| 20:35 | <smaug____> | perhaps that |
| 20:35 | <smaug____> | and when 2d started to use 2nd argument too, the spec was changed |
| 20:35 | <smaug____> | but test wasn't updated |
| 20:36 | <Philip`_> | smaug____: I have very vague memories that that test always failed in Firefox because it had some proprietary extension using the second argument |
| 20:37 | Philip`_ | could be totally wrong though, it was a long time ago :-p |
| 20:38 | <smaug____> | it wasn't failing until I made the Gecko to follow the spec |
| 20:38 | <smaug____> | perhaps it was failing long ago though |
| 20:40 | <smaug____> | but now I'm trying to figure out what the spec should say, or whether spec is actually just fine and some browsers need to update their implementation |
| 20:40 | <Philip`_> | Ah, probably more likely that I'm just totally wrong |
| 20:42 | Philip`_ | no longer has any opinions on spec design |
| 21:04 | <gsnedders> | Philip`_: pff, you should go back to having opinions! |
| 21:10 | <Philip`_> | gsnedders: I suspect I'd first have to catch up with years of politics to even understand how many versions of specs there are to have opinions on, and that sounds like hard work |
| 21:23 | <gsnedders> | Philip`_: I reappeared and it went okay. |
| 21:51 | <jgraham> | https://tech.ebu.ch/news/2016/01/timed-text-subtitling-receives-e |
| 21:51 | <jgraham> | Mainly for the picture |
| 22:34 | <jsbell> | wanderview: can I pester you for some cache and indexeddb w-p-t reviews on critic? (not urgent but they've been lingering since december |
| 22:34 | <wanderview> | jsbell: yea, on my todo list... but I've been on PTO / dealing with moving my family... hope to get to it this week |
| 22:34 | <jsbell> | wanderview: thx! |
| 22:35 | <wanderview> | jsbell: one thought I had today is I should review that before switching our .add() and .addAll() to fail on !response.ok() |
| 22:35 | <wanderview> | since that will surely change the tests |
| 22:36 | wanderview | goes to dinner... |
| 22:39 | <zcorpan> | https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZAPP8aTnyn0 seems radical, and not how i had envisioned how it would work |
| 22:40 | <zcorpan> | i thought we would want to block the parser as little as possible |
| 22:41 | <zcorpan> | Does Edge really block the parser for external CSS? |
| 22:42 | <JakeA> | zcorpan: it blocks rendering, not sure if it blocks parsing |
| 22:43 | <zcorpan> | JakeA: ok. it should be possible to execute scripts with setTimeout to be able to tell the difference here |
| 22:44 | <zcorpan> | JakeA: and if it doesn't block parsing, would be interesting to know if it blocks layout or painting (though not sure how to test that) |
| 22:45 | <zcorpan> | i suppose it would need to block layout in order to not mess up earlier content (e.g. if you have a table and link to a stylesheet in the middle) |
| 22:46 | <zcorpan> | which is a way to test it, come to think of it |
| 22:47 | <JakeA> | zcorpan: doing layout seems pointless if there's a loading stylesheet which is likely to impact all of that |
| 22:48 | <zcorpan> | JakeA: yes |
| 22:48 | <JakeA> | I guess parsing could continue though. Mutation observers would be a good way to test too |
| 22:52 | <zcorpan> | yeah |
| 22:53 | <zcorpan> | it seems useful to evaluate the pros and cons of blocking parsing though. a big pro i assume is that it makes the architecture simpler, but it seems to me there may be many cases where it'll hurt perf |
| 22:55 | <zcorpan> | e.g. a page that has <script async><link rel=stylesheet><video src=x preload> means the video starts to load later |
| 22:59 | <Domenic> | Oh god why are these still up https://forums.whatwg.org/bb3/index.php |
| 22:59 | <Domenic> | what if someone uses them |
| 22:59 | <Domenic> | am i responsible for answering their questions |
| 23:00 | <zcorpan> | Domenic: i guess that's my responsibility, though i havne't looked at that since.... i dunno |
| 23:01 | <Domenic> | ok yes that is 100% your responsibility i am not sure how you came to that conclusion but i highly agree all yours yep imma go over here now |
| 23:01 | <zcorpan> | Domenic: haha |
| 23:02 | <zcorpan> | Domenic: it's really JAB Creations who deals with the forums in practice |
| 23:03 | <zcorpan> | i don't think it's a problem the forums exist, though i should go over it and have it point people to github instead of the mailing list etc |