| 06:08 | <GPHemsley> | Domenic: Did you miss a few onshow wpt tests? |
| 06:08 | <Domenic> | GPHemsley: it's possible, although they would have to be ones Chrome is not running |
| 06:14 | <GPHemsley> | oh, you're here |
| 06:14 | <GPHemsley> | was expecting async :) |
| 06:15 | <GPHemsley> | just trying to make sure I didn't rip out too much code |
| 06:15 | <GPHemsley> | https://github.com/w3c/web-platform-tests/blob/master/html/semantics/forms/the-button-element/button-events.html |
| 06:15 | <GPHemsley> | https://github.com/w3c/web-platform-tests/blob/master/html/browsers/the-window-object/security-window/window-security.html |
| 06:15 | <GPHemsley> | https://github.com/w3c/web-platform-tests/blob/master/html/browsers/the-window-object/window-properties.html |
| 06:16 | <Domenic> | Hmm, yeah, those look bad. The first especially needs a decent bit of removal. |
| 06:16 | <GPHemsley> | alright, cool, that's good news for me :) |
| 06:17 | GPHemsley | heads to bed |
| 09:00 | <Sebmaster> | annevk: Currently implementing UTS46 proper with all validation rules into whatwg-url and I think the w3c toAscii.json tests are wrong (or impl is wrong, of course). For example, https://github.com/w3c/web-platform-tests/blob/ded8ffe86722118bf035cf2e48c9dbf199aa1f92/url/toascii.json#L16-L20 fails on BiDi rules, since - is neither an L, nor R, nor AL bidi char, I think? |
| 09:03 | <annevk> | Sebmaster: I don't have the bidi rules in my head |
| 09:03 | <Sebmaster> | annevk: https://tools.ietf.org/html/rfc5893#section-2 |
| 09:05 | <annevk> | Sebmaster: right and what table should I consult for the hyphen again? |
| 09:06 | <annevk> | Sebmaster: I guess this is further fallout from browsers having an ASCII fast path sigh |
| 09:07 | <annevk> | Sebmaster: if you want me to do the research the best way forward would be to file a bug I think |
| 09:08 | <Sebmaster> | http://www.fileformat.info/info/unicode/char/2D/index.htm says it's in the EN class? I'm not sure if it can be in multiple classes and the site only lists one though |
| 09:09 | <Sebmaster> | Alright, I'll file a bug |
| 09:11 | <annevk> | Sebmaster: looking at http://www.unicode.org/reports/tr9/#Bidirectional_Character_Types the classes due to seem exclusive |
| 09:11 | <annevk> | Sebmaster: but it also almost reads as if www.9.com would fail then? |
| 09:12 | <Sebmaster> | That is correct. I can probably test that out real quick |
| 09:15 | <annevk> | http://www.unicode.org/Public/UNIDATA/UnicodeData.txt is the canonical thing here I think and would indeed classify 9.com as an error |
| 09:15 | <annevk> | I suspect we must be missing something or none of this makes sense |
| 09:16 | <Sebmaster> | Can confirm. Definitely a failing url... |
| 09:17 | <annevk> | Sebmaster: ooh wait |
| 09:17 | <annevk> | Sebmaster: I think you're not doing the "is a bidi domain" check |
| 09:17 | <annevk> | Sebmaster: "A Bidi domain name is a domain name containing at least one character with Bidi_Class R, AL, or AN." |
| 09:18 | <Sebmaster> | You are correct |
| 09:18 | <Sebmaster> | Thanks! |
| 09:46 | <Sebmaster> | doing the is a bidi domain check makes idnatest.txt fail, of course :( |
| 11:00 | <annevk> | Sebmaster: FWIW, I really appreciate you doing an independent implementation |
| 11:00 | <annevk> | Sebmaster: all browser vendors have been rather lame thus far |
| 11:01 | <Sebmaster> | Heh, definitely |
| 13:03 | <GPHemsley> | Domenic: Filed https://github.com/w3c/web-platform-tests/issues/6652 |
| 14:11 | <annevk> | JakeA: seems like Firefox perceives the results as intermittent |
| 14:11 | <annevk> | JakeA: I restarted that job |
| 14:17 | <JakeA> | Cheers! |
| 14:18 | <wanderview> | JakeA: do you know of any other sites besides your blog using streams in service workers? |
| 14:19 | <wanderview> | not that your blog isn't great, just looking for more sites to test with |
| 14:19 | <wanderview> | maybe I already asked you this... my brain is not working great lately |
| 14:20 | <JakeA> | wanderview: I'm not aware of any. It's something Facebook are experimenting with, but nothing public |
| 14:20 | <wanderview> | JakeA: I guess rbyers hinted at some streaming google site that is coming, but maybe not with service workers |
| 14:21 | <rbyers> | JakeA I can forward you the doc I saw on this, don't know exact details. |
| 14:21 | <JakeA> | Please! |
| 14:22 | <JakeA> | Thanks |
| 14:23 | <wanderview> | rbyers: I think we will soon have nightly builds with stream built, but turned off behind a pref... hoping the folks building this google site can test with that |
| 14:23 | <rbyers> | wanderview: It's Jake's team that has apparently been working with the site in question, so I hope he can help. |
| 14:24 | <wanderview> | rbyers: orly? maybe I can convince him to tell my why it can't work without streams at all |
| 14:24 | <JakeA> | Streams are usually way faster |
| 14:25 | <rbyers> | ... Jake, it looks like Surma has been working with them? |
| 14:25 | <JakeA> | rbyers: Ohhh ok. I guess I'm out of the loop |
| 14:25 | <JakeA> | or my brain's fading |
| 14:26 | <wanderview> | JakeA: yea, but what site makes it a *requirement*? It seems you could polyfil a slower, but functional path instead of blocking current firefox like rbyers said was going to happen |
| 14:26 | <annevk> | jgraham: can you help analyze https://travis-ci.org/w3c/web-platform-tests/jobs/258559653? |
| 14:27 | <annevk> | jgraham: it seems like the Firefox bot doesn't have enough time to run all the tests or some such and just calls it quits? |
| 14:27 | <rbyers> | ... To be clear though, I didn't mean to imply that streams is definitely the reason the site is launching initially Chrome-only (didn't mean to cause you to feel undue pressure wnaderview). In their long list of "features we need" it was the only one I saw that Firefox didn't have yet. It's possible they have other reasons not stated in the doc I read for choosing to launch Chrome-only. |
| 14:27 | <JakeA> | wanderview: I guess I'd need to see what they're using it for |
| 14:29 | <wanderview> | rbyers: I guess I didn't know it was chrome-only... I assumed it was not since other browsers have streams API |
| 14:29 | <annevk> | jgraham: FWIW, the only Fx developer that could look into it will be gone until end of August |
| 14:29 | <rbyers> | I'm just working to understand and reduce all the legitimate technical obsticals that Google teams face when trying to make their sites work great across browsers. |
| 14:29 | <annevk> | jgraham: would not be fun to block the tests on that |
| 14:30 | <rbyers> | wanderview: Yeah they have other features on their list for other browsers, eg. WebP for Edge. |
| 14:31 | <wanderview> | rbyers: well, the cynical folks would argue its not technical reasons why google sites end up chrome-only... |
| 14:31 | <wanderview> | rbyers: streams, webp... really? how are those functional blockers? they are optimizations in most cases I am aware of |
| 14:32 | <wanderview> | I guess I don't understand |
| 14:36 | <annevk> | wanderview: you're not alone |
| 14:51 | <jgraham> | annevk: The problem isn't that the tests don't finish. It's that it seems to get 3 results per test |
| 14:53 | <annevk> | jgraham: how is that possible though? |
| 14:56 | <jgraham> | annevk: fetch/api/abort/general.html runs the tests once in window, once in a worker and once in a shared worker without distiniguishing them by names |
| 14:56 | <jgraham> | You can't do that, so the travis failure is a legit bug |
| 14:56 | <jgraham> | In the tests |
| 14:57 | <wanderview> | hooray for travis! |
| 14:57 | <JakeA> | jgraham: ohh, is there a best-practice way to work around that? |
| 14:58 | <JakeA> | Or shall I just add Worker: to the start of the test name if I detect that global? |
| 14:59 | <annevk> | JakeA: yeah, just giving them different names is a good way to go |
| 15:00 | <annevk> | jgraham: ta! |
| 15:00 | <jgraham> | JakeA: Yeah, that would work |
| 15:00 | <JakeA> | Cool, cheers! |
| 15:09 | <wanderview> | JakeA: I think there is some existing prior art for this kind of stuff in fetch and cachestorage WPT tests |
| 15:10 | <rbyers> | wanderview: Yes, lot's of non-technical reasons people could speculate. But there are _some_ legitimate technical reasons (biggest one IMHO is the cost of additional testing given all the little interop bugs between browsers) and those act as barriers to efforts to try to solve the larger problem (eg. muddy the debate especially for leaders/execs who lack deep technical context). |
| 15:12 | <wanderview> | rbyers: isn't testing/supporting across "the lumpy web" part of web development? if a company like google says they aren't going to do that what message does it send to web community in general? |
| 15:13 | <rbyers> | ... So it's my goal to be able to show compelling concrete data about how modern browsers are more interoperable than ever and continuously getting closer, making a compelling argument for why browser-specific-web-design is a relic from the past and today when you build for any modern browser you should assume (except when shown otherwise) your code works for all of them. |
| 15:13 | <rbyers> | wanderview: Of course I agree. I personally HATE the idea that anyone (let alone Google) would think it's OK to release a web product for a single browser. |
| 15:14 | <rbyers> | ... You're preaching to the choir (I wouldn't be devoting my career to this web predictability thing otherwise). |
| 15:15 | <wanderview> | rbyers: I kind of understand realities around things like google earth... but when you tell me that google won't support edge because they don't have webp... honestly that just sounds lazy at best and anti-competitive at worst |
| 15:15 | <wanderview> | rbyers: I appreciate your efforts, sorry if I'm frustrated |
| 15:16 | <rbyers> | ... That said, I don't think the problem is as bad as "google says they aren't going to do that". Most Google properties invest a ton in this, and actually those are the ones (not exceptions like Inbox that start off Chrome-only) where I'm trying to invest most of my time - they're already motivated but still struggling. Eg. google search puts a ton of resources into understand behavior on dozens of different weird |
| 15:16 | <rbyers> | browsers, eg. all the UC browsers of the developing world that have all sorts of site-specific hacks built into them. |
| 15:18 | <rbyers> | wanderview: This isn't "Google", this is one particular product that historically has so far been native-mobile-only and is finally adding _some_ desktop web support. |
| 15:18 | <rbyers> | ... And I totally understand your frustration, definitely feel free to continue venting to me. I see it as part of my job (because you can sure as hell bet that the product teams in question aren't themselves out here in #whatwg talking about it <grin>). |
| 15:20 | <wanderview> | rbyers: people within google like to point out there are separate teams, etc... those of us on the outside have to deal with the reality google is a single company and what it means when it ships sites that are chrome-only... |
| 15:21 | <wanderview> | I'm thankful all google services are not chrome-only... that is great... but if things like "doesn't have my favorite image format" are reasons for chrome-only now it seems like we're moving in the wrong direction |
| 15:21 | <wanderview> | unless you are building a webp manipulation site or something |
| 15:22 | <rbyers> | wanderview: Sure, I'm just saying just because one product makes bad choices doesn't mean it's hopeless for all of them... |
| 15:22 | <jgraham> | Changing culture is hard. Even when the culture change is beneficial to the org in question. When it's not so clear cut… well I hope this is a fight we can win. |
| 15:22 | <rbyers> | As proof of this, we've got at least one engineer from the Google search team excited enough to fly to Waterloo in a couple weeks to do the compat hackathon with Mike Taylor and other mozillians. |
| 15:23 | <wanderview> | something like "what browsers must we support" is not a cultural question, IMO... that is something that could pretty clearly be set as policy if google cared to |
| 15:23 | <jgraham> | Right, but policy is part of culture |
| 15:23 | <wanderview> | someone at a certain level in google could say "don't ship chrome-only sites" |
| 15:23 | <wanderview> | but they choose not to |
| 15:23 | <jgraham> | Right, I agree. I would like them to do that :) |
| 15:23 | <rbyers> | Right and the question "should we have a company wide policy for what browser we should support" is absolutely a culture question to which Google would strongly say "NO, that's a product question for each team to decide". |
| 15:24 | <wanderview> | rbyers: then I think its fair to say *google* does not necessarily have a culture that values web compat |
| 15:24 | <jgraham> | But from the other side, someone at Mozilla could declare that we have to put additional effort into compat despite short term cost (e.g. stop writing non-web-platform-tests for platform features) and they don't |
| 15:25 | <wanderview> | jgraham: we have shifted most testing to WPT, though |
| 15:25 | <jgraham> | wanderview: Hah |
| 15:26 | <wanderview> | jgraham: is WPT running on android yet? |
| 15:26 | <rbyers> | Yeah frankly I'm kind of surprised that Mozilla of all browsers doesn't yet have an interop testing policy a least as strong as our current (temporarily weak one). |
| 15:26 | <jgraham> | wanderview: That is true of certain engineers on certain teams, but not in general |
| 15:26 | <jgraham> | wanderview: No |
| 15:27 | <rbyers> | wanderview: To be fair, we don't run WPT on Android yet either. But in practice our web platform code is nearly identical on Linux so we haven't seen that cause much problem in practice so I'm OK with it as a temporary pragmatic tradeoff. |
| 15:27 | <rbyers> | ... But if we start seeing Android-specific issues slip through at a non-trivial rate, then I'll definitely get it fixed somehow. |
| 15:28 | <wanderview> | my point is WPT integration is progressing, but there are still some coverage gaps, etc... we have largely moved to WPT tests for webapi related stuff AFAIK |
| 15:28 | <jgraham> | Yeah, we could get it working on android too. The pieces are there, what's needed is maybe a quater of effort to wire it all up and deal with the inevitable horrorshow of intermittents |
| 15:28 | <rbyers> | For context: our requirements for shipping any newly exposed web feature include describing why it isn't yet fully tested with web-platform-tests: https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit#bookmark=id.w8j30a6lypz0. |
| 15:28 | <wanderview> | jgraham: if there are teams not writing WPT tests let me know... I think it works well enough now we should ask them to switch |
| 15:30 | <rbyers> | wanderview: I've seen plenty of examples of new features that shipped in Firefox without web platform tests, I could dig some up if you like. position:sticky is one recent one that comes to mind. |
| 15:32 | <jgraham> | wanderview: Well the observed reality is that stylo didn't add wpt testing until I fixed that, even though it was trivial. And if you look at the tests we write there are still lots of mochitest-plain and reftests. Which is partially to do with coverage gaps, but if someone decreed we were only going to do wpt and committed more people to the effort, those gaps could be fixed a lot faster |
| 15:32 | <wanderview> | jgraham: I still write mochitests when I am testing things that require superPowers, weird crash regressions that aren't really about web compat, etc |
| 15:33 | <bloopletech> | I'm playing around with some JS and was looking to see what the specification is around 'expando' properties on DOM/HTML Nodes, but I can't seem to find any info in the HTML, DOM or ECMA-262 specs. It's quite possible it's there and I missed it, but I can't think of the right search terms |
| 15:33 | <wanderview> | rbyers: I think we just got CSS WPT tests running |
| 15:34 | <jgraham> | Anyway, to get back to my original point, I think Google products only supporting Chrome is a medium-term threat to the multi-vendor open web. But I think that the kind of cultural change that would be required to prevent it ever happening is really hard to achieve. |
| 15:35 | <jgraham> | So I am at least very glad that rbyers is trying. I hope it's enough. |
| 15:35 | <wanderview> | jgraham: I'm worried about the trend... missing features requiring native plugins is one thing... rbyers is now warning us of a new product that is making that decision with a *much* lower bar (webp missing in edge, etc) |
| 15:36 | <wanderview> | and I know rbyers did not intend to apply pressure on our streams implementation... but clearly it does actually apply pressure when a company with sites as big as google say they are going to block your browser |
| 15:36 | <jgraham> | wanderview: I share your worry. I don't know what to do about it except trying to remove the technical hurdles by e.g. having good cross-browser testing and having a good way of running tests for the sites themselves that works cross-browser. |
| 15:37 | <bloopletech> | even though what I'm talking about is probably obvious to most, I did a example JSfiddle: https://jsfiddle.net/ohzuz1hc/ |
| 15:37 | <wanderview> | trying not to be cynical, but its a short jump to "implement html imports or we can't support firefox, sorry... chrome-only" |
| 15:37 | <rbyers> | jgraham: Thanks, I'm certainly trying - and it's not just me, lots of people on the web platform team. |
| 15:38 | <wanderview> | thank you rbyers |
| 15:38 | <bloopletech> | side note as I'm joining in this conversation late, but strategically doesn't Apple's strong presence in mobile mean that any Google property has to work in Safari/WebKit? |
| 15:40 | <bloopletech> | On my original question: the fact that you can set a new property on a JS object is just normal, but the fact that you can set the property, then retrieve the Node from the DOM and the new property (or a copy) is still there is the interesting part |
| 15:40 | <wanderview> | bloopletech: maybe the expando info you are looking for is covered by webidl [SameObject] and then its use in various other specs? https://heycam.github.io/webidl/#SameObject |
| 15:40 | <rbyers> | I think the issue is not specific features like WebP or streams. I think we can all agree that would be stupid. But there is a larger legitimate issue here that's more abstract: the cost of building a rich powerful web product that works really great across all browsers is a lot higher than the cost of building the same product for any one browser. It's on us (the web browser/standards community) to reduce this cost. |
| 15:43 | <bloopletech> | rbyers: that statement has been true for the entire time I've been involved with web development (so about 2003 onwards ;)) |
| 15:43 | <rbyers> | Frankly I think we've been too complacent on this front historically. We solve this problem by first looking really critically at ourselves and how we can do better (since we can control that directly). IMHO It is an absolute embarrassment that the single most popular computing platform in the world doesn't yet really evolve with a good level of software engineering discipline. |
| 15:45 | <bloopletech> | isn't the lack of 'discipline' the exact same reason the web exploded and became a platform in the first place? |
| 15:45 | <tobie> | rbyers: what's interesting from the examples (streams, WebP) is those are new features which have precisely been added with the intent to improve the platform and make it more competitive. And yet, because vendors don't sync shippung new features it has a tendency to provoke the opposite, at least during a certain time. |
| 15:46 | <rbyers> | bloopletech: Perhaps, there's certainly a tension between innovation and careful engineering discipline ;-). Eg. we could be much more "disciplined" about interop by never shipping any feature in Chrome that wasn't also shipping in another browser, but we're not willing to slow down web evolution to that extent. |
| 15:46 | <bloopletech> | yes that is an awesome ideal |
| 15:47 | <tobie> | This tension is the crux of the problem, right? |
| 15:47 | <bloopletech> | but I think the W3C requiring 2 competing implementations before standardisation is what killed a number of specs and begat WHATWG in the first place right? |
| 15:48 | <bloopletech> | well that and xhtml |
| 15:48 | <rbyers> | tobie: Perhaps, it's certainly important. But just the progress we've made in web predictability on the past year in Chrome suggests there was a lot of win-win value available that we were just missing somehow... |
| 15:48 | <wanderview> | that's why we work to make APIs feature detectable, etc. So sites can be Progressive... (something I think google coined an acronym about or something) |
| 15:49 | <tobie> | wanderview: sure, but that's still extra work. |
| 15:49 | <jgraham> | YEah, so I certainly agree that we haven't got to the stage where we can't do better just by solving engineering problems |
| 15:49 | <wanderview> | welcome to shipping on the platform with the greatest reach that isn't owned by a single company? |
| 15:50 | <tobie> | rbyers: that's a good point. All the investment in wpt for example, increases velocity for everyone and thus tends to reduce that gap. |
| 15:50 | <wanderview> | I mean, this isn't new... we want to improve it over time... but some of this is unavoidable due to the decentralized nature of the web and the fact no one entity controls it |
| 15:50 | <jgraham> | But it might also be true that just solving eningeering problems isn't enough in the face of a large power imbalance |
| 15:54 | <tobie> | The other question is whether there's still a long term value today in having multiple browser engines, when they're open source and effectively a commodity. |
| 15:54 | tobie | ducks |
| 15:54 | <bloopletech> | I've actually had the same thought privately |
| 15:55 | <bloopletech> | but the popular opinion re cathedral vs bazaar is that the bazaar is a priori better |
| 15:55 | <tobie> | phrased differently, does open source trump standardisation at some point or not? |
| 15:57 | <jgraham> | tobie: I think that servo is an existence proof of the value of having >1 engine, even though it's not yet viable as a standalone product |
| 15:57 | <bloopletech> | in DOM, Element certainly has "[SameObject] readonly attribute NamedNodeMap attributes;" and there's certainly descriptions of how to get and set the attributes etc but AFAICT nothing explicit that the attributes are accessible on the Element itself |
| 15:57 | <bloopletech> | good point |
| 15:58 | <wanderview> | bloopletech: I think from spec perspective its just a js object... so you can set properties on it... the [SameObject] is what guarantees those properties will persist across API getter calls |
| 15:58 | <wanderview> | bloopletech: but maybe Domenic knows better here |
| 15:59 | <tobie> | bloopletech: I'm not sure I understand the question |
| 15:59 | <bloopletech> | yeah I am being pedantic for sure, but element.potato is different from element.attributes.potato right? and having just checked the fact that the newly-created property is JS-side only is worth mentioning |
| 16:00 | <bloopletech> | tobie: in this fiddle, you can see one can create a new property on an element dynamically in JS and then later retrieve the property on a new 'instance' of the same Node: https://jsfiddle.net/ohzuz1hc/ |
| 16:01 | <bloopletech> | I just cant' find anything spec-wise that explicitly describes the process |
| 16:01 | <tobie> | that's just JS |
| 16:02 | <tobie> | bloopletech: and it has no relation to the attributes attribute. |
| 16:04 | <bloopletech> | ok sure... but the fact that the Element you get back from querySelector has the extra property is because it's literally the same object in memory or whatever? |
| 16:04 | <tobie> | bloopletech: yes |
| 16:05 | <tobie> | bloopletech: it's the same object |
| 16:06 | <bloopletech> | sure. empirically that's obvious, just didn't realise that was guaranteed. but tbh I didn't even look at the spec of querySelector till now |
| 16:06 | <tobie> | bloopletech: that's irrelevant to querySelector |
| 16:07 | <tobie> | bloopletech: the DOM tree is constructed at load time and then just sits there. |
| 16:07 | <tobie> | bloopletech: querySelector is just a way to easily traverse it. |
| 16:09 | <bloopletech> | tobie: yeah now you mention it that's obvious. Because everything is defined as IDL and interfaces, I didn't realise it was spec that there is only one instance of the Node object in the tree for a particular element |
| 16:11 | <bloopletech> | the cool part is that I can definitely abuse this; as opposed to dataset where the values are coerced to strings, I can whack in whatever object I want |
| 16:13 | <tobie> | bloopletech: the reason this is avoided is it tends to create references which prevent GC when the nodes are subsequently removed. |
| 16:14 | <bloopletech> | ah ok, interesting. I mean the other reason is because whatever property name you choose might be clobbered in the future by the spec |
| 16:16 | <jgraham> | JakeA: I'm happy with the fetch abort tests now, but you should get approval from someone who understands the spec :) |
| 16:18 | <JakeA> | jgraham: cheers! |
| 16:44 | <tobie> | How is CSSOMString a thing? |
| 16:44 | <annevk> | tobie: Rust |
| 16:44 | <tobie> | annevk: sure, but what does it even mean? |
| 16:45 | <annevk> | tobie: it means USVString in Rust and likely DOMString everywhere else |
| 16:45 | <tobie> | annevk: isn't that an implementation detail, though? |
| 16:45 | <annevk> | tobie: it's observable with lone surrogates |
| 16:47 | <tobie> | annevk: where is it defined? |
| 16:47 | <tobie> | annevk: and how is it defined? |
| 16:48 | <tobie> | oh, CSSOM |
| 16:49 | <tobie> | https://drafts.csswg.org/cssom/#cssomstring-type |
| 16:50 | <TabAtkins> | Yup, Rust wanted USVString because it better matches their internals, other browsers wanted DOMString for the same reason, the difference is tiny, so we just used both. |
| 16:54 | <tobie> | I see. Isn't this something that's going to permeate other bits of the platform at some point? |
| 17:23 | <annevk> | tobie: it might, hsivonen wants to do it for DOM too |
| 17:24 | <annevk> | tobie: once we get there we can revisit the name and place of definition |
| 17:24 | <tobie> | annevk: sure. No hurries. |
| 17:25 | <tobie> | annevk: I was looking at the string stuff and got carried away into this rabbit hole |
| 19:40 | <wanderview> | annevk: JakeA: did the fetch cancelation WPT tests land? |
| 19:43 | <JakeA> | wanderview: are we allowed to land them before spec? |
| 19:43 | <wanderview> | I guess not |
| 19:51 | <wanderview> | JakeA: I got some more fetch cancel patches from baku and was hoping the spec/tests were finalish |
| 19:58 | <JakeA> | wanderview: the tests in that branch are good to go |
| 19:59 | <wanderview> | ok, thanks |