2016-08-01 [18:59:47.0000] zewt: used fetch [19:00:46.0000] tobie++ indeed [19:00:59.0000] brave man [20:41:05.0000] mike: shouldn't need to rewrite with a different api for that, no reason it should work with one and not the other [20:41:53.0000] (sounds like that's just encouraging people to not use https, if they have to rewrite code with a different api to make it work) [20:59:01.0000] zewt: I meant this is maybe a case where there’s no plan to change/update XHR for this or any other new cases [20:59:40.0000] cannot just keep going in and updating legacy funky API [21:06:14.0000] doesn't seem funky to add an "allow mixed" flag to XHR, the fewer barriers discouraging HTTPS the better [21:07:32.0000] (i still use XHR, it works fine for me so I've never felt like spending time learning a new API, especially one that isn't universal yet) [21:15:59.0000] zewt: well for better or worse I think the plan of record is that at this point there are no plans to ever update XHR with anything new [21:16:08.0000] And there are fetch() polyfills. [21:26:25.0000] Domenic: why is Firefox's rendering a bad thing? The author created invalid markup [21:26:51.0000] boogyman: people create invalid markup all the time... you still gotta render something reasonable. [21:27:21.0000] and you consider negative numbers unreasonable? [21:27:35.0000] Yeah definitely [21:27:55.0000] I guess we disagree [21:28:13.0000] I mean this needs to be interoperable at the very least. [21:28:27.0000] https://github.com/whatwg/html/issues/1617 [21:33:07.0000] Why is it a bad thing that the UA could be put into quirksmode with invalid syntax like this? [21:33:44.0000] I don't think this has anything to do with quirks mode... [21:34:12.0000] UAs need to be interoperable not just when authors are well-behaved, but also when they aren't. [21:34:52.0000] Authors writing invalid markup is not a license for no longer following specs. (Although in this case the spec is missing details.) [21:35:26.0000] the alternative is to try and create notations for every found use-case? [21:35:32.0000] is the* [21:35:39.0000] Yes, that's what specs do [21:35:48.0000] That was the whole HTML4 -> HTML5 revolution [21:36:06.0000] That's why we have a HTML parser spec instead of DTDs [21:36:44.0000] fair enough [01:10:02.0000] annevk, happy birthday [01:22:05.0000] Happy birthday, annevk! (And happy national holiday in your country of adoption:) [01:22:35.0000] Cheers 😊 [01:23:12.0000] Oh, so that's why you moved there? :) [02:38:51.0000] smaug____: I've added metrics to measure EventSource usage in Document and Workers in Chromium [02:39:20.0000] smaug____: it should appear in https://www.chromestatus.com/metrics/feature/popularity as EventSourceDocument and EventSourceWorker but at the moment, the data is only collected on Dev/Canary and will soon be on Beta, give it some time to really have useful data [02:40:06.0000] thanks [03:33:39.0000] annevk: is `new URLSearchParams('foo=%EF%BF%BF').get('foo')` supposed to perform UTF-8-style URL-decoding? i.e. should it return '\xEF\xBF\xBF' (Chromium) or '\uFFFF' (Firefox)? [07:22:14.0000] mathiasbynens: suspect Fx is correct [07:22:43.0000] annevk: was hoping that was the case, as it’s the more useful behavior (by far) [07:23:09.0000] but [07:23:09.0000] https://bugs.chromium.org/p/chromium/issues/detail?id=633153#c4 [07:24:10.0000] Will look later this week [09:23:40.0000] tobie: hope you have a good holiday too btw 😊 [10:03:01.0000] annevk: :) [11:51:07.0000] tobie: That does work, but the [] aren't part of the definition. Remove those (or shift them outside {{}} braces) and it should link up. [13:07:52.0000] TabAtkins: So {{TreatNullAs}} yields: TreatNullAs [13:07:52.0000] TreatNullAs yields: [TreatNullAs] [13:09:04.0000] TabAtkins: OK, I think this ties to the GH issue I opened. [13:09:37.0000] tobie: Yes, those are compatible - "idl" is a supertype representing all the IDL types, of which "extended-attribute" is one. [13:10:29.0000] Aren't we loosing info that could be useful for styling or when parsing the spec to fill-in the shepherd DB? [13:14:47.0000] TabAtkins; In https://wicg.github.io/entries-api/ I end up with refs to [File-1] (autogenerated from normative refs) and [FileAPI] (from explicit informative refs), pointing at the same doc. Is that a bikeshed thing or a specref thing? [13:16:28.0000] jsbell: That's me giving FileAPI a weird shortname; I just updated it to be "fileapi" instead, so I think it'll match up now. [13:16:45.0000] If it still does [Fileapi-1] vs [FileAPI], file on me. [13:17:13.0000] testing... [13:17:34.0000] tobie: Nobody's losing anything, they're specifying what they need. If they want to be more specific (because they're styling based on class or something), they can do so, but the shorthand purposely covers a large group of things for convenience. [13:17:51.0000] jsbell: You'll have to `bikeshed update` [13:19:01.0000] TabAtkins: yep. Hrm, now getting No 'idl' refs found for 'File'... [13:23:13.0000] Might be rebuilding right now, or maybe you have some manual declarations that "File" comes from the "file" spec? [13:24:18.0000] TabAtkins: No manual declarations for those. I'll try again in a bit. (FYI, 4 errors total. idl/interface/idl-name for File, idl for FileReader) [14:08:57.0000] TabAtkins: would you have any idea why the following https://github.com/tobie/webidl/blob/bikeshed/index.bs errors with: [14:08:57.0000] FATAL ERROR: Multiple local 'interface' s have the same linking text 'DOMString'. [14:17:20.0000] TabAtkins: I can search and replace all of the instances of "DOMString" with garbage and keep only this one:

