| 00:18 | <MikeSmith> | has anybody looked in detail at the “Identity Provider Proxy” stuff in the WebRTC spec? |
| 00:18 | <MikeSmith> | http://w3c.github.io/webrtc-pc/#sec.create-identity-proxy |
| 00:51 | <duper> | MikeSmith: not me.. looks like SAML at first glance though |
| 00:56 | <MikeSmith> | oh |
| 00:56 | <MikeSmith> | duper: I hope it wasn’t inspired by that |
| 00:58 | <MikeSmith> | annevk: http://stackoverflow.com/questions/38957103/fetch-api-rejects-with-networkerror-when-hosted-on-localhost-firefox-only |
| 06:40 | <mathiasbynens> | wait, what https://twitter.com/distobj/status/765286699404591104 |
| 06:59 | <MikeSmith> | mathiasbynens: trolling |
| 06:59 | <MikeSmith> | he just has an axe to gring |
| 06:59 | <MikeSmith> | *grind |
| 07:00 | <MikeSmith> | hmm disappointed James Clark hearted that but oh well |
| 07:00 | <MikeSmith> | everybody has their blind spots |
| 07:00 | <MikeSmith> | techno-reactionarism |
| 07:02 | <MikeSmith> | if they had to actually implement browser engines they would have a different POV |
| 07:12 | <annevk> | I guess it's valid in the sense that JavaScript obsoleted itself by merging into the thing it was patching, but generalizing it is shortsighted |
| 07:13 | <annevk> | The Quirks and Compat effort have a similar goal, but most other standards don't |
| 07:46 | <MikeSmith> | I think they just get hung up on the word “standard” |
| 07:48 | <annevk> | Using "Standard" turns out to be a good litmus test |
| 08:36 | <mkwst> | Hey folks! I see a few pings in my IRC history, but scrolling through ~2 weeks of backlog doesn't sound like fun. If y'all need something from me that's still relevant, let me know? :) |
| 08:36 | <MikeSmith> | hey mkwst welcome back |
| 08:37 | <mkwst> | hey MikeSmith! |
| 08:37 | <mkwst> | (I'm out again next week; fair warning. :) ) |
| 08:37 | <MikeSmith> | heh |
| 08:38 | <Ms2ger> | mkwst, http://logs.glob.uno/?a=search&c=freenode%23whatwg&q=mkwst&ss=1+Aug+2016&se=16+Aug+2016 |
| 08:38 | <MikeSmith> | will try to pile on as much as possible this week then :D |
| 08:38 | <mkwst> | Ms2ger: !!! That is super useful! |
| 08:39 | <MikeSmith> | oh wow yeah didn’t knwo you could do that |
| 08:39 | <MikeSmith> | hsivonen: is there some way I can get a ContentHandler.characters to ignore inter-element whitespace? |
| 08:41 | <MikeSmith> | hsivonen: specifically for https://github.com/validator/validator/blob/master/src/nu/validator/xml/LanguageDetectingXMLReaderWrapper.java#L171 |
| 08:41 | <mkwst> | MikeSmith: with regard to moving origin policy to WICG, I'm fairly agnostic. Probably worth doing from a process perspective, but not worth doing if we end up running with mnot's more header-based suggestion. |
| 08:42 | <MikeSmith> | mkwst: SGTM |
| 08:42 | <mkwst> | MikeSmith: I _think_ the approach I'm proposing is better, but I might be missing some of the middleware story. I need to chat with Mark. *shrug* |
| 08:42 | <MikeSmith> | OK |
| 08:56 | <annevk> | foolip: interested in reviewing https://github.com/whatwg/dom/pull/295? |
| 10:13 | <zcorpan> | any opinions on where to put the definition of innerText? |
| 10:14 | <annevk> | zcorpan: is it for all elements or just HTML elements? |
| 10:14 | <annevk> | Also, not really I suppose |
| 10:14 | <zcorpan> | annevk: HTMLElement. but we'll also want the same algorithm for Selection |
| 10:15 | <annevk> | That is still a goal? Cool |
| 10:15 | <annevk> | Is rniwa on board with it? |
| 10:16 | <zcorpan> | hmm i don't know, i assumed it was a goal. i might have missed or forgotten some discussion about this |
| 10:17 | <annevk> | zcorpan: putting it somewhere in 3.2 seems okay |
| 10:18 | zcorpan | finds https://www.w3.org/Bugs/Public/show_bug.cgi?id=10583 |
| 10:19 | <zcorpan> | annevk: ok |
| 10:45 | <hsivonen> | MikeSmith: the inter-element whitespace stuff in SAX requires DTD processing to decide what's inter-element whitespace |
| 10:46 | <MikeSmith> | hsivonen: OK that is what I thought and what I was afraid of |
| 10:46 | <hsivonen> | MikeSmith: I'm not sure if you can get that info out of Jing, but my understanding is that RELAX NG is in principle not about augmenting the infoset with this kind of info |
| 10:46 | <MikeSmith> | yup I think so |
| 10:46 | <MikeSmith> | I think Jing does not expose it either |
| 10:47 | <hsivonen> | you could collapse each run of whitespace to a single space. that should be good enough for language detection |
| 10:48 | <MikeSmith> | yeah I was hoping not to have to do that, and instead just pass on the whole character array as is |
| 10:49 | <MikeSmith> | but I think for this purpose it may be sufficient to just not count whitespace toward the MIN_CHARS total |
| 10:50 | <MikeSmith> | I would still have to have to look at it character-by-character but at least I would not have do the additional collapsing |
| 11:45 | <annevk> | MikeSmith: any chance I could get some kind of access to https://github.com/w3c/resource-timing that allows me to fixup comments and such? |
| 11:45 | <annevk> | MikeSmith: other than my own, that is |
| 13:09 | <annevk> | Turning Attr into a Node is harder than I thought |
| 13:32 | <nox> | annevk: Noooooooo |
| 13:32 | <nox> | :'( |
| 13:32 | <nox> | annevk: Sorry, my common sense followed me even though I asked it to stay at home. |
| 13:33 | <annevk> | heh |
| 13:33 | <annevk> | nox: don't worry, you'll understand when you get older |
| 13:34 | <nox> | annevk: Ah ah. |
| 13:34 | <nox> | annevk: I don't mind such issues, I just mind that we will have to change Servo. :P |
| 13:42 | <zcorpan> | annevk: 30 year crisis? :-) |
| 13:46 | <nox> | zcorpan: That's next year for me. |
| 13:47 | <annevk> | zcorpan: heh, predetermined deadline for giving up on improvements in this space |
| 13:48 | <mkwst> | annevk: Skimming through the XFO RFC, there's not really enough there to hook into. |
| 13:48 | <mkwst> | Do you want it defined in HTML, or Fetch, or just link to https://tools.ietf.org/html/rfc7034#section-2.3.2.1 and wash our hands of it? :) |
| 13:50 | <annevk> | An entire RFC for something super simple and it can't even be used |
| 13:50 | <annevk> | mkwst: I think we should just define it in HTML and forget about the RFC |
| 13:51 | <annevk> | mkwst: prolly with a note about our thinking |
| 13:52 | <mkwst> | Eh. The RFC is ~fine. It just doesn't wrap its requirements up into anything we can easily point to. |
| 13:54 | <mkwst> | Would you be sad if I changed the current stub to something even stubbier? Like "TODO: Implement XFO here." I don't really have time to spell it out right now, but can come back to it in a separate patch in The Future(tm). |
| 13:54 | <mkwst> | Or maybe I can get David to do it... :) |
| 13:55 | <annevk> | mkwst: I think that's okay |
| 13:55 | <annevk> | mkwst: will let Domenic sign off though |
| 13:56 | <mkwst> | ok. then I'll double the stub's stubbyness, and squash. thanks! |
| 13:57 | <annevk> | mkwst: no need to squash anymore fwiw |
| 13:57 | <annevk> | mkwst: GitHub has tools for that now |
| 13:58 | <mkwst> | Ah. Nice. :) |
| 14:03 | <mkwst> | ok. stubbed and assigned Domenic. |
| 14:25 | <zcorpan> | annevk: is there something in DOM that innerText setter should invoke? |
| 14:28 | <annevk> | zcorpan: note sure, presumably https://dom.spec.whatwg.org/#concept-node-replace-all once you have created the new Text node and set its node document and such |
| 14:28 | <annevk> | s/note/not/ |
| 14:28 | <zcorpan> | annevk: i looked at that also but it's not just 1 node, it's a list of text nodes and <br>s |
| 14:29 | <annevk> | zcorpan: use a DocumentFragment wrapper? |
| 14:29 | <zcorpan> | ah ok |
| 14:29 | <annevk> | zcorpan: that's how innerHTML works |
| 14:29 | <zcorpan> | thanks |
| 14:29 | <annevk> | zcorpan: and presumably we don't want multiple mutation records here |
| 14:37 | <zcorpan> | annevk: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4383 yep just 1 record in webkit/chromium/gecko |
| 15:03 | <annevk> | So that patch took two hours to write and I guess there'll be some follow up |
| 15:04 | <annevk> | I guess the lesson here is to specify features if browsers don't drop them within a short amount of time |
| 15:06 | <Domenic> | The lesson here is /topic |
| 15:08 | <annevk> | Yeah, but we did actually have input from sicking at the time that simplifying this would be worthwhile |
| 15:08 | <annevk> | And I think Gecko did make one simplification, no child nodes, that stuck and that was probably all we should have hoped for |
| 15:10 | <annevk> | Furthermore, if I recall correctly I didn't quite understand how cheap a prototype object could be and that also drove some of this non-Node-inheritance |
| 15:13 | <gsnedders> | Some kid outside just shouted, "ALIENS! OH MY GOSH!" |
| 15:13 | <Ms2ger> | Did you stick your head out of the window again? |
| 15:14 | <annevk> | So... mutation events? |
| 15:14 | <annevk> | Any progress on that front smaug____? |
| 15:15 | <gsnedders> | Ms2ger: nah, the window is open |
| 15:15 | annevk | wonders if there's other places where DOM could be updated to match reality besides mutation events since he's not much looking forward to those |
| 15:15 | <gsnedders> | Ms2ger: I'd post a photo, but IRC |
| 15:15 | <smaug____> | annevk: let me look at the telemetry |
| 15:18 | <smaug____> | hmm, do I read this right... has the usage of mutation events gone down significantly |
| 15:18 | smaug____ | looks at older data |
| 15:22 | <smaug____> | release builds: 39 0.4% of window/node objects had seen mutation event listener somewhere in them, 47 0.22% |
| 15:23 | <smaug____> | zcorpan: you're doing something with innerText? |
| 15:23 | <smaug____> | there was just a gecko bug, which requires a change to roc's draft |
| 15:23 | <annevk> | smaug____: that's still not even close to 0.003% which Blink requires for removal |
| 15:23 | <zcorpan> | smaug____: https://github.com/whatwg/html/pull/1678 |
| 15:24 | <smaug____> | zcorpan: is that based on roc's draft? |
| 15:24 | <smaug____> | ah, yes |
| 15:24 | <smaug____> | zcorpan: https://github.com/rocallahan/innerText-spec/issues/5 |
| 15:25 | <zcorpan> | smaug____: ok, thanks |
| 15:27 | <smaug____> | hmm, I'm not getting any warnings about mutation events usage in blink |
| 15:28 | <Domenic> | https://www.chromestatus.com/metrics/feature/timeline/popularity/143 https://www.chromestatus.com/metrics/feature/timeline/popularity/148 https://www.chromestatus.com/metrics/feature/timeline/popularity/144 https://www.chromestatus.com/metrics/feature/timeline/popularity/1173 |
| 15:28 | <smaug____> | Domenic: does blink warn about use of deprecated feature when using mutation events? |
| 15:28 | <Domenic> | No, I don't believe so |
| 15:29 | <Domenic> | foolip doesn't like warning about things unless we have a concrete removal plan |
| 15:29 | <smaug____> | we have concrete plan |
| 15:29 | <smaug____> | that is why MutationObserver was designed |
| 15:29 | <Domenic> | what version? |
| 15:29 | <Domenic> | I mean a concrete version number they'll be removed in |
| 15:29 | <smaug____> | oh, you mean plan in blink |
| 15:29 | <Domenic> | Yeah |
| 15:30 | <smaug____> | odd requirement to have plan for that |
| 15:30 | <smaug____> | of course you remove the feature when usage is low enough |
| 15:30 | <smaug____> | and hard to get usage low enough, if web devs think using the feature is just fine |
| 15:31 | <Domenic> | I tend to agree but I see both sides |
| 17:13 | <Wessee> | hello |
| 17:22 | <Wessee> | is iframe.contentWindow.Window === Window true or false? and why? or: is the Window (and other classes in DOM) supposed to be shared among all views, or each view has its own class definition? can someone point me to where this is defined? |
| 17:23 | <Domenic> | Wessee: false; each JavaScript environment has its own set of globals |
| 17:24 | <Domenic> | Digging up spec reference for you in a moment... |
| 17:24 | <Wessee> | thank you very much |
| 17:25 | <Domenic> | https://html.spec.whatwg.org/#creating-a-new-browsing-context step 2 + https://tc39.github.io/ecma262/#sec-initializehostdefinedrealm step 11 |
| 17:37 | <Wessee> | why is that, though? i'd have expected them to be the same object |
| 17:39 | <Domenic> | Hmm, why? They're completely separate |
| 17:40 | <Domenic> | It's important for one window not to be able to mess with another window; that can be a security issue |
| 17:40 | <Domenic> | E.g. var window2 = window.open("https://mybank.com";); if window2.Window === window.Window, then I can mess with code on mybank.com. |
| 17:50 | <Wessee> | i see. my actual question is, how could i check for, say, an Element instance cross-view. eg the way adoptNode does it |
| 17:53 | <Domenic> | .nodeType is pretty good |
| 17:57 | <Wessee> | that's not type safe :D but ok, i get it... maybe dom classes could be shared among those views having the same .origin ? |
| 17:59 | <Wessee> | nope that won't work, i think |
| 20:42 | <zcorpan> | Wessee: type-checking cross-globals doesn't work i believe. :-( you have to do duck typing. see https://github.com/w3c/testharness.js/blob/master/testharness.js#L699 |
| 21:34 | <Wessee> | yeah it's a bit of a bummer |
| 22:49 | <Wessee> | what happened to query() and queryAll() ? |
| 22:53 | <caitp> | the demigorgon ._. |
| 23:28 | <gsnedders> | does any spec cover loading stylesheets with the cross-origin Content-Type checking fun? |
| 23:29 | <gsnedders> | If not, what spec does that even belong in? Probably across multiple. |
| 23:50 | <TabAtkins> | gsnedders: https://drafts.csswg.org/css-cascade/#content-type ? |
| 23:56 | <gsnedders> | TabAtkins: that's only formally @import, right? |
| 23:56 | <gsnedders> | TabAtkins: is that true for <link rel=stylesheet> too? |
| 23:56 | <TabAtkins> | Ah, you're right, it's only defining @import |
| 23:57 | <TabAtkins> | Not to say it doesn't *intend* to work for <link>, too, but it doesn't *say* it does, and I don't remember the intent. |
| 23:58 | <gsnedders> | from memory that behaviour was the eventual interop after the attacks on lax handling for <link>, given AFAIK it's the exact same codepath |
| 23:59 | <TabAtkins> | yeah, i think so too |