DOMString

while still triggering the issue. [14:21:29.0000] TabAtkins: reduced test case here: https://gist.github.com/tobie/3ff6f07158403cde5d154156e2e535d2 [16:58:43.0000] tobie: Ah, sorry, that's because of my terrible hacks to let people link to some of the webidl things. Manually specified anchor blocks count as "local" definitions, and DOMString is in Bikeshed's default anchor file. [16:58:55.0000] So you're colliding with the built-in "DOMString" definition. :/ [16:59:23.0000] I'll remove that as soon as WebIDL can legitimately provide a dfn for the term; for now just suffer thru it. 2016-08-02 [05:23:52.0000] wtf: https://github.com/ylafon/webidl [05:31:07.0000] Ms2ger: What's the problem? [05:31:40.0000] Some random guy forking the spec with no communication whatsoever [05:33:13.0000] Ms2ger: I didn't realise he is part of W3C; [05:33:17.0000] now I see the problem. [05:34:31.0000] remind me, which spec defines how .style.* is mapped to style attribute [05:34:31.0000] will do [05:38:19.0000] (could someone finally kill w3schools) [06:00:51.0000] so I have this strange behavior (so far in Firefox only), when I append a large absolutely positioned element that is translated (css transform) far to the right (out of the screen) and the browser scrolls the documentElement to try to keep this big offscreen thing in the viewport [06:01:02.0000] is this specced/documented/reported/explained somewhere? [06:56:19.0000] Is w3c open for proposals like TC39? [06:56:28.0000] if yes, what's the process like? [06:56:32.0000] how many stages? [06:59:27.0000] have you tired adding an event listener is a promise? [06:59:45.0000] new Promise((res, rej) => element.addEventListner('click', () => if(...){resolve()} reject())) // something like [06:59:53.0000] Domenic: is that a bad idea? [07:23:31.0000] The W3C process is based on stubbornness to the point of exhausting anyone with actual work to do [07:24:14.0000] As for the WHATWG, https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F [07:26:47.0000] In general event listeners and promises have an impedance mismatch because promises are resolve-once and event listeners are continuous streams of events [07:28:07.0000] jgraham: so it's a no no, it won't work right? [07:28:25.0000] Ms2ger: Forget about the particular solution you have in mind! Solution time is later! :D [07:28:50.0000] So much of writing to do :( [07:28:54.0000] Well you can make something that works if you want a promise to resolve the next time a particular event fires [07:29:42.0000] But it generally doesn't seem useful enough to add to the platform; for events that only fire once new APIs are sneakily using promises directly (eg. fetch vs xhr) [07:56:39.0000] Ms2ger: afaik, there's been communication about it. ylafon is working on a bringing version 1 to Rec. That version would only contain bindings actually implemented by vendors. [07:57:04.0000] Ms2ger: note I'm offering info about it. Not my opinion on the topic. :) [08:07:29.0000] jgraham: try, luck that fetch is a function, we done need to do a new Fetch() heh heh [08:07:40.0000] jgraham: does fetch extend promise internally? [08:07:51.0000] or just returns a new Promise() ? [08:21:27.0000] > W3C invites implementations of Mixed Content [08:21:29.0000] Noooooooooo [08:25:55.0000] I thought we were only doing HTTPS these days [08:26:02.0000] HTTPS is the new HTTP [08:35:24.0000] Ms2ger: is that a serious IDL fork? Seems weird… [08:43:07.0000] annevk: see my comments above [08:58:10.0000] Ah [08:58:18.0000] Missed that somehow [10:14:55.0000] Is it possible to represent IPv6 addresses in decimal or octal, similar to how IPv4 addresses can be? [10:20:05.0000] smaug____: As far as I can tell... it's not defined anywhere. [10:21:10.0000] Style Attributes just defines that the contents of a style attribute apply to the document as if they were in a stylesheet. [10:21:11.0000] TabAtkins: ok. The question I have is that when should setting .style.foo = "some new value" cause a dom attribute set [10:21:19.0000] And OM doesn't seem to ahve any specific text about this. [10:23:44.0000] IMO element.style.width = "10px"; element.style.width = "10px"; should cause two mutation records, to be consistent with element.setAttribute("style", "width: 10px;"); element.setAttribute("style", "width: 10px;"); [10:24:36.0000] but not all the browsers create the latter record for the .style case [10:25:20.0000] Yeah, I think that's utterly undefined. A good bug report for CSSOM. Make zcorpan fix it. ^_^ [10:25:54.0000] (I wouldn't be surprised if it does dirty-checking and only writes when there's a change.) [10:26:57.0000] > Mutating the declarations must set the style content attribute on the context object to the serialization of the declarations. If the style content attribute is set, changed or removed, the declarations must be updated as appropriate. [10:27:13.0000] So what is "Mutating the declarations"? [10:27:26.0000] smaug____, file a bug on cssom? [10:28:00.0000] reading... [10:28:04.0000] perhaps this is speced? [10:28:49.0000] hmm, " Mutating the declarations" is indeed too vague 2016-08-03 [21:04:15.0000] you have any advice about how I should preparee fo/win 23 [21:04:18.0000] oofs [06:14:07.0000] hmm, I thought I knew how download attribute works with [06:14:11.0000] but apparently I don't [06:19:23.0000] hmm, or perhaps server can still override the filename? [06:49:19.0000] JakeA: a couple times last week you mentioned the idea of returning a promise from respondWith() that would resolve after the browser consumes the response [06:49:30.0000] it didn't quite sit well with me and I couldn't figure out why [06:49:39.0000] I think I finally figured out what bothers me about it [06:50:13.0000] JakeA: wouldn't a promise returned from respondWith() essentially provide a callback exactly when we're no longer holding the service worker alive? its like a "now its unsafe" callback [06:50:55.0000] wanderview: yeah you'd have to do waitUntil( respondWith(stuff).then(…) ) [06:51:12.0000] Which is a bit :/ [06:51:38.0000] JakeA: or it gets an implicit extension for a micro-task... but feels difficult to explain with our current primitives [06:51:42.0000] or wonky at least [07:06:51.0000] We already have an extension for a microtask right? [07:07:25.0000] We talked about that so waitUntil( thing.then(() => waitUntil(anotherThing)) ) works [07:08:06.0000] hm, my code there is wrong. I mean: thing.then(() => waitUntil(anotherThing)); whatUntil(thing); [07:08:17.0000] hah, I mean waitUntil [07:08:28.0000] /me falls over [07:56:59.0000] wanderview: now I think about it, didn't we decide a separate fetcherror event was a better idea? [07:57:37.0000] JakeA: yea... I was just thinking about the respondWith() promise idea this morning [07:58:09.0000] JakeA: I guess I was saying "not only are we not doing your idea, Jake, but I don't like it either!!!!" [07:58:10.0000] sorry [07:58:18.0000] :-) [07:58:21.0000] haha [07:58:54.0000] Yeah, the event is better, as you can do something with it [08:03:42.0000] JakeA: now I'm trying to remember why we wanted FetchErrorEvent instead of just using the normal Worker global onerror... I guess its more explicit and we can provide a better method to "resume the connection" than just preventDefault() [08:04:24.0000] wanderview: yeah, preventDefault is really confusing in this case, since it'd make the default thing happen [08:05:58.0000] annevk: https://fetch.spec.whatwg.org/#http-fetch 3.3 - does this suggest a new generic network error is created? Devs have complained that Chrome presents a generic error rather than a more specific one. Does there need to be a spec change to allow the actual error to pass through to the navigation handler? [08:06:50.0000] JakeA: yeah, we'd need to change the spec [08:07:01.0000] I'll file an issue [08:07:06.0000] JakeA: and get security sign off [08:07:11.0000] annevk: I think the browser could just stash the specific type on an internal value... its never consumed by anyone but the browser [08:07:32.0000] JakeA: that is the main reason all errors are the same [08:07:56.0000] Yeah, might need some same-origin checks [08:08:30.0000] annevk: JakeA: in firefox all network error pages are cross origin.. so i don't think the error type can ever be leaked to content... doesn't seem like a security issue to me... might be an issue for chrome with same-origin error pages [08:08:51.0000] JakeA: even for that I recall folks not liking it, but there might be APIs exposing that now [08:09:37.0000] wanderview: I thought we were discussing specific TypeError exceptions [08:09:51.0000] Hmm, I can't think of problems, but will make an issue and see if we can get someone security-minded to look at it [08:10:04.0000] annevk: not if its the same as the face-to-face meeting discussion... it was just showing the right network error page to the user... not exposing different exception types [08:10:51.0000] Okay, I guess I'll follow up on the issue then 😊 [08:11:07.0000] Not today, but likely tomorrow [08:24:34.0000] who might know about blink's MutationObserver implementation [12:21:32.0000] JakeA: how do you BroadcastChannel to a service worker? [12:21:59.0000] wanderview: new BroadcastChannel? It'd only work while the instance is alive [12:22:06.0000] JakeA: I guess each service worker thread adds an event listener to the BroadcastChannel ? [12:22:12.0000] Yeah [12:22:20.0000] /me goes to read BroadcastChannel... [12:22:20.0000] I don't think it's a problem, just something to think about [12:22:56.0000] JakeA: it might be worth pointing out that SharedWorker is either not implemented or not supported as a nested worker in any browser today? [12:23:07.0000] but we could make that a pre-req of implementing this? [12:23:15.0000] Good point [12:23:45.0000] JakeA: maybe pre-req is too strong a word :-) [12:27:01.0000] JakeA: I do kind of like the conceptual difference between SharedWorker and ServiceWorker in this design... ServiceWorker instances are ephemeral and fast... if you want synchronous coordination you pay the price and opt-in to SharedWorker [12:27:41.0000] Or IDB (maybe with observers too) [12:27:52.0000] JakeA: I guess an opt-in to "single thread always" for service worker could just be implemented as "all service worker instances open a SharedWorker and fire their event there" [12:28:26.0000] JakeA: I mean, the browser could implement it that way... no special logic beyond what the content could polyfil themselves [12:28:38.0000] JakeA: the browser would just be fixing up the global to connect a few things, etc [12:28:51.0000] Hah! Well, if you're talking about doing that on the developer-side, it's tricky due to what can be cloned/transfered [12:31:20.0000] JakeA: once ReadableStream transfer gets spec'd, I think Response/Request objects should be transferable as well? [12:31:35.0000] Agreed 2016-08-04 [00:05:19.0000] JakeA: thanks for https://github.com/w3c/webappsec-mixed-content/issues/7 [00:05:36.0000] JakeA: was thinking about raising that issue this morning in that exact repository [00:11:04.0000] No problem! Still worried about the practicality of it, but I get where you're coming from [00:18:50.0000] Yeah, well, folks should just move to HTTPS really [00:19:24.0000] That we present HTTP as more favorable than mixed content is part of the problem, they're sorta the same [00:21:42.0000] We may have made that change in Chrome, or we've certainly been moving in that direction [00:25:02.0000] Hmm, https://github.com/whatwg/dom/commit/9e3ce67c7927d6642646a3d0c84fa6d8f7926cfa no longer points to the correct PR [00:25:14.0000] So removing the PR annotation might be problematic? [00:27:46.0000] Wasn't that in the pre-green-merged-button days? [00:28:14.0000] It might also just be a GitHub bug.... no idea why tab's fork took over the pointer [00:33:05.0000] Yeah could be, though April seems pretty recent [01:11:15.0000] Domenic: accessible nodes have their own tree as well with focusing and such? [01:11:29.0000] Domenic: so now we have shadow trees, accessible trees, and normal trees? [01:11:37.0000] annevk: apparently. I am not super-jazzed about them having parallel concepts, *especially* event dispatch. [01:11:41.0000] Domenic: that sounds very complicated [01:12:07.0000] annevk: part of the idea, I think, is to allow adding a "virtual" ax tree underneath a canvas [01:12:21.0000] It *is* apparently exposing the primitives that browsers already implement [01:12:41.0000] Domenic: all browsers? [01:12:58.0000] Domenic: I doubt we have something like that, unless they mean XBL, which is shadow trees [01:13:06.0000] annevk: hmm i'm not sure. but i believe all the implementers are involved... [01:13:45.0000] Domenic: but nobody with a background in API design is on the list of editors [01:16:12.0000] https://lists.w3.org/Archives/Public/public-w3process/2016Aug/0017.html [01:18:33.0000] Domenic: also, I thought

s etc [23:41:53.0000] Domenic: we only vaguely define that for browsing contexts [23:42:14.0000] Domenic: lifecycle of documents/windows is terrible though [23:42:28.0000] Ask hsivonen about it :) [23:42:28.0000] will do [23:42:32.0000] Oops [23:49:18.0000] Domenic: about upload streams, https://www.w3.org/Bugs/Public/show_bug.cgi?id=20322 is relevant [23:49:39.0000] Domenic: it seems browsers are widely inconsistent (and XMLHttpRequest is too) about progress event listeners for uploads [23:50:35.0000] Domenic: that doesn't really diminish the chunked encoding aspect, but given H2 has different framing perhaps that isn't as much of an issue (although we should still make sure of course) [23:50:44.0000] hmm hmm [23:50:53.0000] Not really sure what to make of it... [23:51:24.0000] This HEIST attack makes me feel like I don't understand the constaints anymore :( [23:52:38.0000] The constraints are basically anything that isn't possible using

, , ,